Pracuję nad samouczkiem dla usług sieciowych REST na stronie www.udemy.com (REST Java Web Services). Przykład w samouczku mówi, że aby mieć SSL, musimy mieć folder o nazwie „trust_store” w moim projekcie „klienta” zaćmienia, który powinien zawierać plik „magazynu kluczy” (mieliśmy projekt „klienta” do wywołania usługi oraz projekt „usługa”, który zawierał serwis internetowy REST - 2 projekty w tym samym obszarze roboczym zaćmienia, jeden klient, drugi serwis). Aby uprościć sprawę, powiedzieli, aby skopiować plik „keystore.jks” z serwera aplikacji glassfish (glassfish \ domains \ domain1 \ config \ keystore.jks), którego używamy, i umieścić go w tym folderze „trust_store”, w którym kazali mi zrobić projekt klienta. Wydaje się to mieć sens: samopodpisane certyfikaty na serwerze „ s key_store odpowiada certyfikatom w kliencie trust_store. Teraz robiąc to, otrzymałem błąd, o którym wspomina oryginalny post. Poszukałem tego i przeczytałem, że błąd wynika z pliku „keystore.jks” na kliencie nie zawierającego zaufanego / podpisanego certyfikatu, że znaleziony certyfikat jest samopodpisany.
Aby wszystko było jasne, powiem, że w moim rozumieniu plik „keystore.jks” zawiera certyfikaty z podpisem własnym, a plik „cacerts.jks” zawiera certyfikaty CA (podpisane przez urząd certyfikacji). „Plik keystore.jks” to „magazyn kluczy”, a „cacerts.jks” to „magazyn zaufania”. Jak komentuje „Bruno”, komentator powyżej, „keystore.jks” jest lokalny, a „cacerts.jks” jest dla zdalnych klientów.
Więc powiedziałem sobie: hej, glassfish ma również plik „cacerts.jks”, który jest plikiem trust_store glassfish. cacerts.jsk powinien zawierać certyfikaty CA. I najwyraźniej potrzebuję, aby mój folder trust_store zawierał plik magazynu kluczy, który ma co najmniej jeden certyfikat CA. Próbowałem więc umieścić plik „cacerts.jks” w utworzonym przeze mnie folderze „trust_store” w projekcie klienta i zmienić właściwości maszyny wirtualnej, aby wskazywały „cacerts.jks” zamiast „keystore.jks”. Pozbyłem się błędu. Chyba wszystko, czego potrzebował, to certyfikat CA do pracy.
Może to nie być idealne do produkcji, a nawet do rozwoju, poza czymś, co wystarczy do pracy. Na przykład prawdopodobnie można użyć polecenia „keytool”, aby dodać certyfikaty CA do pliku „keystore.jks” na kliencie. Ale i tak mam nadzieję, że przynajmniej zawęzi to możliwe scenariusze, które mogą się wydarzyć, aby spowodować błąd.
RÓWNIEŻ: moje podejście wydawało się przydatne dla klienta (certyfikat serwera dodany do klienta trust_store), wygląda na to, że powyższe komentarze do rozwiązania oryginalnego postu są przydatne dla serwera (certyfikat klienta dodany do serwera trust_store). Twoje zdrowie.
Konfiguracja projektu Eclipse:
- MyClientProject
- src
- test
- Biblioteka systemowa JRE
- ...
- trust_store
--- cacerts.jks --- keystore.jks
Urywek z pliku MyClientProject.java:
static {
// Setup the trustStore location and password
System.setProperty("javax.net.ssl.trustStore","trust_store/cacerts.jks");
// comment out below line
System.setProperty("javax.net.ssl.trustStore","trust_store/keystore.jks");
System.setProperty("javax.net.ssl.trustStorePassword", "changeit");
//System.setProperty("javax.net.debug", "all");
// for localhost testing only
javax.net.ssl.HttpsURLConnection.setDefaultHostnameVerifier(new javax.net.ssl.HostnameVerifier() {
public boolean verify(String hostname, javax.net.ssl.SSLSession sslSession) {
return hostname.equals("localhost");
}
});
}