Der Server sendet CertificateRequest mit den zulässigen Signaturalgorithmen und optional CA-Namen; der Client antwortet mit seiner Zertifikatskette und einer Signatur über das Transkript. Der Server validiert die Kette gegen seinen eigenen Trust Store (meist eine private CA) und ordnet das Zertifikat einer Identität zu, zum Beispiel einer SPIFFE-ID in der SAN-URI oder einem Subject-Namen.
Service Meshes (Istio, Linkerd), Zero-Trust-Gateways, Zahlungsnetze, IoT-Geräteflotten sowie die mTLS-Client-Authentifizierung und zertifikatsgebundene Tokens von OAuth 2.0 (RFC 8705) bauen darauf auf. Die Zertifikatsbindung bleibt nur Ende-zu-Ende erhalten: Ein Proxy, der TLS terminiert, muss die geprüfte Client-Identität in einem vertrauenswürdigen Header weiterreichen.
Öffentliche TLS-Zertifikate sind keine Quelle für Client-Zertifikate mehr: Das Root-Programm von Chrome verlangt EKUs, die nur die Server-Authentifizierung erlauben, und öffentliche CAs haben 2026 aufgehört, clientAuth in TLS-Zertifikaten auszustellen. Nutze eine private CA mit kurzlebigen Zertifikaten.