サーバーは、受け入れ可能な署名アルゴリズムと、任意で CA 名を指定した CertificateRequest を送信し、クライアントは自身の証明書チェーンと、ハンドシェイクのトランスクリプトに対する署名で応答します。サーバーは自身のトラストストア（通常はプライベート CA）に照らしてチェーンを検証し、証明書を ID に対応付けます。たとえば、SAN の URI に含まれる SPIFFE ID や、サブジェクト名です。
サービスメッシュ（Istio、Linkerd）、ゼロトラストゲートウェイ、決済ネットワーク、IoT デバイス群、そして OAuth 2.0 の mTLS クライアント認証と証明書に紐付いたトークン（RFC 8705）は、いずれも mTLS に依存しています。証明書による紐付けが保たれるのはエンドツーエンドの場合だけです。TLS を終端するプロキシは、検証済みのクライアントの ID を信頼できるヘッダーで転送しなければなりません。
公的な TLS 証明書は、もはやクライアント証明書の入手元にはなりません。Chrome のルートプログラムはサーバー専用の EKU を求めており、公的な CA は 2026年に、clientAuth を含む TLS 証明書の発行を終了しました。有効期間の短い証明書を発行するプライベート CA を使ってください。