Does the order of Subject Alternative Names matter for TLS certificates?

Does the order of Subject Alternative Names matter for TLS certificates?

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.

The order of SAN entries does not matter

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.