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?

1 Answer 1


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.

  • This was what I had thought initially too, but this situation was only happening with the new cert installed. Commented Sep 18, 2016 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. Commented Sep 18, 2016 at 14:03
  • @conorgriffin: see updated response: might also related to a bug in client but is nonetheless independent from the order of SAN. Commented Sep 18, 2016 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? Commented Sep 18, 2016 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. Commented Sep 18, 2016 at 14:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .