El servidor envía CertificateRequest con los algoritmos de firma aceptables y, opcionalmente, nombres de CA; el cliente responde con su cadena y una firma sobre la transcripción. El servidor valida la cadena con su propio almacén de confianza (normalmente, una CA privada) y asigna el certificado a una identidad, por ejemplo, un SPIFFE ID en el URI del SAN o un nombre de sujeto.
Dependen de él las mallas de servicios (Istio, Linkerd), las pasarelas de confianza cero, las redes de pago, las flotas de IoT y la autenticación de clientes con mTLS de OAuth 2.0 junto con los tokens vinculados a certificados (RFC 8705). El vínculo con el certificado solo se mantiene de extremo a extremo: un proxy que termina TLS debe reenviar la identidad verificada del cliente en un encabezado de confianza.
Los certificados TLS públicos ya no sirven como fuente de certificados de cliente: el programa raíz de Chrome exige EKU solo de servidor, y las CA públicas dejaron de emitir clientAuth en certificados TLS en 2026. Usa una CA privada con certificados de corta duración.