PKI - certificate impact on TLS protocol

Question

I have been learning about the TLS protocol handshake process. From my understanding the TLS version is decided purely by the clients OS\browser support. And the chosen cipher suite is decided by the server (based on the available suites of the client)

I am trying to understand what part of the protocol does the certificate have impact on. I remember having chrome warning me about sha1 certificates, and forcing me to renew certificates on my server (essentially forcing me to upgrade my organization CA server)

Answer 1

From my understanding the TLS version is decided purely by the clients OS\browser support.

True for the most part. The client may start with the stronger option and retry older protocols if that doesn't match one that the server offers.

And the chosen cipher suite is decided by the server (based on the available suites of the client)

Not quite. The cipher suite is agreed between server and client. The server offers one or more that it supports which may or may not be in descending order of strength and the client will respond with the one it chooses to use;

I am trying to understand what part of the protocol does the certificate have impact on.

Certificates come into play for (mutual) authentication and key exchange. It is at the cost of certificates that you can verify whether a particular server is who they claim to be (because there is a mutually trusted CA at the top of that PKI) and also it is using certificates that you can use a client side cert as an authentication factor. Asymmetric cryptography using key pairs on the certificates is also used to negotiate a symmetric key for encrypting the communications from that point on. There's an awful lot of nuancing and variation to this method, it's quite complex and involved but in a nutshell, it's what certificates enable.

I remember having chrome warning me about sha1 certificates, and forcing me to renew certificates on my server (essentially forcing me to upgrade my organization CA server)

This has to do with the algorithm used to sign presented certificates. SHA1 has been proven to be sufficiently susceptible to collisions that has been deprecated as an safe way to produce signatures on certificates.

Answer 2

The main contributor to the agreed cipher is:

Key Algorithm

The type of key in your certificate can have an impact on your TLS cipher.

You will see many certificates with RSA keys. As such, the mutually agreed cipher suite can only include ciphers that work with RSA keys. For example, this site uses an RSA key and the cipher, as shown by OpenSSL is: ECDHE-RSA-AES128-GCM-SHA256 (note the RSA).

However, other sites don't use RSA keys and therefore the above cipher wouldn't be permitted/agreed. I've struggled to find an example, if I'm honest; but there must be one out there somewhere!

---

The following will have impact on setting up the TLS session. It won't affect the agreed cipher, but will result in a more binary success/fail.

Signature Algorithm

This won't restrict the choice of cipher, but the recent deprecation of SHA1 means clients, especially browsers, will reject a certificate (other than a self-signed) that is signed using SHA1.

Key Usage Extension

Certificates may (and most often do) contain an extension that limits the use of the keys. The list is defined in RFC 5280 section 4.1.2.3 and permits purposes at a high level, such as digitalSignature, keyEncipherment etc. If the certificate contained an incorrect value here clients should reject the certificate. For example, a CA certificate should only have keyCertSign and crlSign and therefore should not be usable to set up a TLS session (such as HTTPS).

Extended Key Usage Extension

This is similar to the previous extension, but is at a more granular level. This list is defined in RFC 5280 section 5.2.1.12. For example, two common EKUs are id-kp-serverAuth and id-kp-clientAuth. Both permit to use of the keys for authenticating the entity, but they do so in a different direction. A server certificate would be expected to have the former, while a client certificate (maybe in a TPM or smartcard etc.) would be expected to have the latter. Conforming software would be expected to reject certificates which don't have the correct EKU.