Mutual TLS: two identities, two trust decisions, and the authorisation that comes after

In mutual TLS the server asks the client for a certificate too, and each side decides on its own whether to trust what it was shown. How the request travels in a TLS 1.3 handshake, what the server may do when the certificate is missing or unacceptable, why HTTP/2 and HTTP/3 rule out asking later, and why a valid client certificate authenticates a connection without deciding what that client may do.

Ordinary TLS authenticates one side: the server presents a certificate, the client checks it, and the client stays at the TLS layer. Mutual TLS adds the other direction. The server asks the client for a certificate as well, and the connection is established only when each side has decided, independently and by its own policy, whether to trust what the other presented. The phrase "two identities, two policies" is the whole design: there are two certificates, two sets of trust anchors, two verification decisions, and then a third decision that TLS does not make at all.

How the server asks

In TLS 1.3, a server that authenticates with a certificate may also request one from the client. It does so with a CertificateRequest message, sent after EncryptedExtensions, which must list the signature algorithms the server accepts and may carry a certificate_authorities extension naming the certificate authorities, trust anchors or intermediate CAs, the client's certificate should chain to (RFC 9846, sections 4.4.2 and 4.3.4). That list guides the client's choice when it holds several certificates; it is not itself a trust decision. The client answers with its Certificate message and a CertificateVerify that proves it holds the private key (RFC 9846, section 4.5).

What the server may do when it does not like the answer

The protocol leaves the outcome to the server. If the client sends an empty Certificate message, the server may continue the handshake without client authentication or abort with a certificate_required alert; if the chain is unacceptable, for example not signed by a trusted , the server may either continue and treat the client as unauthenticated, or abort (RFC 9846, section 4.5.1.3). That is why products expose a choice between requesting and requiring a client certificate, as BIG-IP's peer-cert-mode does, and why "the handshake completed" is not evidence that the client was authenticated: in the permissive mode it completes either way, and the application has to check the result.

What "acceptable" means is ordinary certificate path validation, the same steps described in how certificate validation works, run by the server against its own trust anchors. One check is specific to this direction: a certificate restricted by the extended key usage extension has to permit client authentication, id-kp-clientAuth, to be used for it (RFC 5280, section 4.2.1.12).

Asking later is ruled out on HTTP/2 and HTTP/3

TLS 1.3 also defines post-handshake authentication: a client that offered it can be asked for a certificate at any time after the handshake (RFC 9846, section 4.7.2). It looks like the natural way to require a certificate only for one part of a site. The two multiplexed versions of HTTP forbid it: servers must not send post-handshake CertificateRequest messages, even when the client offered post-handshake authentication (RFC 9113, section 9.2.3), and QUIC servers must not use post-handshake client authentication at all, because with many requests multiplexed on one connection the client cannot tell which request the certificate request belongs to (RFC 9001, section 4.4). Over those versions, then, the decision to ask for a client certificate is made when the connection is set up, so a service that needs client certificates on only some of its paths has to separate them at that level, for example by giving them their own host name.

Authenticated is not authorised

A client certificate that validates proves one thing: whoever is at the other end holds the private key of a certificate issued, directly or through intermediates, by a CA this server trusts for client authentication. It does not say what that client may do. Many certificates can chain to the same accepted CA, and an operation still needs a decision: which identity in the certificate the application uses (a subject name, a subject alternative name), which account or role that identity maps to, and whether that role may perform this request on this resource. A partner with a valid certificate and read permission is still refused a write. Keeping those two steps separate in design and in logs is what makes an access failure readable: "the handshake failed" is a trust-anchor or certificate problem, while "the request was refused" is a mapping or permission problem.

Where termination moves the decision

Mutual TLS authenticates the endpoint that terminates TLS. When a reverse proxy offloads or re-encrypts the session, the proxy is the server that validated the client certificate, and the backend sees a different connection; whatever the backend learns about the client then comes from the proxy, not from the client's handshake. The trade-offs of offload, bridging and passthrough for client certificates are covered in inbound TLS at the reverse proxy.