javax.net.ssl.SSLHandshakeException: Remote-Host hat während des Handshakes während der Webdienstkommunikation die Verbindung geschlossen

77

Ich erhalte javax.net.ssl.SSLHandshakeException: Remote-Host hat während der Handshake- Ausnahme die Verbindung geschlossen, wenn ich versuche, HTTPS Post eines Webdienstes über das Internet durchzuführen . Der gleiche Code funktioniert jedoch auch für andere im Internet gehostete Webdienste. Ich habe viele Dinge ausprobiert, nichts hilft mir. Ich habe meinen Beispielcode hier gepostet. Kann mir bitte jemand helfen, dieses Problem zu lösen?

public static void main(String[] args) throws Exception {

    String xmlServerURL = "https://example.com/soap/WsRouter";
    URL urlXMLServer = new URL(xmlServerURL);
    // URLConnection supports HTTPS protocol only with JDK 1.4+ 
    Proxy proxy = new Proxy(Proxy.Type.HTTP, new InetSocketAddress(
            "xxxx.example.com", 8083));
    HttpURLConnection httpsURLConnection = (HttpURLConnection) urlXMLServer
            .openConnection(proxy);
    httpsURLConnection.setRequestProperty("Content-Type","text/xml; charset=utf-8");
    //httpsURLConnection.setDoInput(true);
    httpsURLConnection.setDoOutput(true);
    httpsURLConnection.setConnectTimeout(300000);
    //httpsURLConnection.setIgnoreProxy(false);
    httpsURLConnection.setRequestMethod("POST"); 
    //httpsURLConnection.setHostnameVerifier(DO_NOT_VERIFY); 
    // send request
    PrintWriter out = new PrintWriter(
            httpsURLConnection.getOutputStream());
    StringBuffer requestXML = new StringBuffer();
    requestXML.append(getProcessWorkOrderSOAPXML());   
    // get list of user     
    out.println(requestXML.toString()); 
    out.close();
    out.flush();
    System.out.println("XML Request POSTed to " + xmlServerURL + "\n");
    System.out.println(requestXML.toString() + "\n"); 
    //Thread.sleep(60000);  
    // read response

    BufferedReader in = new BufferedReader(new InputStreamReader( 
            httpsURLConnection.getInputStream()));
    String line;
    String respXML = "";
    while ((line = in.readLine()) != null) {
        respXML += line;
    }
    in.close();

    // output response
    respXML = URLDecoder.decode(respXML, "UTF-8"); 
    System.out.println("\nXML Response\n");
    System.out.println(respXML);
}

Vollständige Stapelverfolgung:

Exception in thread "main" javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
       at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:946)
       at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1312)
       at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1339)
       at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1323)
       at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:563)
       at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
       at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1091)
       at sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:250)
       at com.labcorp.efone.vendor.TestATTConnectivity.main(TestATTConnectivity.java:43)
Caused by: java.io.EOFException: SSL peer shut down incorrectly
       at sun.security.ssl.InputRecord.read(InputRecord.java:482)
       at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:927)
       ... 8 more

Tatsächlich gibt es hier zwei Szenarien. Wenn ich als eigenständiges Java-Programm arbeite, erhalte ich die oben genannte Ausnahme. Wenn ich jedoch versuche, auf einem Weblogic-Anwendungsserver auszuführen, wird die folgende Ausnahme angezeigt: Gibt es einen Hinweis darauf, was der Grund sein könnte?

java.io.IOException: Connection closed, EOF detected
    at weblogic.socket.JSSEFilterImpl.handleUnwrapResults(JSSEFilterImpl.java:637)
    at weblogic.socket.JSSEFilterImpl.unwrapAndHandleResults(JSSEFilterImpl.java:515)
    at weblogic.socket.JSSEFilterImpl.doHandshake(JSSEFilterImpl.java:96)
    at weblogic.socket.JSSEFilterImpl.doHandshake(JSSEFilterImpl.java:75)
    at weblogic.socket.JSSEFilterImpl.write(JSSEFilterImpl.java:448)
    at weblogic.socket.JSSESocket$JSSEOutputStream.write(JSSESocket.java:93)
    at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
    at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
    at java.io.FilterOutputStream.flush(FilterOutputStream.java:140)
    at weblogic.net.http.HttpURLConnection.writeRequests(HttpURLConnection.java:192)
    at weblogic.net.http.HttpURLConnection.getInputStream(HttpURLConnection.java:433)
    at weblogic.net.http.SOAPHttpsURLConnection.getInputStream(SOAPHttpsURLConnection.java:37)
    at com.labcorp.efone.service.impl.WorkOrderServiceImpl.processATTWorkOrder(ATTWorkOrderServiceImpl.java:86)
    at com.labcorp.efone.bds.WorkOrderBusinessDelegateImpl.processATTWorkOrder(WorkOrderBusinessDelegateImpl.java:59)
    at com.labcorp.efone.actions.ATTWorkOrderAction.efonePerformForward(ATTWorkOrderAction.java:41)
    at com.labcorp.efone.actions.EfoneAction.efonePerformActionForward(EfoneAction.java:149)
    at com.labcorp.efone.actions.EfoneAction.execute(EfoneAction.java:225)
    at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:484)
    at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:274)
    at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482)
    at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:751)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:844)
    at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:280)
    at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:254)
    at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:136)
    at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:341)
    at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:25)
    at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:79)
    at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
    at com.labcorp.efone.security.EfoneAuthenticationFilter.doFilter(EfoneAuthenticationFilter.java:115)
    at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
    at org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87)
    at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
    at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192)
    at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160)
    at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:346)
    at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:259)
    at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:79)
    at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.wrapRun(WebAppServletContext.java:3367)
    at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3333)
    at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
    at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
    at weblogic.servlet.provider.WlsSubjectHandle.run(WlsSubjectHandle.java:57)
    at weblogic.servlet.internal.WebAppServletContext.doSecuredExecute(WebAppServletContext.java:2220)
    at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2146)
    at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2124)
    at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1564)
    at weblogic.servlet.provider.ContainerSupportProviderImpl$WlsRequestExecutor.run(ContainerSupportProviderImpl.java:254)
    at weblogic.work.ExecuteThread.execute(ExecuteThread.java:295)
    at weblogic.work.ExecuteThread.run(ExecuteThread.java:254)
Exception: java.io.IOException: Connection closed, EOF detected
java ssl webservice-client user3216923
quelle
1
Können Sie bitte den vollständigen Stack-Trace posten?
Der Kerl mit dem Hut
1
Ein weiterer der vielen möglichen Gründe kann eine unterbrochene oder sehr minderwertige Verbindung sein
Comodoro
Was passiert, wenn Sie ein anderes Programm verwenden, um Ihren Webdienst wie Curl oder Soap-UI zu testen? Ich habe ein ähnliches Problem und es funktioniert mit Curl, aber nicht von meiner Java-Laufzeit (Servicemix). Ich vermute, es könnte auch der Client-Cacert sein, der das Serverzertifikat nicht enthält.
Februar
Falls jemand über gradle auf diese Seite gelangt ist, was das OP nicht verlangt, stellen Sie sicher, dass Sie JAVA_HOME auf Java 8 oder höher setzen.
Sridhar Sarnobat

Antworten:

70

Java 7 verwendet standardmäßig TLS 1.0, was diesen Fehler verursachen kann, wenn dieses Protokoll nicht akzeptiert wird. Ich bin auf dieses Problem mit einer Tomcat-Anwendung und einem Server gestoßen, der keine TLS 1.0-Verbindungen mehr akzeptiert. Ich fügte hinzu

-Dhttps.protocols=TLSv1.1,TLSv1.2

zu den Java-Optionen und das hat es behoben. (Tomcat führte Java 7 aus.)

Erica Kane
quelle
2
Wo soll ich diese Codezeile hinzufügen? In welcher Datei? Können Sie den Verzeichnispfad angeben?
hamed
2
Es ist kein Code, sondern Teil der Java-Optionen, die beim Aufrufen der ausführbaren Java-Datei festgelegt werden. Die genaue Antwort hängt von Ihrem Betriebssystem und Programm ab. Wenn Sie für Tomcat unter Windows wie in diesem Beispiel Tomcat7w ausführen, können Sie loslegen und anschließend die Java-Optionen ändern. In anderen Fällen fügen Sie die Optionen Ihrer Initialisierungsdatei oder der Befehlszeile java.exe hinzu und fügen sie dort hinzu. Ich würde definitiv empfehlen, nach Java-Optionen zu suchen, anstatt diese blind hinzuzufügen, wenn Sie mit ihnen nicht vertraut sind. Ein guter Startpunkt ist docs.oracle.com/javase/7/docs/technotes/tools/windows/java.html .
Erica Kane
1
@EricaKane - Es ist schön, eine Antwort zu haben. Aber wie können wir dieses Problem beheben und herausfinden, woran es liegt? (dh wie kommen wir zu Ihrer Lösung?)
MasterJoe
Wenn Sie mit einer öffentlich zugänglichen Website arbeiten, können Sie SSL Labs oder ein anderes Tool verwenden, um festzustellen, welches Protokoll akzeptiert wird. Wenn sie TLS 1.0 nicht mehr akzeptieren (und ehrlich gesagt, die meisten nicht) und Sie Java 7 verwenden, müssen Sie dies implementieren. Ich erinnere mich nicht mehr daran, wie ich dies ursprünglich speziell getestet habe.
Erica Kane
2
Dies scheint immer noch für Java 8 und Java Web Start von diesem zu gelten. Gerade <property name="https.protocols" value="TLSv1.1,TLSv1.2"/>zu einer JNLP-Datei hinzugefügt , um Web Start wieder betriebsbereit zu machen ...
Dirk Hillbrecht
30

Ich stand vor dem gleichen Problem und löste es durch Hinzufügen von:

System.setProperty("https.protocols", "TLSv1,TLSv1.1,TLSv1.2");

vor der openConnection- Methode.

Kamal SABBAR
quelle
20

Noch keine Antwort, aber zu viel für einen Kommentar. Dies ist eindeutig kein Serverzertifizierungsproblem. Die Symptome davon sind ganz anders. Aus dem POV Ihres Systems scheint der Server während des Handshakes geschlossen zu werden. Es gibt zwei Möglichkeiten:

Der Server wird wirklich geschlossen. Dies ist eine Verletzung des SSL / TLS-Protokolls, wenn auch eine ziemlich geringfügige. Es gibt einige Gründe, warum ein Server möglicherweise keinen Handshake mit Ihnen ausführt, aber er sollte zuerst eine schwerwiegende Warnung senden, auf die Ihre JSSE oder das Weblogic-Äquivalent hinweisen sollte. In diesem Fall enthält das Serverprotokoll möglicherweise einige nützliche Informationen, wenn Sie in der Lage (und berechtigt) sind, mit sachkundigen Serveradministratoren zu kommunizieren. Oder Sie können versuchen, einen Netzwerkmonitor auf Ihrem Client-Computer zu installieren, oder einen, der nah genug ist, um Ihren gesamten Datenverkehr zu sehen. persönlich mag ich www.wireshark.org. Dies zeigt jedoch normalerweise nur, dass der Abschluss unmittelbar nach dem ClientHello erfolgte, was ihn nicht wesentlich einschränkt. Sie sagen nicht, ob Sie ein "Client-Zertifikat" (tatsächlich Schlüssel & Zertifikat in Form eines Java privateKeyEntry) für diesen Server konfigurieren sollen und haben;kann dies als Angriff wahrnehmen und wissentlich gegen das Protokoll verstoßen, indem sie geschlossen werden, obwohl sie offiziell eine Warnung senden sollten.

Oder eine Middlebox im Netzwerk, meistens eine Firewall oder ein angeblich transparenter Proxy, entscheidet, dass Ihre Verbindung nicht gefällt, und erzwingt das Schließen. Der von Ihnen verwendete Proxy ist ein offensichtlicher Verdächtiger. wenn Sie der „gleiche Code“ sagen zu anderen Hosts arbeitet, bestätigen , wenn Sie das bedeuten durch gleiche Proxy (nicht nur einen Proxy) und HTTPS (nicht klares HTTP) . Wenn dies nicht der Fall ist, versuchen Sie, über den Proxy mit HTTPS an andere Hosts zu testen (Sie müssen keine vollständige SOAP-Anforderung senden, sondern nur ein GET / wenn genug). Wenn Sie können, versuchen Sie, eine Verbindung ohne den Proxy oder möglicherweise einen anderen Proxy herzustellen, und verbinden Sie HTTP (nicht S) über den Proxy mit dem Host (wenn beide klar unterstützen) und prüfen Sie, ob diese funktionieren.

Wenn es Ihnen nichts ausmacht, den tatsächlichen Host zu veröffentlichen (aber definitiv keine Authentifizierungsdaten), können andere es versuchen. Oder Sie können auf www.ssllabs.com nachfragen, ob der Server getestet werden soll (ohne die Ergebnisse zu veröffentlichen). Dadurch werden verschiedene gängige Varianten der SSL / TLS-Verbindung ausprobiert und alle aufgetretenen Fehler sowie Sicherheitslücken gemeldet.

dave_thompson_085
quelle
8

Ich denke, Sie vermissen Ihre Zertifikate.

Sie können versuchen, sie mithilfe der InstallCerts-App zu generieren. Hier können Sie sehen, wie es verwendet wird: https://github.com/escline/InstallCert

Sobald Sie Ihr Zertifikat erhalten haben, müssen Sie es in Ihrem Sicherheitsverzeichnis in Ihrem JDK-Home ablegen, zum Beispiel:

C:\Program Files\Java\jdk1.6.0_45\jre\lib\security

Lass mich wissen ob es funktioniert.

Federico Piazza
quelle
beide links sind down
kane
@ Kane Ich habe die Links aktualisiert ... Übrigens, meine Antwort versucht nicht zu erklären, wie Zertifikate generiert werden, sondern wo sie abgelegt werden sollen. Ich habe diesen Link als Kontextinformation hinzugefügt, falls OP tiefer in die Zertifikatsgenerierung eintauchen möchte.
Federico Piazza
7

Ich habe ein ähnliches Problem mit dem Glassfish-Anwendungsserver und Oracle JDK / JRE festgestellt, jedoch nicht mit Open JDK / JRE.

Beim Herstellen einer Verbindung zu einer SSL-Domäne stieß ich immer auf Folgendes:

javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
...
Caused by: java.io.EOFException: SSL peer shut down incorrectly

Die Lösung für mich bestand darin, die JCE-Richtliniendateien (Java Cryptography Extension) mit unbegrenzter Stärke zu installieren, da der Server nur Zertifikate verstand, die standardmäßig nicht in Oracle JDK enthalten sind, sondern nur OpenJDK. Nach der Installation funktionierte alles wie charme.

JCE 7: http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html

JCE 8: http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html

McIntosh
quelle
3

In meinem Fall trat dieses Problem auf, weil ich dem Server aufgrund eines Tippfehlers in der Konfigurationsdatei ein nicht vorhandenes Zertifikat erteilt hatte. Anstatt eine Ausnahme auszulösen, ging der Server wie gewohnt vor und schickte ein leeres Zertifikat an den Client. Es kann sich daher lohnen, zu überprüfen, ob der Server die richtige Antwort liefert.

Bei der Verwendung des Jersey-Clients für die Verbindung zu einem Server ist dieser Fehler aufgetreten. Ich habe es gelöst, indem ich die Bibliothek debuggt und festgestellt habe, dass sie in dem Moment, in dem sie zu lesen versuchte, tatsächlich eine EOF erhalten hat. Ich habe auch versucht, eine Verbindung mit einem Webbrowser herzustellen, und habe die gleichen Ergebnisse erzielt.

Schreiben Sie dies einfach hier, falls es jemandem hilft.

Parisbre56
quelle
2

Ich bin auf ein ähnliches Problem gestoßen und habe festgestellt, dass ich den falschen Port getroffen habe. Nach dem Reparieren des Hafens funktionierten die Dinge großartig.

user3225313
quelle
1

Vielen Dank an alle für das Teilen Ihrer Antworten und Beispiele. Das gleiche eigenständige Programm funktionierte für mich durch kleine Änderungen und das Hinzufügen der folgenden Codezeilen.

In diesem Fall wurde die Keystore-Datei vom Webservice-Anbieter angegeben.

// Small changes during connection initiation.. 

// Please add this static block 

      static {

        HttpsURLConnection.setDefaultHostnameVerifier(new HostnameVerifier()

            {   @Override

        public boolean verify(String hostname, SSLSession arg1) {

        // TODO Auto-generated method stub

                if (hostname.equals("X.X.X.X")) {

                    System.out.println("Return TRUE"+hostname);

                    return true;

                }

                System.out.println("Return FALSE");

                return false;

              }
               });
         }


String xmlServerURL = "https://X.X.X.X:8080/services/EndpointPort";


URL urlXMLServer = new URL(null,xmlServerURL,new sun.net.www.protocol.https.Handler());


HttpsURLConnection httpsURLConnection = (HttpsURLConnection) urlXMLServer               .openConnection();

// Below extra lines are added to the same program

//Keystore file 

 System.setProperty("javax.net.ssl.keyStore", "Drive:/FullPath/keystorefile.store");

 System.setProperty("javax.net.ssl.keyStorePassword", "Password"); // Password given by vendor

//TrustStore file

System.setProperty("javax.net.ssl.trustStore"Drive:/FullPath/keystorefile.store");

System.setProperty("javax.net.ssl.trustStorePassword", "Password");
Laxman
quelle
1

Ich bin auf dieses Problem mit Java 1.6 gestoßen. Das Ausführen unter Java 1.7 hat meine spezielle Wiedergabe des Problems behoben. Ich denke, die zugrunde liegende Ursache war, dass der Server, zu dem ich eine Verbindung hergestellt habe, eine stärkere Verschlüsselung benötigt haben muss als unter 1.6 verfügbar.

matt forsythe
quelle
1

Ich hatte den gleichen Fehler, aber in meinem Fall wurde er durch den DEBUG-Modus in Intellij IDE verursacht. Das Debugging verlangsamte die Bibliothek und der Server beendete die Kommunikation in der Handshake-Phase. Der Standard "RUN" hat einwandfrei funktioniert.

Bechyňák Petr
quelle
1

Ich führe meine Anwendung mit Java 8 aus und Java 8 brachte ein Sicherheitszertifikat in den Trust Store. Dann wechselte ich zu Java 7 und fügte den VM-Optionen Folgendes hinzu:

-Djavax.net.ssl.trustStore=C:\<....>\java8\jre\lib\security\cacerts

Ich habe einfach auf den Ort hingewiesen, an dem sich ein Zertifikat befindet.

Seltener Fall
quelle
1

Sie können diesen folgenden Code in Ihr aktuelles Java-Programm schreiben

System.setProperty("https.protocols", "TLSv1.1");

oder

System.setProperty("http.proxyHost", "proxy.com");

System.setProperty("http.proxyPort", "911");

Srinivas Thouti
quelle
0

Ich habe das p12 verwendet, das ich mit Keychain in mein MacBook exportiert habe, es funktionierte jedoch nicht mit meinem Java-Apns-Servercode. Was ich tun musste, war, einen neuen p12-Schlüssel wie hier angegeben mit meinen bereits generierten pem-Schlüsseln zu erstellen:

openssl pkcs12 -export -in your_app.pem -inkey your_key.pem -out your_app_key.p12

Dann wurde der Pfad zu dieser neuen p12-Datei aktualisiert und alles funktionierte perfekt.

Cyberdelphos
quelle
0

Wie Sie es lösen würden, ist zu gehen

  1. die Einstellungen

  2. Suche "Netzwerk"

  3. Wählen Sie "IDEA General Proxy-Einstellungen als Standard-Subversion verwenden".

W.Shawn
quelle
0

Mit Basis bei TLSv1.2 ALERT: fatal, handshake_failure habe ich nach dem Debuggen mit diesem Thread erhalten

-Djavax.net.debug = all

Ich ging zu https://www.ssllabs.com/ und festgestellt , dass der Web - Server einer SSLv3 Verbindung deprecate im Juni 2015 erforderlich und veraltete bei JDKu31 Release Notes

ssllabs Ergebnisse

Ich habe das $ {java_home} /jre/lib/security/java.security in der Zeile bearbeitet

jdk.tls.disabledAlgorithms = SSLv3, RC4, DES, MD5 mit RSA, DH-Schlüsselgröße <1024,
EC-Schlüsselgröße <224, 3DES_EDE_CBC, anon, NULL

zu

jdk.tls.disabledAlgorithms = RC4, DES, MD5withRSA, DH keySize <1024,
EC keySize <224, 3DES_EDE_CBC, anon, NULL

Als letzten Schritt habe ich diesen Fehler bekommen

sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target [javax.net.ssl.SSLHandshakeException]

Ich habe dieses Problem behoben, indem ich das Zertifikat mit dem Java-Keytool installiert habe. Nach dieser Antwort ist die Erstellung des PKIX-Pfads fehlgeschlagen. “Und„ Es konnte kein gültiger Zertifizierungspfad zum angeforderten Ziel gefunden werden. “

Josuedani
quelle
-2

Ich hatte einmal das gleiche Problem. Ich denke, es liegt an der URL

String xmlServerURL = " https://example.com/soap/WsRouter ";

Überprüfen Sie, ob es richtig ist oder nicht?

javax.net.ssl.SSLHandshakeException Dies liegt daran, dass der Server aus folgenden Gründen keine Verbindung zur angegebenen URL herstellen kann:

  • Entweder wird die Identität der Website nicht überprüft.
  • Das Serverzertifikat stimmt nicht mit der URL überein.
  • Oder das Serverzertifikat ist nicht vertrauenswürdig.
Manjunath Adoor
quelle
Dies SSLHandshakeException wird durch keines dieser Dinge verursacht.
user207421
-4

Das löst mein Problem.

Wenn Sie versuchen, den Debugger zu verwenden, stellen Sie sicher, dass sich Ihr Haltepunkt nicht in der URL oder URLConnection befindet. Setzen Sie Ihren Haltepunkt einfach auf BufferReader oder in die while-Schleife.

Wenn nichts funktioniert, verwenden Sie die Apache-Bibliothek http://hc.apache.org/index.html .

Kein SSL, kein JDK-Update erforderlich, keine Notwendigkeit, Eigenschaften festzulegen, nur ein einfacher Trick :)

Fahad Saleem
quelle