What means “javax.net.ssl.SSLHandshakeException: server certificate change is restrictedduring renegotiation” and how to prevent it?

Question

We use Oracle jdk 1.7.0_71 and Tomcat 7.0.55. Unfortunately we started to get the following exception during SSL connection between servers:

javax.net.ssl.SS         


        

Answer 1

I had this issue and it turned out to be that the client calling the service with a different cert behind a load balancer.

Answer 2

Following code piece worked for us in an enterprise environment under the following conditions;

• seamless (run-time) certificate update is a critical requirement
• it is too costly to update the HTTPClient used in the application
• restricting https protocol to "TLSv1" doesn't have effect
• the application is a JNLP served java client and neither the "allowUnsafeServerCertChange" and "allowUnsafeRenegotiation" are not allowed to be passed to the client application via JNLP arguments (i'm guessing JWS is blocking them due to security reasons)

• setting the "allowUnsafeServerCertChange" and "allowUnsafeRenegotiation" via System.setProperty() calls during the bootstrap of the application doesn't have effect.

  if (e.getCause() instanceof SSLHandshakeException) {
      logger.debug("server https certificate has been altered");
      try {
          Class<?> c = Class.forName("sun.security.ssl.ClientHandshaker");
          Field allowUnsafeServerCertChangeField = c.getDeclaredField("allowUnsafeServerCertChange");
          allowUnsafeServerCertChangeField.setAccessible(true);
          Field modifiersField = Field.class.getDeclaredField("modifiers");
          modifiersField.setAccessible(true);
          modifiersField.setInt(allowUnsafeServerCertChangeField, allowUnsafeServerCertChangeField.getModifiers() & ~Modifier.FINAL);
          allowUnsafeServerCertChangeField.set(null, true);
          logger.debug("client has been updated in order to support SSL certificate change (re-negotiation) on runtime.");
      }
      catch (Exception ex) {
          logger.debug("client cannot be updated to support SSL certificate change (re-negotiation) on runtime. Please restart the application.", ex);
      }
  }
  

Please note that this should be considered as a hack (introducing a vulnerability) and should be used in a trusted environment. One should try all the options in Yves' answer before going down this path.

Answer 3

This error message in client layer code is a consequence of code hardening following "SSL V3.0 Poodle Vulnerability - CVE-2014-3566" in recent Java updates. And it is a bug - here are work-arounds in case you cannot update your JRE immediately:

A first option is to force TLS protocol when establishing HTTPS connection:

If you can update HttpClient to a more recent version than 4.3.6, then SSLv3 will be disabled by default and your code should no longer report such exception.

If you cannot upgrade your HttpClient version, you will have to use this answer's code to restrict protocols to TLS: https://stackoverflow.com/a/26439487/737790

For other http access from Java 7 runtime, the following system property must be set

-Dhttps.protocols="TLSv1"

Full details can be found here: Java http clients and POODLE

A second option is to relax client check to still allow renegotiation with the following properties:

-Djdk.tls.allowUnsafeServerCertChange=true 
-Dsun.security.ssl.allowUnsafeRenegotiation=true

A third option is to "improve" your server certificates to include all IP addresses of your cluster members as Subject Alternative Names according to this post in Burp forum

A fourth option is to downgrade your Java version before this certificate/renegotiation checks have been added, so before 7u41 (to be confirmed)

Updates This buggy behaviour is now fixed in JDK updates 7u85 and 8u60. Credits to Pada for having found the JDK-8072385 reference.

Answer 4

I got this problem because the server side updated their certificates. Before this our client was working fine. We simply restarted our program & it went back to normal again.

Answer 5

This can also be due to misconfigured connectivity, such as an haproxy with one or more load-balance targets pointing to the wrong IP address, so that X percent of requests get a different certificate.