1

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)

  • There are lots of different types of user agents. Every browser is even slightly different. So in what context are you using this TLS/SSL certificate exactly? – Ramhound Feb 11 '19 at 17:00
  • The 1st - vulnerable cipher - is under the control of the SSL implementation/handshake, not the certificate. – garethTheRed Feb 11 '19 at 17:29
  • We could start with a website and go from there (as detailed in the question) - but many of the browsers use the same underlying libraries. OpenSSL and GnuTLS probably account for most of the web traffic on the internet. – Mikey T.K. Feb 11 '19 at 17:30
  • @MikeyT.K. - Chrome, Firefox, and Edge all throw certificate errors due to different conditions. Some simply have stricter rules. – Ramhound Feb 11 '19 at 18:41
  • This answer suggests there is an order of precedence ... security.stackexchange.com/a/97176/70929 ... although I don't know the source of this information. The only other reference I can find is this one... sites.google.com/site/ddmwsst/digital-certificates#TOC-Purpose ... which suggests that each certificate in the chain is assigned a status code, and that the status code with the highest precedence is taken as the certificate chain status. I can't seem to find the status codes, but presumably there is a defined ordering if it has translated into rankable status codes. – Dallas Feb 11 '19 at 19:03
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.
| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.