SSL certificates and cipher suites correspondence

Question

I have been learning about the SSL/TLS protocol (from https://tools.ietf.org/html/rfc5246) and have a few conceptual questions about the protocol.

1. The client and server exchange "hello" messages during which they choose the SSL/TLS version and the cipher suites. More specifically, the client suggests a list of cipher suites and the server picks one (If the server does not pick anything, the handshake fails). Now, does the server choose the cipher suite corresponding to the ones used in the certificate?

   For ex: running openssl x509 -in <server_cert>.pem -text -noout gives you information about the server certificate. On a sample certificate, I see that the public key algorithm is rsaEncryption (2048bit) and the signature algorithm is sha256WithRSAEncryption. Doesn't this already predetermine part of the cipher suite used in the handshake?

2. Let us suppose that the server and client agree upon a cipher suite. Now, I also see that clients can also present a certificate later in the handshake. Does that mean that the ciphers on the client certificate must be compatible with the cipher suite chosen?

   (Similar question, but does not answer what I want: Picking cipher suites for HTTPS)

Answer 1

For the server certificate: the cipher suite indicates the kind of key exchange, which depends on the server certificate key type. You basically have the following:

• For TLS_RSA_* cipher suites, key exchange uses encryption of a client-chosen random value with the server's RSA public key, so the server's public key must be of type RSA, and must be appropriate for encryption (the server's certificate must not include a Key Usage extension that says "signature only").

• For TLS_DHE_RSA_* cipher suites, key exchange uses an ephemeral Diffie-Hellman, and the server signs its part of the DH key exchange with its RSA key. So the server's public key must be of type RSA, and must be appropriate for signatures (there again, the certificate must not restrict the key usage to only encryption).

• TLS_DHE_DSS_* and TLS_DHE_ECDSA_* cipher suites use an ephemeral Diffie-Hellman key exchange, and the server's key must be of type, respectively, DSA and EC, and must be appropriate for signatures.

• TLS_ECDHE_* cipher suites are similar to TLS_DHE_* cipher suites, except that the Diffie-Hellman key exchange is an elliptic curve variant. Conditions on the server's certificate remain the same.

• TLS_DH_* and TLS_ECDH_* cipher suites are different (mind the lack of 'E' after the 'DH'). For these suites, the server's certificate directly contains a Diffie-Hellman public key (or an elliptic curve variant thereof), and the cipher suite then qualifies the algorithm used by the issuing CA to sign the certificate. For instance, TLS_DH_RSA_* means "server has a DH public key stored in a certificate that was signed by some CA with RSA". This is the only case where the signature type on the certificate has any relation with the cipher suite. Since in practice nobody uses that kind of certificate, this case can be neglected.

For the client certificate: the client presents a certificate when the server asks for it. The client certificate type has no relation whatsoever with the cipher suite (except for the extremely rare case of static DH certificates, but I have never seen that used in practice). The client certificate must be appropriate for signatures. As part of the handshake message that requests a client certificate, the server sends some information about the supported algorithms (see the standard). In fact, TLS 1.2 further expands that mechanism by giving a flexible list of supported algorithm and hash function combinations.

Answer 2

UPDATE (since this is linked, upvoted and search-optimized):

In TLS 1.3, released in 2018 and actually used pretty widely by 2020 (faster than earlier updates of TLS spread), the ciphersuite no longer controls the server cert or the keyexchange method.

Instead the key type in the server cert (used for protocol signature) is controlled (always) by the signature_algorithms extension in ClientHello (introduced as optional in 1.2, as I commented on the ursine answer), and the signature(s) on the server cert and any chain cert(s) are controlled by a new optional extension signature_algorithms_cert if used and otherwise by signature_algorithms. And DSA aka DSS is no longer permitted at all.

And except for a PSK option used to replace session resumption, key exchange always uses ephemeral Diffie-Hellman (no more plain-RSA key encryption, or static DH) using either classic/integer/modp/Z_p groups (now called Finite-Field DH, FFDH, for clarity) or elliptic-curve groups (ECDH), specified by the modified supported_groups (originally supported_curves for EC only) and new key_share extensions.