Mutual TLS - with self-signed client certs - what is the security purpose of a client private key in addition to client cert?

Question

In mutual TLS, during client-authentication phase, a client proves its identity to the server by sending its client certificate (Certificate message). Additionally, it signs all previous handshake messages using its private key and sends the resulting hash (CertificateVerify message). Server uses this hash to validate client's ownership of the certificate.

What is the security benefit of the doing CertificateVerify validation above? How cert can be compromised while key can't?

A typical key storage/management logistics for client key+cert is "bundled". Usually, when server issues client certificate to a particular client - it supplies key+cert (often bundled into a single P12 or PFX file, or PEM file with both parts concatenated), and all client APIs (OpenSSL, curl, Node.js request, etc.) expect both key and cert to be supplied. Therefore, a client reasonably deals with key and cert local storage/protection the same way.

Since they're typically bundled - what benefit/reason there is for key-verification of a cert? Why supplying just cert would not be good enough?

Official definition and reasoning (which is not convincing to me, per the above):

• https://en.wikipedia.org/wiki/Transport_Layer_Security#Client-authenticated_TLS_handshake
• https://security.stackexchange.com/a/141050/249969

EDIT (to emphasize the client cert is self-signed by the server):

It is clear that for well-known-CA signed client certificates, key is indeed required. That's because in such case - client's cert is publicly known.

However, in most real-life cases I saw - the server is a well-known entity, while clients are not (or the server doesn't care if they are, and still issues, and expects to get, self-signed certs of its own). Since clients are not well-known entities - arranging a well-known-CA registration for each client - is not practical. In other words, the server issues the key+cert. And then - the question is - is there still any security benefit of supplying key-verified hash, in addition to cert during mTLS client auth?

Does it only exist in the protocol to cover the case when client cert is issued by a well-known-CA, i.e. for cases when client cert is protected differently than key? Or there's some solid reason for key in self-signed scenario as well?

Answer 1

I think you need to do some reading on what a certificate is. At it's core, a certificate is an attestation from the Certificate Authority (CA) to bind together the following information:

• Name (DN or SAN)
• Public key

Think of it like a driver's license that "binds together" your name, birthdate and photo. Imagine you hand your ID to a bouncer; alright, so they know that somebody has that name and birthdate, but to prove that it's you, you have to show your face and let the bouncer verify that it matches the photo. Mailing someone a photocopy of a driver's license does not actually prove that you are the person named on the ID.

Similarly, when you authenticate to a server using a client certificate, you are proving your identity in the following way:

• Provide a public key.
• Perform an operation that could only have been done with the matching private key, thus proving that you are the owner of that public key.
• Provide a CA-signed certificate binding that public key to your name, thus proving that you are the person named in that certificate.

---

Update addressing comments

Yes, you really need to use the private key, even if the client cert is self-signed, even if it's issue by a private CA.

Sending a client cert without using the private key is like showing your ID to a bouncer without showing your face. You need to use the private key in order to prove that you are the owner of the public key in the certificate. In digital security we call this a "replay attack" because if all you needed to do was show your certificate, then once you've shown it to one server, that server could impersonate you to another server (or an admin of that site could impersonate you). Public key cryptography solves this because you only share your public key (which is inside the certificate) and keep the matching private key to yourself. If you're not using any of the cryptography in a certificate, then why go through the effort? Why not have users log in with username/password; that would be much simpler and get you the same security properties.

Answer 2

You want to treat the certificate like a password: the issuing authority, the legitimate server and the client would all have to keep it secret. This has many downsides, the biggest of which is that the server needs to keep a big database with all the clients' secrets. This database needs to be replicated and backed up so that clients don't lose access if the server is destroyed (hardware failure, operator error, etc.), but it also needs to be kept secret (against database leaks, password leaks, etc.). If multiple servers need to authenticate the same client, the security of the password is at the mercy of the weakest client.

Using asymmetric cryptography solves this and other problems. The certificate contains the public key, plus additional metadata indicating who issued that public key and in what way the issuer vouches for the client. The certificate doesn't need to be kept particularly secret: if it leaks, this may compromise the client's privacy, but it doesn't let anyone impersonate the client.

Anyone can have the certificate, but that doesn't let them impersonate the client. To impersonate the client, you need the corresponding private key. Only the client needs to have the private key. The issuing authority had to have a copy (if it wasn't generated on the client itself), but it could delete it after sending it to the client. The server does not need to know the client's private key. It doesn't even need to know the client's public key: usually, all it needs to know is that the certificate is signed by the appropriate certificate authority. Asymmetric cryptography allows the server not to store a secret value for each permitted client, and public-key infrastructure (certificates) allow the server not to even store a public value for each permitted client.

Answer 3

Other answers describe general ideas behind PKI and cert validation, but do not directly answer the question. After some research, I hope I found an answer. There is a very specific reason why CertificateVerify message with key-signed hash-validation is needed, also in case client cert is originally produced and self-signed by the server:

Client Certificate message is not encrypted(*)

(* in TLS 1.2, see note about TLS 1.3 below)

And since it's not encrypted - even if cert is kept/protected on the client side the same way as the key - the cert, when it's sent by the client as part of the handshake - is accessible to man-in-the-middle. This makes server-self-signed client cert case identical to a public-CA-signed client cert in a sense that client cert is indeed public regardless how well the client keeps it protected.

Here it is from TLS 1.2 spec (https://www.rfc-editor.org/rfc/rfc5246#section-7.3): Theoretically, it could be possible to encrypt Certificate as well, but it's not done in the TLS 1.2 spec. My personal, uneducated guess - due to a high cost of RSA encryption, and since in a more generic case (public-CA-issued client cert) - key-verification is still needed, so it wouldn't simplify/improve anything in generic mechanism, while adding costly RSA encryption during the handshake phase.

Interestingly, TLS 1.3 spec mandates handshake messages (including Certificate message) to be encrypted, but according to TLS 1.3 spec - the encryption at this stage is unauthenticated, so client cert transmission can still be accessed by main-in-the-middle, therefore cert should be protected by a mandatory PKI verification (CertificateVerify). The verification mechanism in TLS 1.3 is somewhat different, though (https://www.rfc-editor.org/rfc/rfc8446#section-2):

With TLS 1.3, the key exchange and cert-verification mechanisms are decoupled, therefore this question becomes irrelevant. To the best of my understanding - TLS 1.3 with client cert (regardless of the issuer) - requires key verification because there is nothing in TLS 1.3 key-exchange itself that protects from client being impersonated by man-in-the-middle.

Comments/corrections are welcome.

P.S.: some excellent links doing proper drill-down into the details of a handshake, both TLS 1.2 and TLS 1.3:

• TLS 1.3 walkthrough
• TLS 1.2 walkthrough
• TLS 1.3 vs. TLS 1.2