Client Authentication in SSL Handshake

Question

I am trying to understand how client certificate authentication works in an SSL handshake. Can someone help to clarify the following bullet points below:

1. Do we need to have a Client Leaf certificate in Server truststore? Is it referred to at any given time during the two-say SSL handshake process? What if it is present, will it be ignored?

2. In server Hello message there is a certificate_list message. This contains a list of CA or Inter CA which would have a signed client certificate. Clients will check this list and only send client certificate if its signed by CA or Inter CA present in the list. Is this understanding correct?

3. Once the client sends the client certificate to server, the server will check if it's signed by a known CA (CA present in certificate_list in server hello), if that's the case then server is sure that the certificate name (cn) in certificate is legitimate. However at this point the server is unsure if the client has a private key of the client certificate or not (could be that the client has got a client certificate through an illegitimate way), hence server expects the certificate_verify message from client. That message is signed by the private key of client and since server is able to decrypt that message through the public key of client (which the server received in an earlier message through the Client Certificate) the server can now confirm Client is what it claims to be. Is this correct?

4. What is the content of the certificate_verify message ?

5. In this case how servers differentiate between clients. Do servers check client CN and accept and reject client based on that? Without this the server will accept all clients if they have legitimate certificate, right?

Answer 1

I believe you have some misunderstading about the exact steps happening when Client Authentication takes place. I will try to answer your questions:

#1 Do we need client certificate in the server's TrustStore?

Not necessarily, the client certificate could have been signed by a CA the server trusts and it will be trusted. There's nothing fancy here, you could imagine a company having their own PKI and each employee/device has a personal certificate signed the internal CA.

#2. Clients use the "certificate_list" in the ServerHello message to send the right certificate

No. This is not what happens. ServerHello is used so the 2 parties can negotiate the ciphers suite, restart a previous session, share random values, etc. ServerHello is sent and then followed by the Certificate message, which includes the server certificate, and the certificate chain (each certificate certifying the precedent.)

If a server requires a client to authenticate, it will then send another message named CertificateRequest. This message does indeed have a list of acceptable CA.

certificate_list is just a technical structure the RFC specify.

I believe you misunderstood the different steps and merged all into a single ServerHello message.

#3 CertificateVerify is used to verify that the client does indeed own the private key.

Yes. The client takes all the messages that were previously exchanged, hashes them, and sign them (with their private key.) The server can now verify and determine that the client does indeed own the associated private key.

#4 What is the content of CertificateVerify?

Answer #3 also answers your question #4, even though I believe it is possible to only hashes somes of the message. (Not all.)

#5 How does the Server differentiate the different clients?

The server doesn't really care about that when establishing a TLS handshake. Other mechanisms can complement it and detect/prevent simultaneous usage of the same certificate.

Summary of the different steps

Here's a summary of the different steps taking place in a TLS handshake where both the server and the client authenticates. This is not an in-depth look at it, a lot of (sometime important) details will be overlooked as they doesn't really impact your question. Wireshark could show you a more verbose message flow.

1. ClientHello
The Client initiates the connection, shares some random value and shares the algorithms they can work with.

2. ServerHello
The Server choses the algorithms from the ones provided by the Client (and the ones it can use) and also shares its own random value.

3. Certificate
The Server shares its certificate with the certificate chain (the chain optional.)

4. CetificateRequest
The Server requests a certificate from the Client. It also specify a list of acceptable CA.

5. ServerHelloDone
The Server indicates it has done his side of the handshake

6. ClientCertificate
The Client shares its certificate

7. CertificateVerify
The Client proves that they own the associated private key by sending a signed hash of all the previous messages concatenated. (Concatenate, then hash, then sign.)

8. Finished
The Client tells the Server it has finished their side of the handshake.
The Server will confirm with a Finished message if no additional action is necessary