Javax.net.ssl.SSLHandshakeException: remote connection to a remote host during a handshake during a Communicaiton web service

Question

I get javax.net.ssl.SSLHandshakeException: remote closed host connection during a handshake exception when I try to make an HTTPS web service message over the Internet. But the same code also works for other Internet services. I tried a lot, nothing helps me. I have posted my sample code here. Can someone help me solve this problem?

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

 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 

There are actually two scenarios here. When I work as a standalone Java program, I get the exception above. But when I try to execute weblogic on the application server, I get the following exception: any hint, what could be the reason?

 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 

Answer 1

Java 7 defaults to TLS 1.0, which can cause this error if this protocol is not accepted. I ran into this problem with a Tomcat application and a server that will no longer accept TLS 1.0 connections. I added

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

for Java options and fixed it. (Tomcat was running Java 7.)

Answer 2

I ran into the same problem and solved it by adding:

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

before the openConnection method.

Answer 3

Not an answer yet, but too much for comment. This is clearly not a server certificate issue; the symptoms of this are completely different. From your POV system, the server seems to shut down during a handshake. Two possibilities are possible:

The server is indeed shutting down, which is a violation of the SSL / TLS protocol, although it is rather minor; There are many reasons why a server may disagree with you, but it should first send a fatal warning, which should indicate your JSSE or the equivalent of weblogic. In this case, there may be some useful information in the server log if you can (and are allowed to) contact a knowledgeable administrator of the server (s). Or you can try to place a network monitor on your client machine or one close enough to see all your traffic; I personally like www.wireshark.org. But this usually only shows that the closure occurred immediately after ClientHello, which does not greatly narrow it. You are not saying whether you want and set up a "client certificate" (actually key & cert, in the form of Java privateKeyEntry) for this server; if it is required by the server, and not correctly, some servers may perceive it as an attack and deliberately violate the protocol by shutting it down, although officially they must send a warning.

Or, some middle box on the network, most often a firewall or supposedly transparent proxy, decides that he does not like your connection and forces it to close. The proxy you are using is an obvious suspect; when you say that "the same code" works with other hosts, confirm whether you are using the same proxy (not just the proxy) and using HTTPS (incomprehensible HTTP). If this is not the case, try testing other hosts using HTTPS through a proxy (you do not need to send a full SOAP request, just GET / if enough). If you can, try connecting without a proxy server, or possibly another proxy server, and connect HTTP (not S) through the proxy server to the host (if both supports are clear) and see if they work.

If you don't mind publishing the actual host (but definitely not some credentials), others may try it. Or you can go to www.ssllabs.com and ask them to test the server (without publishing the results); this will try several common SSL / TLS connection options and report any errors detected, as well as any security weaknesses.

Answer 4

The first step to diagnose the problem is to start the client - and if you start the server yourself, a private test instance of the server - by starting Java with the VM parameter:

 -Djavax.net.debug=all 

See also https://blogs.oracle.com/java-platform-group/entry/diagnosing_tls_ssl_and_https

Answer 5

I think you are missing your certificates.

You can try creating them using the InstallCerts application. Here you can see how to use it: https://github.com/escline/InstallCert

Once you get the certificate, you need to place it under your security directory in your jdk home, for example:

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

Let me know if this works.

Answer 6

I ran into a similar problem with Glassfish and Oracle JDK / JRE application server, but not in Open JDK / JRE.

When connecting to an SSL domain, I always came across:

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

The solution for me was to install the Java Cryptography Extension (JCE) Unlimited Strength override protection policy files, because the server only understood certificates that were not included in the Oracle JDK by default, only OpenJDK included them. After installation, everything works like a 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

Answer 7

I ran into a similar problem and found that I got into the wrong port. After fixing the port, everything worked fine.

Answer 8

Thanks to everyone for sharing your answers and examples. The same stand-alone program worked for me with small changes and added the lines of code below.

In this case, the keystore file was provided by the webservice provider.

 // 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("XXXX")) { System.out.println("Return TRUE"+hostname); return true; } System.out.println("Return FALSE"); return false; } }); } String xmlServerURL = "https://XXXX: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"); 

Answer 9

I ran into this problem with Java 1.6. Running under Java 1.7 fixed my specific implementation of the problem. I think the main reason was that the server I was connecting to had to require stronger encryption than the one available under 1.6.

Answer 10

I had the same error, but in my case it was caused by DEBUG mode in the Intellij IDE. Debugging slowed down the library, and then terminated the connection with the server at the stage of establishing the connection. The standard "RUN" worked perfectly.

Answer 11

In my case, I got this problem because I gave the server a nonexistent certificate due to a typo in the configuration file. Instead of throwing an exception, the server passed as usual and sent an empty certificate to the client. Therefore, it may be worth checking that the server provides the correct answer.

I experienced this error when using the Jersey Client to connect to the server. The way I solved this was to debug the library and see that it really got EOF the moment it was trying to read. I also tried to connect using a web browser and got the same results.

Just write it here if it helps someone.

Answer 12

You can write this code below in your current Java program

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

or

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

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

Answer 13

I run my application with Java 8 and Java 8, bringing a security certificate to my trust store. Then I switched to Java 7 and added the following VM options:

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

I just pointed to the place where the certificate is located.

Answer 14

I used p12, which I exported using Keychain on my MacBook, however it did not work on my java-apns server code. I needed to create a new p12 key, as indicated here , using my pem keys already generated:

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

Then the path to this new p12 file is updated and everything works fine.

Answer 15

I ran into the same problem once. I think because of the url

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

Check if it is correct or not?

javax.net.ssl.SSLHandshakeException is that the server cannot connect to the specified URL due to the following reason -

• The identity of the website is not verified.
• Server certificate does not match URL.
• Or the server certificate is not trusted.

Answer 16

How do you solve this by going to

1. settings

2. Search "Network"

3. Select Use General IDEA Proxy Settings As Subversion By Default

Answer 17

Adding certificates to the Java \ jdk \ jre \ lib \ security folder worked for me. If you use Chrome, click the green lamp [ https://support.google.com/chrome/answer/95617?p=ui_security_indicator&rd=1] and save the certificate in the security folder.

Answer 18

This is what solves my problem.

If you are trying to use a debugger, make sure that no breakpoint is specified in the URL or URLConnection, just set a breakpoint on the BufferReader or inside the while loop.

If nothing works, try using the apache library http://hc.apache.org/index.html .

no SSL, no JDK update needed, no need to set properties even, just a simple trick :)

Answer 19

SSL takes up more memory than regular ports. Just make available memory for the SSL port. Search your application's port configuration in "headerBufferSize" I am changing it from 16k to 64k.