What order are TLS/SSL certificate attributes checked for validity? Is there a standard?

Question

Imagine an SSL certificate with the following parameters - we're going to concoct the worst imaginable cert by doing every possible thing wrong:

• Old, vulnerable cipher
• Vulnerable signature alrgorithm
• Wrong signature (signature doesn't match the contents)
• Explicitly revoked (cert is on a CRL we're using)
• CA explicitly marked untrusted in the cert store
• Wrong domain name/CN for the connection
• Expired
• Duplicate of another cert for a different domain
• Self signed

Of all of these error conditions for a certificate, in what order are they checked by the user agent?

Or, putting this another way, if I were to use this horrible certificate on a website, what error message would I get - and once I fixed that, what would be next, and so forth.

These errors all have different implications for the security of the connection, so some errors are objectively more scary than others - but is there a standard defined somewhere that states a "priority" for these problems? (I.e. telling me the cert is expired is silly if it's for the wrong website and using broken encryption)

Answer 1

RFC 5246, says the following about the ServerHello message:

The server will send this message in response to a ClientHello message when it was able to find an acceptable set of algorithms. If it cannot find such a match, it will respond with a handshake failure alert.

Therefore, if the ciphers proposed by the client aren't acceptable to the server (assuming the server administrator has disabled weak ciphers and the client only sends weak ciphers) the server will terminate the connection before it sends the certificate to the client.

If the ciphers are acceptable, the server sends its certificate to the client. RFC 5280 section 6 describes the certificate path validation. However, it has the following to say about it:

Conforming implementations of this specification are not required to implement this algorithm, but MUST provide functionality equivalent to the external behavior resulting from this procedure. Any algorithm may be used by a particular implementation so long as it derives the correct result.

Therefore the client may verify the path in any way it deems fit as long as the end result is the same. Given that there are many operating systems available, some with many libraries available for processing certificates, it would be very difficult to come to a definitive answer to your question.

Unfortunately, your options are probably limited to:

• Script certificate generation and testing with all combinations of your list above and run it against all libraries;
• Read the source code if available.