Le serveur envoie CertificateRequest avec les algorithmes de signature acceptés et, facultativement, des noms d’AC ; le client répond avec sa chaîne et une signature sur la transcription. Le serveur valide la chaîne par rapport à son propre magasin de confiance (généralement une AC privée) et associe le certificat à une identité, par exemple un SPIFFE ID dans l’URI du SAN ou un nom de sujet.
Les maillages de services (Istio, Linkerd), les passerelles zero trust, les réseaux de paiement, les parcs d’objets connectés ainsi que l’authentification client mTLS d’OAuth 2.0 et les jetons liés à un certificat (RFC 8705) s’appuient dessus. La liaison au certificat ne tient que de bout en bout : un proxy qui termine TLS doit transmettre l’identité vérifiée du client dans un en-tête de confiance.
Les certificats TLS publics ne sont plus une source de certificats clients : le programme racine de Chrome exige des EKU réservés au serveur, et les AC publiques ont cessé d’émettre clientAuth dans les certificats TLS en 2026. Utilisez une AC privée avec des certificats de courte durée.