2

I ran into an issue today and I'm interested in finding out if the behaviour seen is standard or non standard.

We have several servers that are exposed through a load balancer serving https requests. These servers use TLS certificates with three Subject Alternative Name entries.

For example:

  1. myservice.mycompany.int
  2. dc1.myservice.int
  3. dc2.myservice.int

We had one of the servers rebuilt and a new cert deployed on that server. The Subject Alternative Name entries on the new cert had the same entries as shown above but in a different order.

We had one client system that had issues after this server went into the load balancer where it was throwing the following errors:

Caused by: javax.net.ssl.SSLHandshakeException: server certificate change is restricted during renegotiation

So I came to the conclusion that this was due to the order of the SAN entries when an SSL session renegotiation was being performed by the client system and it got a cert with the SAN entries in a different order.

Is the order of the SAN entries supposed to be significant when determining whether a certificate is equivalent for the purposes of TLS renegotiation?

conorgriffin
  • 185
  • 7

1 Answers1

5

The order of subject alternative names is not important. What the client is complaining about was a change of the certificate during renegotiation inside an existing SSL session. It does not matter what the change is, i.e. it is enough that the serial number has been changed.

Apart from that it might be a bug in the client. See What means “javax.net.ssl.SSLHandshakeException: server certificate change is restrictedduring renegotiation” and how to prevent it? where the answer points out a bug in Java7 and Java8 introduced while trying to mitigate POODLE. According to this post the bug was fixed in Java 7u85 and 8u60.

Community
  • 1
Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • This was what I had thought initially too, but this situation was only happening with the new cert installed. – conorgriffin Sep 18 '16 at 14:02
  • @conorgriffin: if there is an existing SSL session (established with the old certificate) and a renegotiation is done in this session with the new certificate then you get this error. – Steffen Ullrich Sep 18 '16 at 14:03
  • @conorgriffin: see updated response: might also related to a bug in client but is nonetheless independent from the order of SAN. – Steffen Ullrich Sep 18 '16 at 14:07
  • Thanks I'll look into the client bug. Is there somewhere I can reference that states the order should not matter? An RFC perhaps? – conorgriffin Sep 18 '16 at 14:18
  • 1
    @conorgriffin: You might for example take a look at RFC 6125. It does not explicitly state that the order does not matter but it is quite clear that it is relevant that at least on SAN matches the hostname - which means that the actual order of the SAN does not matter at all. – Steffen Ullrich Sep 18 '16 at 14:36
  • I strongly suspect this was due to the client code as they are running OpenJDK 1.8.0_51. Will accept once confirmed, thanks – conorgriffin Sep 18 '16 at 17:44