4

I have noticed that the intermediate certificates on a web service are installed in the wrong order. What effects could I expect from this?

I used the Symantec certificate checker which stated:

Certificates installed in the wrong order.

Some certificates in the chain are installed in the wrong order. See details below. Reinstall the certificates in the proper order.

  1. Would this result in SSL handshakes being rejected?
  2. If they're not rejected, would it result in requests/responses being encrypted incorrectly?

1 Answer 1

2

As per the SSL/TLS standard:

  This is a sequence (chain) of certificates.  The sender's
  certificate MUST come first in the list.  Each following
  certificate MUST directly certify the one preceding it.

What may happen depends on the client: some will simply disregard the chain and simply revalidate the server's certificate, using the provided certificate as an unordered bag of "potentially useful certificates". Others will reject the chain and refuse to connect. A sub-case is when the certificates are so out-of-order that the first certificate in the chain is not the server's actual certificate: in that case, clients who did not rejected the chain will try to use the wrong certificate, and this ought to trigger a "name mismatch" warning (i.e. the client is trying to use the certificate of an intermediate CA, and the CA name does not match the expected server name); and it would ultimately lead to a handshake failure since the CA public key is not the server's public key.

In any case, the SSL handshake ends with a pair of Finished messages which are used to check that everything went well. If the client does not use the correct public key, the key exchange will fail, or (at worst) the Finished messages won't match, and no application data will be sent or received. There will not be any "incorrectly encrypted request/response".

You must log in to answer this question.

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