Edycja: - Próbowałem sformatować pytanie i zaakceptowałem odpowiedź w bardziej reprezentatywny sposób na moim blogu
Oto oryginalny numer.
Otrzymuję ten błąd:
szczegółowy komunikat sun.security.validator.ValidatorException: Kompilacja ścieżki PKIX nie powiodła się:
sun.security.provider.certpath.SunCertPathBuilderException: nie można znaleźć prawidłowej ścieżki certyfikacji do żądanego celupowoduje javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: nie powiodło się budowanie ścieżki PKIX: sun.security.provider.certpath.SunCertPathBuilderException: nie można znaleźć prawidłowej ścieżki certyfikacji do żądanego celu
Używam Tomcat 6 jako serwera WWW. Mam dwie aplikacje internetowe HTTPS zainstalowane na różnych Tomcats na różnych portach, ale na tym samym komputerze. Powiedz App1(port 8443)i
App2(port 443). App1łączy się z App2. Po App1nawiązaniu połączenia App2otrzymuję powyższy błąd. Wiem, że jest to bardzo częsty błąd, więc natknąłem się na wiele rozwiązań na różnych forach i stronach. Mam poniższy wpis w server.xmlobu Tomcats:
keystoreFile="c:/.keystore"
keystorePass="changeit"
Każda witryna podaje ten sam powód, dla którego certyfikat podany przez app2 nie znajduje się w zaufanym magazynie jvm app1. Wydaje się, że tak jest również wtedy, gdy próbowałem trafić w ten sam adres URL w przeglądarce IE, działa (działa z ociepleniem, jest problem z certyfikatem bezpieczeństwa tej strony. Tutaj mówię, kontynuuj na tej stronie). Ale kiedy klient Java uderza w ten sam adres URL (w moim przypadku), pojawia się powyższy błąd. Aby umieścić go w magazynie zaufania, wypróbowałem trzy opcje:
Opcja 1
System.setProperty("javax.net.ssl.trustStore", "C:/.keystore");
System.setProperty("javax.net.ssl.trustStorePassword", "changeit");
Opcja 2 Ustawienie poniżej w zmiennej środowiskowej
CATALINA_OPTS -- param name
-Djavax.net.ssl.trustStore=C:\.keystore -Djavax.net.ssl.trustStorePassword=changeit ---param value
Opcja 3 Ustawienie poniżej w zmiennej środowiskowej
JAVA_OPTS -- param name
-Djavax.net.ssl.trustStore=C:\.keystore -Djavax.net.ssl.trustStorePassword=changeit ---param value
Ale nic nie działało .
Co w końcu działało, stosując podejście Java sugerowane w Jak obsługiwać nieprawidłowe certyfikaty SSL za pomocą Apache HttpClient? przez Pascal Thivent, tj. wykonując program InstallCert.
Ale takie podejście jest dobre dla konfiguracji devboksa, ale nie mogę go używać w środowisku produkcyjnym.
Zastanawiam się dlaczego trzema podejściami wymienionymi powyżej nie działa, gdy wspomniałem te same wartości server.xmlod app2wartości serwerowych i samych w truststore przez ustawienie
System.setProperty("javax.net.ssl.trustStore", "C:/.keystore") and System.setProperty("javax.net.ssl.trustStorePassword", "changeit");
w app1programie.
Aby uzyskać więcej informacji, w ten sposób nawiązuję połączenie:
URL url = new URL(urlStr);
URLConnection conn = url.openConnection();
if (conn instanceof HttpsURLConnection) {
HttpsURLConnection conn1 = (HttpsURLConnection) url.openConnection();
conn1.setHostnameVerifier(new HostnameVerifier() {
public boolean verify(String hostname, SSLSession session) {
return true;
}
});
reply.load(conn1.getInputStream());
domainnameserwerów RHEL problem zniknął. Mam nadzieję, że to komuś pomoże.