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

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 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.)

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.

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.

Ein erster Schritt zur Diagnose des Problems besteht darin, den Client zu starten - und wenn Sie den Server selbst ausführen, eine private Testinstanz des Servers -, indem Sie Java mit der VM-Option starten:

-Djavax.net.debug=all

Siehe auch https://blogs.oracle.com/java-platform-group/entry/diagnosing_tls_ssl_and_https

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.

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

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.

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.

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");

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.

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.

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.

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");

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.

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".

Gemäß https://kb.informatica.com/solution/23/Pages/69/570664.aspx funktioniert das Hinzufügen dieser Eigenschaft

CryptoProtocolVersion = TLSv1.2

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

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. “

Das Hinzufügen von Zertifikaten zum Ordner Java \ jdk \ jre \ lib \ security hat bei mir funktioniert. Wenn Sie Chrome verwenden, klicken Sie auf die grüne Lampe [ https://support.google.com/chrome/answer/95617?p=ui_security_indicator&rd=1] und speichern Sie das Zertifikat im Sicherheitsordner.

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.

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 :)