0

I'm mostly creating this page to troubleshoot this issue, but also because Google returns 0 results for this quoted error in title.

A backend client of my legacy Tomcat7 webapp recently updated their SSL certificate to TLS1.2 and now my production systems can't connect. This code base is 5 years old and MASSIVE. I cannot simply upgrade to JDK 1.8 without major surgery.

In my Mac OSX Intellij IDE I use 1.7.0_u141 and it works fine, it can connect to the client and data is returned! BUT Using 1.7.0_79 in my IDE, I am able to reproduce the error and do a debug to the java code that tries to perform the SSL handshake.

I have tried to update the CentOS 6.6 server to use 1.7.0_131 (same error), I found 1.7.0_151b32 on "the internet" (i.e. not from oracle but looks legit) and tried it on a non-prod server with this issue, I still get the SSLHandshakeException: (data masked and changed so security won't yell at me)

com.twitter.finagle.SslHandshakeException: Received fatal alert: handshake_failure at remote address: client.example.com/##.##.##.##:443,DefaultHttpRequest(chunked: false)
GET /BClass/LocationStatusLookup?id=################### HTTP/1.1
Host: client.example.com
Accept-Encoding: gzip, deflate
,Some(com.twitter.finagle.ChannelWriteException: com.twitter.finagle.SslHandshakeException: Received fatal alert: handshake_failure at remote address: client.example.com/##.##.##.##:443))

I tried passing these arguments to tomcat7 setenv.sh: 

-Dhttps.protocols="TLSv1,TLSv1.1,TLSv1.2" 
-Djdk.tls.client.protocols="TLSv1,TLSv1.1,TLSv1.2"

No difference yet.

I also tried downloading cert in browser converting it to x509 using openssl and importing it into my jks (java key store).

Anything else I can do?

dlite922
  • 1,924
  • 3
  • 24
  • 60
  • Have a look at https://www.ssllabs.com/ssltest/viewClient.html?name=Java&version=7u25&key=26 : java 1.7 does not support TLS 1.2. So you need either to upgrade something or to downgrade something else. – Patrick Mevzek Apr 26 '18 at 23:15
  • https://blogs.oracle.com/java-platform-group/diagnosing-tls,-ssl,-and-https seems to say otherwise regarding java 1.7 and tls 1.2, and based on your own observations it seem to depend on the specific subversion of 1.7 ... good luck diagnosing that. See https://stackoverflow.com/questions/37806743/tls-1-2-was-supported-in-java-8-but-not-in-java-7 that deals with same issue. – Patrick Mevzek Apr 26 '18 at 23:26
  • The server cert is completely independent of TLS protocol version. j7 (all updates) does indeed support 1.2 if you enable it, but `https.protocols` does so only if the code goes through `[Https]URLConnection` which you didn't say, while `jdk.tls.client.protocols` only works in j7 from u95, and Oracle versions over 7u80 are available only on the 'advanced' (paid) plan not free, which you might consider if this app is so critical; OpenJDK releases of the same thing (including RHEL/CentOS) are usually free. (All updates of 8 have `jdk.tls.client.protocols`. And I believe 9 and 10.) ... – dave_thompson_085 Apr 27 '18 at 02:18
  • 1
    ... There are many possible causes of handshake_failure and the best way to distinguish them is to look on the server; https://stackoverflow.com/questions/6353849/ https://stackoverflow.com/questions/30350120/ https://stackoverflow.com/questions/49748108/ (last one mine) are just a few of the Qs about this I'm surprised google didn't give you. Failing that my first guess in your situation (and it's only a guess) is the server now demands 256-bit encryption and you are using Oracle 7 updates that don't allow that unless you install the 'unlimited policy' and you didn't. – dave_thompson_085 Apr 27 '18 at 02:23

0 Answers0