Remote host closed connection during handshake ошибка

SSLHandshakeException appear in logs when there is some error occur while validating the certificate installed in client machine with certificate on server machine. In this post, we will learn about fixing this if you are using Apache HttpClient library to create HttpClient to connect to SSL/TLS secured URLs.

The exception logs will look like this.

Caused by: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
	at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:980)
	at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1363)
	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1391)
	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1375)
	at org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:275)
	at org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:254)
	at org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:117)
	at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:314)
	at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:363)
	at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:219)
	at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:195)
	at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:86)
	at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:108)
	at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:186)
	at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
	at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:57)
	at org.springframework.http.client.HttpComponentsClientHttpRequest.executeInternal(HttpComponentsClientHttpRequest.java:88)
	at org.springframework.http.client.AbstractBufferingClientHttpRequest.executeInternal(AbstractBufferingClientHttpRequest.java:46)
	at org.springframework.http.client.AbstractClientHttpRequest.execute(AbstractClientHttpRequest.java:49)
	at org.springframework.web.client.RestTemplate.doExecute(RestTemplate.java:509)
	... 61 more
Caused by: java.io.EOFException: SSL peer shut down incorrectly
	at sun.security.ssl.InputRecord.read(InputRecord.java:505)
	at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:961)
	... 80 more

I have already posted code fix to bypass SSL matching in earlier post.

Unfortunately, that fix works in TLS and TLS 1.1 protocols. It doesn’t work in TLS 1.2 protocol. So ultimately, you need to fix the certificate issue anyway. There is ‘no code only’ fix for this.

Now there are two ways, you can utilize the imported certificate from server. Either add certificate to the JDK cacerts store; or pass certificate information in JVM aruguments.

1) Import certificate to JDK cacert store

1. Import the certificate from server.
2. Use given command to add the certificate to JDK store. (Remove new line characters).

   keytool -import 
   	-noprompt 
   	-trustcacerts 
   	-alias MAVEN-ROOT 
   	-file C:/Users/Lokesh/keys/cert/maven.cer 
   	-keystore "C:/Program Files (x86)/Java/jdk8/jre/lib/security/cacerts" 
   	-storepass changeit
   

Now create HTTP client as given:

public HttpClient createTlsV2HttpClient() throws KeyManagementException, 
				UnrecoverableKeyException, NoSuchAlgorithmException, KeyStoreException {

      SSLContext sslContext = SSLContext.getInstance("TLSv1.2");

      SSLConnectionSocketFactory f = new SSLConnectionSocketFactory(sslContext, new String[] { "TLSv1.2" }, null,
                   						SSLConnectionSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);

      Registry<ConnectionSocketFactory> socketFactoryRegistry = RegistryBuilder.<ConnectionSocketFactory>create()
                   		.register("http", PlainConnectionSocketFactory.getSocketFactory())
                   		.register("https", f)
                   		.build();

      PoolingHttpClientConnectionManager cm = new PoolingHttpClientConnectionManager(socketFactoryRegistry);

      CloseableHttpClient client = HttpClients
      					.custom()
      					.setSSLSocketFactory(f)
                   		.setConnectionManager(cm)
                   		.build();
      return client;
}

Notice the code : SSLContext.getInstance("TLSv1.2"). This code picks up the certificates added to JDK cacert store. So make a note of it.

2) Pass certificate information in JVM aruguments

1. Import the certicate from server.
2. Add JVM arguments while starting the server. Change the parameter values as per your application.

   -Djavax.net.ssl.keyStore="C:/Users/Lokeshkeysmaven.jks" 
   -Djavax.net.ssl.keyStorePassword="test" 
   -Djavax.net.ssl.trustStore="C:/Users/Lokeshkeysmaven.jks" 
   -Djavax.net.ssl.trustStorePassword="test" 
   

Now create HTTP client as given:

public HttpClient createTlsV2HttpClient() throws KeyManagementException, 
				UnrecoverableKeyException, NoSuchAlgorithmException, KeyStoreException {

      SSLContext sslContext = SSLContexts.createSystemDefault();

      SSLConnectionSocketFactory f = new SSLConnectionSocketFactory(sslContext, new String[] { "TLSv1.2" }, null,
                   						SSLConnectionSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);

      Registry<ConnectionSocketFactory> socketFactoryRegistry = RegistryBuilder.<ConnectionSocketFactory>create()
                   		.register("http", PlainConnectionSocketFactory.getSocketFactory())
                   		.register("https", f)
                   		.build();

      PoolingHttpClientConnectionManager cm = new PoolingHttpClientConnectionManager(socketFactoryRegistry);

      CloseableHttpClient client = HttpClients
      					.custom()
      					.setSSLSocketFactory(f)
                   		.setConnectionManager(cm)
                   		.build();
      return client;
}

Notice the code : SSLContext.createSystemDefault(). This code picks up the certificates passed as JVM arguments. Again, make a note of it.

Summary

1. Use SSLContext.getInstance("TLSv1.2") when certificate is added to JDK cacert store.
2. Use SSLContext.createSystemDefault() when SSL info is passed as JVM argument.

Drop me your questions in comments section.

Happy Learning !!

«SSLHandshake: Remote host closed connection during handshake. » «SSLHandshake: Received fatal alert: certificate_unknown»

The reason you see the error «SSLHandshake: Remote host closed connection during handshke.» because the request was sent out from web browser over the HTTPS, if all the requests or responses sent out over HTTP, you won’t see this error in Charles because all requests sent out over HTTP are plain message without any encrypted. Either request or response sent out over HTTP or HTTPS, it depends on the website itself development system. As we said message over HTTP is plain message without any encrypted, then it will have less security. But if request or response sent out over HTTPS, all message are encrypted and have more security than over HTTP.

All messages exchanged between client and server are encrypted over HTTPS. If you want to see decoded plain text message between client end of phone and server over HTTPS, you have to install SSL certificate for Charles on your phone device, to let Charles translate these encrypted message for you by passing the installed SSL certificate between client and server. Check More details.

I am going to show you here with the details about how to install Charles ssl certificate on iPhone or android devices. Check this video, it will show you how to install Charles SSL Root Certificate on android phone.

The above video shows how set up Charles on Android phone There will be the same way to install ssl certificate on iPhone and android phone for Charles Proxy. 

On iPhone, now will show you how to set up Charles on iPhone:
#1. Go to Charles «Help» > «local IP Address», to found Proxy IP address. 
#2  Go to iPhone Settings> Wifi network, and select Wifi that was set up from you PC.
#3  Click on a blue disclosure arrow, scroll down to the HTTP Proxy setting, tap «Manual». Enter the IP address you found in step #2 into «Server field».
#4  In port field to fill port number. the port number you can found from Charles «Proxy»> «Proxy Settings», On Proxies tab, and in Http Proxy form.
#5  Leave Authentication set to Off.
#6  Go to Proxy>SSL Proxy Settings, to make sure In SSL Proxying tab check Enable SSL Proxying. and put «*» in Host and * in Port to filter all hosts and Ports.

On Android phone,
#1. Go to Proxy> Proxy Settings

On Proxies tab,  in Http Proxy form to fill out port number. Here you leave the default port number 8888 unchanged.
 
#2. Go to Proxy>SSL Proxy Settings

In SSL Proxying tab check Enable SSL Proxying
Click Add button to add * in Host and * in Port to filter all hosts and Ports, click OK button. Here you can put any Host or Port that you want to enable SSL Proxying for those Host and Port only.

#3. Go to Help > local IP Address

 to find you proxy IP address
 
 #4. Go to your phone Settings > Wifi
And long press the hotspot wifi that you set up from your computer, to bring up «Manage network Settings«
Fill in the password for you wifi
Check «Show advanced options«
In Proxy to choose «Manual»  
Fill IP address that you get from #3 in Proxy hostname and default «8888» in Proxy port. Save it.

#5. Go to web browser on the phone, in url type www.charlesproxy.com/getssl to install Charles certificate automatically. If you failed to download SSL certificate in the browser, see my another post how to fix this installation issue. Failed to install Charles SSL Certificate due to network.

Hi All,

I’m facing this error while trying to access to invoking servlet from a applet through HTTPS protocol.

But I works fine when i uses HTTP protocol.

Error message from Java console is given below.

javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.j(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.setProxiedClient(Unknown Source)
at sun.net.www.protocol.https.PluginDelegateHttpsURLConnection.superConnect(Unknown Source)
at sun.net.www.protocol.https.PluginDelegateHttpsURLConnection.connect(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(Unknown Source)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(Unknown Source)
at Test.Login.login(Login.java:127)
at Test.ConnectionDialog.makeConnection(ConnectionDialog.java:306)
at Test.ConnectionDialog$1.actionPerformed(ConnectionDialog.java:54)
at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source)
at java.awt.Component.processMouseEvent(Unknown Source)
at java.awt.Component.processEvent(Unknown Source)
at java.awt.Container.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Window.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.Dialog$1.run(Unknown Source)
at java.awt.Dialog.show(Unknown Source)
at java.awt.Component.show(Unknown Source)
at java.awt.Component.setVisible(Unknown Source)
at Test.ConnectionDialog.construct(ConnectionDialog.java:123)
at Test.ConnectionDialog.<init>(ConnectionDialog.java:42)
at Test.Menu.openConnectionDialog(SunExchangeMenu.java:147)
at Test.Menu.access$000(SunExchangeMenu.java:11)
at Test.Menu$1.actionPerformed(SunExchangeMenu.java:62)
at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
at javax.swing.AbstractButton.doClick(Unknown Source)
at javax.swing.plaf.basic.BasicMenuItemUI.doClick(Unknown Source)
at javax.swing.plaf.basic.BasicMenuItemUI$MouseInputHandler.mouseReleased(Unknown Source)
at java.awt.Component.processMouseEvent(Unknown Source)
at java.awt.Component.processEvent(Unknown Source)
at java.awt.Container.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
Caused by: java.io.EOFException: SSL peer shut down incorrectly
at com.sun.net.ssl.internal.ssl.InputRecord.read(Unknown Source)
… 66 more

I’m using Iplanet IWS 4.1 webserver.
Java 1.4.2

Thanks in Advance
James

[{«Product»:{«code»:»SS9GLA»,»label»:»IBM Control Center»},»Business Unit»:{«code»:»BU059″,»label»:»IBM Software w/o TPS»},»Component»:»—«,»Platform»:[{«code»:»PF033″,»label»:»Windows»},{«code»:»PF027″,»label»:»Solaris»},{«code»:»PF016″,»label»:»Linux»},{«code»:»PF010″,»label»:»HP-UX»},{«code»:»PF002″,»label»:»AIX»}],»Version»:»5.4″,»Edition»:»»,»Line of Business»:{«code»:»LOB59″,»label»:»Sustainability Software»}}]

The remote server is dropping the connection though the specific reason on why it’s getting dropped it
something we need to discover.

The full error is as follows:
org.identityconnectors.framework.common.exceptions.ConnectorException: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake.

Check the connection

It’s fairly safe to state that the connection between the servers is correct though it’s probably worth determining the ping/telnet request
between the servers as well as ensuring that your services are running on the remote server by performing a netstat

Check the certificate is still valid

Probably not the first thing to check though you need to ensure that your certificate remains valid. Assuming that you’ve already setup the connector server with SSL = true.
If you’re not using SSL and you have your connector server and AD IT resource setting to SSL, then you need to change that, purge the OIM cache, then retry.

To confirm the certificate is valid, you need to perform the keytool command with the list parameter. A useful reference link, Common java keytool commands will be of assistance as you’ll be using the OOTB java SDK keytool commands.
An example to see the certificates is as follows:
./keytool -list -keystore /u01/app/oracle/Middleware/wlserver_10.3/server/lib/DemoTrust.jks -storepass DemoTrust -alias mykey -v

Check the remote server

Certificate is valid, OK good. Next, check the remote server itself. The connector server services has already been checked
when you performed the action within the ‘checking the connection’ section though you need to ensure the connector server is up and running

The issue from my experience was that the HDD reached full capacity. This was a result of the connector server
growing to the point that the HDD was full. The resultant action was to cleanup the HDD then bounce the services as mentioned above, including the OIM connector server service.

This however didn’t resolve the issue. Once I did that, I needed to restart the Active Directory Web Services services, the remote registry service, and of course the connector server
connection.

Once completed, check within the connector server logs that the connection from OIM is initiated and presented within the log file

Further Issues — Authentication failed because the remote party has closed the transport stream.

One of the reasons why the logs were getting populated was because
of the following error. The error in question was getting getting populated within the ICF connector server log file at every 5 second intervals. (It’s probably worth noting that the
with the connector server service residing on the Active Directory Domain Controller).

Obviously the SSL configuration is the immediate item in question here. The work around to this was to configure the OIM and AD IT Resource to non-ssl, which removed the
error within the logs. Futhermore, this also stopped the sporadic failure for the provisioning of AD accounts.

The error, ‘ConnectorServer.exe Error: 0 : Error processing request’ seems to be a generic response by default so I would ignore that.

Of course from OIM to the connector works as expected. From the OIM perspective, the JKS had a valid certificate for the initial request.

Because OIM uses the common java keystore for it’s certificates, you can use the common command to validate the certificates. You’ll find that this website,
The Most Common Java Keytool Keystore Commands contains pretty much
all the commands needed. To access the keystore though, you would use something as follows:
./keytool -list -keystore /u01/app/oracle/Middleware/wlserver_10.3/server/lib/DemoTrust.jks -storepass DemoTrustKeyStorePassPhrase -alias mykey -v This only leaves the issue of certifications and the initial handshake over the network to be the cause to the issue, If I find out I’ll re-post though for now, we’re proceeding with non-SSL in our non-PROD environment

Comments

Other Posts