O servidor envia CertificateRequest com os algoritmos de assinatura aceitos e, opcionalmente, nomes de CAs; o cliente responde com a sua cadeia e uma assinatura sobre a transcrição. O servidor valida a cadeia contra o próprio trust store (em geral, uma CA privada) e associa o certificado a uma identidade, por exemplo, um SPIFFE ID na URI do SAN ou um nome de titular (subject).
Dependem dele as service meshes (Istio, Linkerd), os gateways zero trust, as redes de pagamento, as frotas de IoT e, no OAuth 2.0, a autenticação de cliente por mTLS e os tokens vinculados a certificado (RFC 8705). O vínculo com o certificado só sobrevive de ponta a ponta: um proxy que termina o TLS precisa repassar a identidade verificada do cliente em um cabeçalho confiável.
Os certificados TLS públicos deixaram de ser uma fonte de certificados de cliente: o programa de raízes do Chrome exige EKUs só de servidor, e as CAs públicas pararam de incluir clientAuth nos certificados TLS em 2026. Use uma CA privada com certificados de curta duração.