Working around a javax.net.ssl.SSLHandshakeException

Steve Neal Development 1 Comment

When trying to download data from an HTTPS connection, you might see the following exception reported:

javax.net.ssl.SSLHandshakeException: renegotiation is not allowed

This rather unhelpful error message can be raised on either the server or the client and indicates that the SSL libraries in Java cannot determine whether the CA that signed the server’s certificate is to be trusted or not. The solution is pretty straight-forward but will differ between client and server.

Error appears in a Java client application

A quick fix to this problem is to add the server’s certificate to the local trust store.  Here’s how to do this:

  1. Visit the server using a web browser and click on the navigation bar to see the server’s certificate details.
  2. Export/save the X509 certificate to a local .cer file
  3. Import the certificate into the local CA trust store using the JDK keytool.

For step 3, given a certificate file called tomcat.cer and assuming that you are using JDK 1.5.0, you could use the following command line instruction:

keytool -import -keystore C:jdk1.5.0_22jrelibsecuritycacerts -alias tomcat -file tomcat.cer

For other JDK versions you’ll just need to adjust the above command a little.

Error appears in a Java server application

This is less common but something that I encountered recently when trying to access a Tomcat server that relied on client certificate (client-cert) based authentication. The fix to this is much the same as above except that the certificate for the client should be trusted by the server.

In this scenario the client is sending the certificate to prove their identity and the server needs reassuring that the certificate was issued by a trusted authority. To fix this scenario, repeat the command shown above substituting the CA certificate that is used t0 sign the client-certs.

Note that this change should only be made if you are certain that the CA that signed the clients certificate is trusted!

Different results discovered when using different versions of Java

Note that this exception is only raised by versions of Java 1.6.0_19 or later (SSL renegotiation was disabled in this version). Version 1.6.0_07, for example, just fails quietly and drops the socket connection. Version 1.5.0_20 (on Windows) seemed to work just fine for me.

This took me a while to find a work-around for so I hope this post helps someone.

Comments 1

  1. Bernd

    I also get this Excpetion when I use .startHandshake() explicitely, and did use some methods before, so the handshake was already done:

    //System.out.println(“connected1: ” + s.getSession().getCipherSuite());
    //System.out.println(“connected1: ” + s.getSession().getProtocol());
    s.startHandshake();
    System.out.println(“connected2: ” + s.getSession().getCipherSuite());
    System.out.println(“connected2: ” + s.getSession().getProtocol());

    In the above example, removing the comment marks will lead to the renegotiation problem (even when I overwrite the TrustManager to accept all server authentication).

    Bernd

Leave a Reply

Your email address will not be published. Required fields are marked *