10

I read this article, but I did not understand how and when the client's certificate is actually used to do anything.

As far as I understand, "normal" TLS works like this:

  1. Some unencrypted handshake shenanigans
  2. Server sends their certificate, basically their trusted public key
  3. Client encrypts a symmetric key with the server's public key
  4. Client sends over the encrypted symmetric key
  5. Now client and server can communicate privately via the shared symmetric key

When a client certificate is used, it starts like this:

  1. Some unencrypted handshake shenanigans
  2. Server sends their certificate, basically their trusted public key
  3. Client sends their certificate, basically the client's trusted public key
  4. ???

Now what? What does the server do with the client's public key?

One way it could work, I suppose, is that from now on the client encrypts all messages with the servers public key and the server encrypts all messages with the client's public key. In this case, no symmetric key would have to be generated.

Improve this question
2
  • The server does the same with my certificate as the client does with the server's certificate: It's checked if it's valid. Commented Mar 10, 2021 at 10:14
  • @MechMK1 please go into more detail. The validity check the server performs is done by decrypting the signature in the cert with the CA's public key. But this is completely pointless if from here on the client's public key is never used, because anyone could have sent the client's certificate to the server. Commented Mar 10, 2021 at 10:18

3 Answers 3

Reset to default
5

The client proves possession of the private key by signing a hash of the TLS handshake. The relevant section of RFC 5246 is 7.4.8, and a plain English explanation can be found here. So the communication is, roughly:

  1. Client sends hello
  2. Server sends hello, including server certificate chain and list of accepted client certificate issuers
  3. Client sends certificate
  4. Client sends key exchange message
  5. Client sends certificate verify, a signature over all previous steps

Server then verifies that the signature is correct and the certificate is valid. So now the server can be sure the client is in possession of the private key and proceeds to match the CommonName, or a specified SAN field (e.g. DNS, RFC822, UPN) against its user database.

Improve this answer
1
  • So the server uses the client's public key (from the client certificate) to decrypt the encrypted hash. If the decrypted hash matches the hash of the previous steps, this proves the client is in possession of the private key associated with the client certificate. Perfect answer, straight to the point. Thank you! Commented Mar 11, 2021 at 13:26
5

The reason you want to use a client certificate is for additional authentication.

The handshake works a bit like this:

  1. The client sends the ClientHello.
  2. The server replies with the ServerHello, which includes that the server wants to see a certificate from the client. Optionally, the server also includes details on which certificate authority the client certificate should be signed by. This is useful for clients automatically selecting the correct certificate out of many, but clients are free to ignore this.

What happens now depends on how the server is configured. There are several possibilities:

1. The server expects a certificate signed by a specific Certificate Authority.

The server has the certificate of a certificate authority (usually an internal one) and the server checks whether or not the certificate sent by the client was signed by this certificate authority.

This means that any client who does not possess a certificate signed by this specific (internal) Certificate Authority cannot make a connection to the server.

2. The server offers an optional client certificate.

This means that the client can send a client certificate, but the connection is not aborted if no client certificate is sent. Usually, in such cases, the certificate data (or lack thereof) is passed onto the application layer for processing.

For example, access to example.com does not require a client certificate, but access to example.com/admin/ does require a client certificate. Parsing of the URL path can however not be done purely through TLS and requires a HTTP server. So all the TLS library can offer is an optional certificate and the HTTP server needs to determine if it's valid and if the path requires it.

3. The client sends the wrong client certificate

For example, the server may require a client certificate signed by Example Corp. Root CA, but the client sends a client certificate signed by Attacker Corp. Internal CA. The server doesn't care about that, and rejects the certificate and ends the connection.

Also it should be noted that when I say a participant "sends a certificate", it's not just the certificate they send. There is also a validation that the participant possesses the associated private key.

Improve this answer
3
  • 1
    Thank you. I believe this answer lacks the critical step of how the server checks whether the client is the owner of the client certificate. Sending over the file is not proof, anybody could have the certificate file. The accepted answer addresses this issue. Commented Dec 17, 2021 at 11:41
  • 2
    @actual_panda It's probably a case of knowledge blindness from my side, where I assumed that this was self-evident. But you're right, the accepted answer explains it better. Commented Dec 17, 2021 at 12:15
  • Anyway, this answer adds very useful additional information. +1 Commented Mar 29 at 17:32
-1

anyone could have sent the client's certificate to the server

That's correct. Server behavior on client certificate is nearly the same:

  1. server validates the certificate (according to RFC5280 §6 rules) and then
  2. attempts to bind the certificate to a user account in some directory to authenticate by using information embedded in client certificate. For example, use UPN (User Principal Name) name type in client certificate's Subject Alternative name extension. This is how client certificate-based authentication works in Microsoft Windows (IIS, smart card logon, RADIUS, etc.).

If server finds such principal in account directory (for example, Active Directory), certificate is bound to the user account and client is identified and authenticated, otherwise server rejects client certificate and client remains anonymous. Server can add extra validation rules if necessary.

Of course, for client certificate authentication server must have a kind of account directory to authenticate client with.

One way it could work, I suppose, is that from now on the client encrypts all messages with the servers public key and the server encrypts all messages with the client's public key. In this case, no symmetric key would have to be generated.

it doesn't going to work, because asymmetric encryption is slow and computationally complex and doesn't provide security features such as PFS (perfect forward secrecy) and others. This is why you need symmetric session key, which is much faster and can be periodically rotate (in much shorter time span than asymmetric keys).

Improve this answer
3
  • Sorry I still don't understand how just checking certificate validity and then binding it to the account improves security when anybody could have the client's certificate (it's public after all) and then log into that account. Is the client's public key that's in the certificate never used in TLS? Commented Mar 10, 2021 at 10:42
  • 1
    Client certificate-based authentication is about client identification and authentication on a server, not TLS transport security. TLS security alone is accomplished with server certificate. Commented Mar 10, 2021 at 10:44
  • 1
    @actual_panda Because you also need the corresponding private key. Commented Mar 10, 2021 at 10:45

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.