HTTPS communication failed , jdk 1.6 (32 bit client) with jdk 1.8 (64 bit) server : READ: Unknown-3.3 Alert, length = 2

This is my first question of stackoverflow. I am trying HTTPS communication between two tomcats:

1. Client Tomcat, using JDK1.6 32 bit.
2. Server Tomcat, using JDK1.8 64 bit.

Client Code for HTTPs request:

HttpClient hc = new HttpClient();
hc.startSession(monitAppURL);
int code = hc.executeMethod(poster);

Exception I get:

Received fatal alert: handshake_failure

I obtain the more detailed exception by starting JVM with -Djavax.net.debug=ssl:handshake:verbose:

trigger seeding of SecureRandom
done seeding SecureRandom
Allow unsafe renegotiation: true
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: true
Monitoring service @dealy::nap 30::30, setSoTimeout(0) called
Monitoring service @dealy::nap 30::30, setSoTimeout(0) called
%% No cached client session
*** ClientHello, TLSv1 RandomCookie: GMT: 1468994533 bytes = { 100, 134, 165, 203, 220, 40, 175, 72, 89, 189, 99, 104, 208, 177, 19, 59, 234, 210, 59, 1, 57, 254, 73, 155, 253, 82, 102, 221 } Session ID: {}
Cipher Suites: [SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WIT _AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CB _SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_DES_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_S A, SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_RSA_EXPORT WITH_DES40_CBC_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_DSS_EXPORT_W TH_DES40_CBC_SHA, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]

Compression Methods: { 0 }

*** Monitoring service @dealy::nap 30::30, WRITE: TLSv1 Handshake, length = 75
Monitoring service @dealy::nap 30::30, WRITE: SSLv2 client hello message, length = 101
Monitoring service @dealy::nap 30::30, READ: Unknown-3.3 Alert, length = 2
Monitoring service @dealy::nap 30::30, RECV TLSv1 ALERT: fatal, Handshake_failure
Monitoring service @dealy::nap 30::30, called closeSocket() Monitoring service
@dealy::nap 30::30, handling exception: javax.net.ssl.SSLHan shakeException: Received fatal alert: handshake_failure

I have started my JVM with set JAVA_OPTS="-Dhttps.protocols="TLSv1" -Djdk.tls.client.protocols="TLSv1" -Dcom.sun.net.ssl.checkRevocation=false -Ddeployment.security.TLSv1=true -Djavax.net.debug=ssl:handshake:verbose -Dsun.security.ssl.allowUnsafeRenegotiation=true -Djdk.tls.enableRC4CipherSuites=true -Ddeployment.security.TLSv1=true -Dhttps.cipherSuites=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

But still not able to get ride of the error. I've already spent a lot of time. Please help me resolve this issue.

I have found solution to my problem , 1.What was happening ? Java 6 by default uses SSlv2Client Hello message for handshake ,Even though it is using TLSv1 protocol.The Handshake message format is sslv2Client hello

@dealy::nap 30::30, WRITE: SSLv2 client hello message,length=101

My server is using java 8 , with SSLv3 disabled for security reason ,

jdk.tls.disabledAlgorithms=SSLv3

This was causing my handshake message failure ,as my client was sending sslv2Client hello message ,even though TLSv1 protocol was choosen for communication .Its reported as bug :

https://serverfault.com/questions/637880/disabling-sslv3-but-still-supporting-sslv2hello-in-apache

If you disable Sslv3 in jvm it also disables sslv2Client Hello message support

2.What I did ? apache httpClient always takes jvm original protocol stack for communication by default. Thats why my jvm arguments was not working for httpclient.

so, I overridden the httpclient SSL communication by adding following code .

SSLContext sslContext = SSLContexts.custom()
  .useTLS()
  .build();

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

HttpClient hc = HttpClients.custom()
  .setSSLSocketFactory(f)
  .build();

and finally , Apache httpclient started TLSv1 format handshake message for communication.

I hope this will help someone facing same issue ,

Thank you.