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.SSLHandshakeException: server certificate change is restrictedduring renegotiation

What it means? How to prevent it?

The exception is disappeared after the Tomcat restart.

The full stack:

Caused by: javax.net.ssl.SSLHandshakeException: server certificate change is restrictedduring renegotiation
        at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) ~[?:1.7.0_71]
        at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1884) ~[?:1.7.0_71]
        at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:276) ~[?:1.7.0_71]
        at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:266) ~[?:1.7.0_71]
        at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1402) ~[?:1.7.0_71]
        at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:209) ~[?:1.7.0_71]
        at sun.security.ssl.Handshaker.processLoop(Handshaker.java:878) ~[?:1.7.0_71]
        at sun.security.ssl.Handshaker.process_record(Handshaker.java:814) ~[?:1.7.0_71]
        at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1016) ~[?:1.7.0_71]
        at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1312) ~[?:1.7.0_71]
        at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:702) ~[?:1.7.0_71]
        at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:122) ~[?:1.7.0_71]
        at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) ~[?:1.7.0_71]
        at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) ~[?:1.7.0_71]
        at org.apache.commons.httpclient.methods.EntityEnclosingMethod.writeRequestBody(EntityEnclosingMethod.java:506) ~[commons-httpclient-3.1.jar:?]
        at org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.java:2114) ~[commons-httpclient-3.1.jar:?]
        at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1096) ~[commons-httpclient-3.1.jar:?]
        at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:398) ~[commons-httpclient-3.1.jar:?]
        at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171) ~[commons-httpclient-3.1.jar:?]
        at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397) ~[commons-httpclient-3.1.jar:?]
        at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323) ~[commons-httpclient-3.1.jar:?]
        at org.springframework.remoting.httpinvoker.CommonsHttpInvokerRequestExecutor.executePostMethod(CommonsHttpInvokerRequestExecutor.java:205) ~[spring-web-3.2.9.RELEASE.jar:3.2.9.RELEASE]
        at org.springframework.remoting.httpinvoker.CommonsHttpInvokerRequestExecutor.doExecuteRequest(CommonsHttpInvokerRequestExecutor.java:140) ~[spring-web-3.2.9.RELEASE.jar:3.2.9.RELEASE]
        at org.springframework.remoting.httpinvoker.AbstractHttpInvokerRequestExecutor.executeRequest(AbstractHttpInvokerRequestExecutor.java:136) ~[spring-web-3.2.9.RELEASE.jar:3.2.9.RELEASE]
        at org.springframework.remoting.httpinvoker.HttpInvokerClientInterceptor.executeRequest(HttpInvokerClientInterceptor.java:192) ~[spring-web-3.2.9.RELEASE.jar:3.2.9.RELEASE]
        at org.springframework.remoting.httpinvoker.HttpInvokerClientInterceptor.executeRequest(HttpInvokerClientInterceptor.java:174) ~[spring-web-3.2.9.RELEASE.jar:3.2.9.RELEASE]
        at org.springframework.remoting.httpinvoker.HttpInvokerClientInterceptor.invoke(HttpInvokerClientInterceptor.java:142) ~[spring-web-3.2.9.RELEASE.jar:3.2.9.RELEASE]
        ... 160 more

Casemate

Looks like your server sent a different certificate during renegotiation then initially. Did you change certificates while running or do you have multiple certificates configured? – Copyholder

No, One certificate that perform SSL handshake – Casemate

What does "X" mean? * – Carbohydrate

If it's a bug, it doesn't appear to be fixed in all cases. We've also seen this on JDK 1.8.0_40 – Nide

Answer 1

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://mcmap.net/q/390875/-java-http-clients-and-poodle

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.

Sloatman

I am afraid that all these options are bad workarounds for what was supposed to be code change in JIRA and Confluence. It seems that Apache HttpClient 4.3.6 disables SSLv3 by default, which means that JIRA and Confluence should just do the same. BTW, the SO contains more details related to JAVA 8 !!!. – Hopscotch

Why JIRA and Confluence ? I find out that Burp is also impacted. May it be related to HttpClient or maybe also Spring behavior that changed recently ? – Sloatman

As far as I can tell the code that caused this issue was: hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/eabde5c42157 and now it seems like they have fixed it with: bugs.openjdk.java.net/browse/JDK-8072385 So the fix would be included in: 7u85 & 8u60 – Shantell

I am now running Java 8u60 with https.protocols="TLSv1" but a deployed product still face this error. Definitely not fixed yet. – Sloatman

I have raised a similar question but I am using java 1.8 and httclient 4.4.1 and using only TLSv1.2. Please see if you can help-#37821928 – Cheesecake

https.protocols should not contain quotation, so the proper value is: -Dhttps.protocols=TLSv1 – Inofficious

Why not ? I agree quotes are useless here, but should not prevent option to work. Do you notice failures comparing with and without quotes ? – Sloatman

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.

Borsch

Answer 3

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.

Ingoing

I agree. But in my context, it is relative to LDAP/SSL ActiveDirectory endpoints in cluster, and administrators seem reluctant to deploy the same certificate on both endpoints manually because it breaks automatic renewal mechanism. But you're right, a 10-year certificate with correct alternate names is the best option. – Sloatman

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.

Pinnace

Answer 5

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

Saprophyte