The server sends CertificateRequest with acceptable signature algorithms and, optionally, CA names; the client answers with its chain and a signature over the transcript. The server validates the chain against its own trust store (usually a private CA) and maps the certificate to an identity, for example a SPIFFE ID in the SAN URI or a subject name.
Service meshes (Istio, Linkerd), zero-trust gateways, payment networks, IoT fleets and OAuth 2.0 mTLS client authentication and certificate-bound tokens (RFC 8705) rely on it. The certificate binding survives only end to end: a TLS-terminating proxy must forward verified client identity in a trusted header.
Public TLS certificates are no longer a source of client certificates: Chrome's root program requires server-only EKUs, and public CAs stopped issuing clientAuth in TLS certificates in 2026. Use a private CA with short-lived certificates.