skip to content

In a TLS handshake, which peer proves its identity by default, and what does mutual authentication add?

level: juniorimportance: must knowfreq 62%

answer

  1. one direction by default
  2. server proves, client only watches
  3. identity settled before the first byte
  4. CertificateRequest makes it two-way
  5. client answers with Certificate and CertificateVerify

basics

~20 s

An ordinary TLS handshake authenticates only the server: it sends a certificate and a signature proving it holds the matching private key. Mutual authentication adds a client certificate and signature, so both peers prove identity before any application data flows.

solid answer

~40 s

In an ordinary handshake the server sends a `Certificate` message carrying its chain and a `CertificateVerify` signature proving it holds the matching private key; the client verifies both and stays anonymous at the TLS layer. Anything the server learns about who is calling comes later, from an application credential carried inside the encrypted channel. Mutual authentication moves that proof into the handshake: the server sends a `CertificateRequest`, and the client answers with its own `Certificate` and `CertificateVerify` over the same transcript. The connection then either comes up with a verified peer identity or does not come up at all, which is why it suits machine-to-machine links such as a crane's control link to a terminal management system, where no operator is present to type a password or click through a warning.

code

pseudocode · 12 lines
pseudocode
// TLS 1.3, server asking the client to authenticate
client -> server: ClientHello
server -> client: ServerHello
server -> client: EncryptedExtensions
server -> client: CertificateRequest      // only present when client auth is wanted
server -> client: Certificate
server -> client: CertificateVerify
server -> client: Finished
client -> server: Certificate             // the client's own leaf
client -> server: CertificateVerify       // signs the transcript so far
client -> server: Finished
// application data may now flow, with both peers named

go deeper

for a junior

Recall the direction: by default only the server presents a certificate and proves it holds the key. Mutual authentication means the client does the same thing, inside the handshake, before any request is sent.

for a middle

Explain the mechanics: the server adds a CertificateRequest, the client answers with Certificate and CertificateVerify, and the signature covers the handshake transcript so it cannot be replayed on another connection.

for a senior

Show what it buys operationally. A caller with no acceptable certificate never reaches the application, so there is no unattributed connection to reason about and no credential to rotate inside the payload.

for a principal

Frame the trade. Certificates in the handshake move the identity problem into issuance and renewal, and an expired client certificate is an outage rather than a login prompt, so the decision is really about which failure mode the estate can absorb.

## The default shape of a handshake TLS is not symmetric by default. The server sends a `Certificate` message carrying its end-entity leaf and the intermediates a peer needs to build a path, and a `CertificateVerify` message containing a signature over the handshake transcript so far. Those two messages prove two different things: - that some authority the client already trusts issued a certificate for the name the client dialled; - that whoever is on the other end of **this** connection holds the private key matching that certificate. The client checks both, sends `Finished`, and the channel opens. At no point in that flight is the client asked for anything. So at the moment the first application byte moves, the server knows exactly nothing about who is calling. Every identity it eventually acts on arrives afterwards, inside the encrypted channel, as application data the server itself must parse and validate. ## What mutual authentication changes Mutual authentication moves the client's proof into the handshake itself. The server includes a `CertificateRequest` message in its flight, and the client answers with the same two message types the server sent: a `Certificate` carrying its own leaf, and a `CertificateVerify` signing the transcript with the private key for that leaf. The server verifies the chain and the signature exactly as the client verified its own. The consequences are structural rather than cosmetic: - **The identity exists before the first application byte.** There is no window in which a connection is open but unattributed. - **A failure is a refused connection, not a rejected request.** A caller with no acceptable certificate never reaches the application layer at all. - **The private key never travels.** What crosses the wire is a signature over the transcript, not the secret itself, so a recorded exchange yields nothing reusable. - **The proof is bound to this connection.** Because the signature covers the handshake transcript, which includes values freshly chosen by both peers, a captured `CertificateVerify` cannot be replayed onto a different connection. - **Both peers can still fail independently.** The client verifying the server and the server verifying the client are two separate checks; passing one says nothing about the other. ## Who proves what | | server-only handshake | mutual handshake | |---|---|---| | server sends | `Certificate`, `CertificateVerify` | `Certificate`, `CertificateVerify`, `CertificateRequest` | | client sends | no certificate at all | `Certificate`, `CertificateVerify` | | server knows the caller | not until an application credential arrives | when the handshake completes | | a bad credential shows up as | an application-level rejection | a handshake that never completes | ## Why an unattended link reaches for it A crane's control link to a terminal management system has no human at either end. Nobody can be prompted for a password, and nobody can be shown a warning to click through. That rules out the usual fallback in which a questionable connection is allowed and a person is asked to judge it. Certificate authentication in the handshake fits because the decision is mechanical and final: either the peer produced a valid signature under a certificate the other side is willing to accept, or the connection is torn down. It also removes a long-lived shared secret from the application protocol. A password or an API key in the payload has to be stored on the crane side, transmitted on every request, and logged nowhere by accident. A private key sits in one place and only ever produces signatures. ## What it does not give you Three limits are worth naming, because candidates routinely overstate the result: 1. **It is not encryption.** Both handshakes produce exactly the same protected channel; mutual authentication adds an identity, not a second layer of protection. 2. **It is not an authorisation decision.** Knowing which certificate holder is calling does not say what that holder may do; that mapping belongs entirely to the service. 3. **It is not new.** Client certificates exist in TLS 1.2 as well as TLS 1.3. What TLS 1.3 changes is that the client's `Certificate` and `CertificateVerify` travel inside the encrypted part of the handshake, so a passive observer no longer sees which client certificate was presented. The short version an interviewer wants: by default the server proves itself and the client watches; mutual authentication makes the client answer the same way, and it does so early enough that no unidentified connection ever reaches the application.

  • Once a mutual handshake completes, what exactly has the server learned about the caller?
    Two facts and no more: the caller presented a certificate chain the server was willing to accept, and it holds the private key for that leaf, because it signed this connection's transcript. What that holder is permitted to do, and even which of several holders it is, are decisions the service makes afterwards from the name in the certificate.
  • Does mutual authentication make the channel more confidential than a normal handshake?
    No. Record protection is identical either way; the negotiated cipher and the derived traffic keys do not change because a second certificate was exchanged. What changes is that the peer is named. Treating it as extra encryption is the most common misreading, and it leads people to skip it on links that already carry an application credential, which is the opposite trade.
  • Why is a refused connection often preferable to an application-level rejection on an unattended link?
    Because nothing downstream has to cope with an unidentified caller. There is no partially handled request, no half-built session and no audit entry attributed to nobody. The failure is also unambiguous to whoever investigates: the link never came up, and the reason is in the handshake rather than scattered across application logs.

A doorman shows you his employer's letter of introduction but never asks for yours: you now know whose house it is, and the house still has no idea who walked in.

saying these in an interview costs you the question

  • Thinks an ordinary TLS handshake already authenticates the client
  • Says mutual authentication encrypts the traffic a second time
  • Believes client certificates are a TLS 1.3 feature only
  • Treats a verified client certificate as an authorisation decision
  • Assumes the client's private key is sent to the server to be checked