mTLS
Mutual TLS — both client and server present X.509 certificates. The animation shows the handshake echoing both ways, with both nodes badged ⊕CERT. After ClientHello+ClientCert, ServerHello+ServerCert, CertVerify both directions, Finished, the tunnel is mutually authenticated.
Animation
Engineering pitfalls
Client certificate revocation checking
OCSP and CRL must be reachable from your server to validate the client cert. If revocation check fails (network, OCSP responder down), most stacks fail-open — accepting revoked certs. Configure fail-closed in production.
Certificate-pinning rotation breakage
Pinning the cert SPKI in client config means rotating the cert requires coordinated rollout. Pin the issuing CA's SPKI instead, OR use short-lived certs (24h) with automated rotation.
Workload identity in service mesh
SPIFFE/SPIRE assigns workload identities via mTLS. If your sidecar can't reach the SPIRE server at startup, the workload starts with no identity = denied. Pre-load identities or bootstrap from a trusted-token.
References
Primary sources
- RFC 8705 — OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens.
- RFC 5246 — The Transport Layer Security (TLS) Protocol (mTLS extension semantics).
- SPIFFE specification — Secure Production Identity Framework for Everyone.