it-swarm.com.de

javax.net.ssl.SSLHandshakeException: Die Verbindung des Remote-Hosts während des Handshakes während der Web-Service-Kommunikation wurde geschlossen

Ich bekomme javax.net.ssl.SSLHandshakeException: Remote-Host-Verbindung beim Handshake geschlossen exception, wenn ich versuche, einen HTTPS-Post eines Webservices über das Internet auszufü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 veröffentlicht. 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);
}

Full Stacktrace:

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

Eigentlich 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, erhalte ich die folgende Ausnahme: Irgendwelche Anhaltspunkte, was könnte der Grund sein?

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
55
user3216923

Java 7 verwendet standardmäßig TLS 1.0, was zu diesem Fehler führen kann, wenn das 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 akzeptieren würde. Ich fügte hinzu

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

zu den Java-Optionen und das wurde behoben. (Tomcat lief mit Java 7.)

57
Erica Kane

Ich stand vor demselben Problem und löste es, indem ich Folgendes hinzufügte:

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

vor openConnection Methode.

20
Kamal SABBAR

Noch keine Antwort, aber zu viel für einen Kommentar. Dies ist eindeutig kein Server-Zertifizierungsproblem. Die Symptome dafür sind sehr unterschiedlich. Vom POV Ihres Systems aus scheint der Server während des Handshakes zu schließen. Es gibt zwei Möglichkeiten:

Der Server schließt gerade. Dies ist ein Verstoß gegen das SSL/TLS-Protokoll, allerdings nur ein geringfügiger Verstoß. Es gibt einige Gründe, warum ein Server möglicherweise keinen Handshake mit Ihnen durchführt, aber er sollte zuerst eine schwerwiegende Warnung senden, die von Ihrer JSSE oder dem Weblogic-Äquivalent angezeigt wird. In diesem Fall enthält das Serverprotokoll möglicherweise einige nützliche Informationen, wenn Sie in der Lage (und gestattet) sind, mit sachkundigen Serveradministratoren zu kommunizieren. Sie können auch versuchen, einen Netzwerkmonitor auf Ihrem Client-Computer zu installieren, oder einen Monitor, der nah genug ist, um den gesamten Datenverkehr anzuzeigen. persönlich mag ich www.wireshark.org. Dies zeigt jedoch in der Regel nur, dass der Abschluss unmittelbar nach dem ClientHello erfolgte, was nicht viel einschränkt. Sie sagen nicht, ob Sie ein "Client-Zertifikat" (tatsächlich key & cert in Form eines Java privateKeyEntry)) für diesen Server konfigurieren sollen und haben, ob dies vom Server benötigt wird und nicht korrekt, einige Server können das als Angriff wahrnehmen und wissentlich gegen das Protokoll verstoßen, indem sie schließen, 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 funktioniert, und erzwingt einen Abschluss. Der von Ihnen verwendete Proxy ist ein offensichtlicher Verdächtiger. Wenn Sie sagen, dass der "gleiche Code" für andere Hosts funktioniert, bestätigen Sie, ob Sie dies durch den gleichen Proxy (nicht nur einen Proxy) und mit HTTPS (nicht klares HTTP) meinen. Wenn dies nicht der Fall ist, testen Sie andere Hosts mit HTTPS über den Proxy (Sie müssen keine vollständige SOAP Anfrage senden, nur ein GET/wenn genug). Wenn Sie können, versuchen Sie es Verbinden ohne den Proxy oder möglicherweise einen anderen Proxy und Verbinden von HTTP (nicht S) über den Proxy mit dem Host (sofern beide klar unterstützen) und prüfen, ob diese funktionieren.

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

16

Bei glassfish application server und Oracle JDK/JRE ist ein ähnliches Problem aufgetreten, jedoch nicht bei Open JDK/JRE.

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

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 war die Installation der JCE-Richtliniendateien ( Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files, da der Server nur Zertifikate verstand, die nicht standardmäßig in Oracle JDK enthalten sind. Nur OpenJDK enthält sie. Nach der Installation hat alles wie am Schnürchen geklappt.


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

7
McIntosh

Ich denke, Sie vermissen Ihre Zertifikate.

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

Nachdem Sie Ihr Zertifikat erhalten haben, müssen Sie es in Ihrem jdk-Home-Verzeichnis unter dem Sicherheitsverzeichnis ablegen. Beispiel:

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

Lass mich wissen ob es funktioniert.

7
Federico Piazza

Ein erster Schritt zur Diagnose des Problems ist das Starten des Clients - und wenn Sie den Server selbst ausführen, eine private Testinstanz des Servers -, indem Sie Java mit der Option VM starten:

-Djavax.net.debug=all

Siehe auch https://blogs.Oracle.com/Java-platform-group/entry/diagnosing_tls_ssl_and_https

6
Henno Vermeulen

Ich stieß auf ein ähnliches Problem und stellte fest, dass ich den falschen Port traf. Nach der Reparatur des Hafens funktionierte alles super.

2
user3225313

In meinem Fall ist dieses Problem aufgetreten, weil ich dem Server aufgrund eines Tippfehlers in der Konfigurationsdatei ein nicht vorhandenes Zertifikat gegeben hatte. Anstatt eine Ausnahme auszulösen, ging der Server wie üblich weiter und sendete ein leeres Zertifikat an den Client. Es lohnt sich also zu prüfen, ob der Server die richtige Antwort liefert.

Dieser Fehler ist bei der Verwendung des Jersey-Clients zum Herstellen einer Verbindung zu einem Server aufgetreten. Wie ich es gelöst habe, war das Debuggen der Bibliothek und das Sehen, dass sie tatsächlich einen EOF erhielt, sobald sie zu lesen versuchte. Ich habe auch versucht, über einen Webbrowser eine Verbindung herzustellen und erhielt die gleichen Ergebnisse.

Einfach hier schreiben, falls es irgendjemandem helfen soll.

1
Parisbre56

Ich starte meine Anwendung mit Java 8 und Java 8 brachte das Sicherheitszertifikat in den Truststore. Dann wechselte ich zu Java 7 und fügte die folgenden Optionen in VM hinzu:

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

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

1
Rare Case

Vielen Dank an alle für das Teilen Ihrer Antworten und Beispiele. Dasselbe Standalone-Programm funktionierte für mich durch kleine Änderungen und das Hinzufügen der folgenden Codezeilen.

In diesem Fall wurde die Keystore-Datei vom Webservice-Provider bereitgestellt.

// 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");
1
Laxman

Dieses Problem ist bei Java 1.6 aufgetreten. Beim Ausführen unter Java 1.7 wurde meine besondere Wiedergabe des Problems behoben. Ich denke, die zugrunde liegende Ursache war, dass der Server, zu dem ich eine Verbindung herstellte, eine stärkere Verschlüsselung als unter 1.6 verfügbar erfordert.

1
matt forsythe

Sie können diesen 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");

1
Srinivas Thouti

Ich habe das p12 verwendet, das ich mit Keychain in mein MacBook exportiert habe. Es funktionierte jedoch nicht auf meinem Java-Apns-Servercode. Was ich tun musste, war, einen neuen p12-Schlüssel wie angegeben here zu erstellen, wobei meine bereits generierten Pem-Schlüssel verwendet wurden:

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 hat perfekt funktioniert.

0
Cyberdelphos

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

0
Bechyňák Petr

Ich war einmal mit demselben Problem konfrontiert. Ich denke es liegt an der URL 

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

Überprüfen Sie, ob es sich um ein ordnungsgemäßes Gerät handelt oder nicht?

javax.net.ssl.SSLHandshakeException ist darauf zurückzuführen, 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 Zertifikat des Servers stimmt nicht mit der URL überein.
  • Oder das Zertifikat des Servers ist nicht vertrauenswürdig.
0
Manjunath Adoor

Wie würden Sie es lösen, indem Sie gehen 

  1. Die Einstellungen

  2. Suche "Netzwerk"

  3. Wählen Sie "Verwenden Sie IDEA allgemeine Proxy-Einstellungen als Standard-Subversion". 

0
W.Shawn