Forum Stats

  • 3,827,899 Users
  • 2,260,838 Discussions


Java 8 SSL issues - works properly with Java 7

3533137 Member Posts: 1
edited Sep 1, 2017 2:56AM in Java Programming

The Problem:

I am having issues sending an HTTPS GET request that requires a client certificate while using Java 8.

The following code is used to build the SSL context and start the REST Client - the code builds and runs correctly for both Java 7 and Java 8 (no functions are marked as deprecated): 

Screen Shot 2017-08-31 at 5.26.21 PM.png

After building the SSL context and starting REST Client, I attempt to make a GET request to a REST API - this code also builds and runs properly on both Java 7 and Java 8:

Screen Shot 2017-08-31 at 5.32.39 PM.png

Note: I am not displaying the setRestRequestHeaders() function because it contains confidential credentials - but all the function does is set the content type and expected content to JSON, and set the user's username and password.

The difference between Java 7 and Java 8 is the response from the REST API. Java 7 always returns the expected result (the expected JSON object). Java 8 always fails, never returning a response but returning the following Exception message: "An existing connection was forcibly closed by the remote host." Note: the exception is thrown during the SSL handshake process.

My Attempted Solutions:

First, I tried searching online for similar issues, but I do not find anyone else that posted about the same problem.

Second, I am using Apache Commons' Async Http Client, so I thought of the possibility of a bug within that dependency - here is the exact version:

Screen Shot 2017-08-31 at 5.41.45 PM.png

Thus, I attempt to use the non-asynchronous native Java Http Client: Screen Shot 2017-08-31 at 5.49.04 PM.png

Screen Shot 2017-08-31 at 5.50.15 PM.png

But the result was the same (Java 7 success, Java 8 failure).

Third, I set the system property "" to "all", as such:

Screen Shot 2017-08-31 at 5.53.33 PM.png

This logs the SSL handshake to the console. I a GET request with both Java 7 and Java 8 and saved the SSL log output. I ran a 'diff' against both files, and there were only minor differences that did not give any pointer towards the root of the problem. Feel free to leave me a message if you would like to see the logs; I have them with the property set to just "ssl" as well.

Lastly, I just looked more into Java cryptography and found out there is a Java Cryptography Extension (JCE) that can be added to a Java Runtime. The JCE essentially allows for more complex cryptography (i.e., a more complicated client certificate). I added the JCE to my Java 8 runtime (within the SDK), and it did not fix anything. The only thing that it changed was in the SSL handshake logs (mentioned above) there were less "unavailable" cipher suites.

My Development Environment:

Java Versions:

Screen Shot 2017-08-31 at 6.17.55 PM.png

IDE: IntelliJ IDEA Community Edition 2017.2

Relevant Dependencies: Apache Commons' Async HTTP Client version: 1.3.2, and tried the Java native HttpsURLConnection.

Final Comments:

No trust certificate is used - the trust certificate for the REST API I am connecting to is a GoDaddy certificate that is in the default Java Truststore.

I can use Java 8 to successfully connect and make requests to other URL's that do not require a client certificate.

I would not call myself an expert on SSL or Java Keystores - there may be something simple that I am missing. I do not know what the issue is, but I find it odd for my non-deprecated code to work on Java 7 and not Java 8. If anyone has any comments/suggestions/questions, please do not hesitate to let me know. Thank you!



  • handat
    handat Member Posts: 4,688 Gold Crown
    edited Sep 1, 2017 2:56AM

    What are the ciphers, signing algorithm and key length of the certificate in question? Since you are using JDK 7.0.79 (this was one prior to security enhancements allowing weak algorithms) it would not had enforced stricter security like the later 7 releases such as 7.0.91+ which would be similar to what 8 does.

    Check the differences specified in, in particular jdk.certpath.disabledAlgorithms and jdk.tls.disabledAlgorithm.

This discussion has been closed.