Mutual TLS (mTLS)
Mutual TLS authenticates both ends of a connection with certificates, giving services a cryptographic identity that works without shared secrets or user context.
Definition
Mutual TLS is a TLS handshake in which the client and the server both present X.509 certificates, so each side can verify the other's identity against a trusted certificate authority before any application data is exchanged.
Context and scope
Use it for service-to-service traffic, zero-trust networks, B2B integrations, and device authentication where both parties can manage certificates.
Common misconceptions
- mTLS authenticates end users; it authenticates workloads or devices holding the certificate
- Terminating TLS at a load balancer preserves client identity; the backend must receive and trust that identity explicitly
- Certificates never need rotation once the handshake works
Anti-patterns
- Sharing one client certificate across every service, destroying attribution
- Validating the certificate chain but ignoring the identity in the subject or SAN
- Using long-lived client certificates with no revocation or expiry monitoring
Related concepts
Related examples
Authoritative source
Two certificates, one handshake
In ordinary TLS only the server proves its identity. With mutual TLS the client also presents a certificate, and the server verifies it against a trusted CA. The result is a mutually authenticated channel where each side has a cryptographic identity rather than a shared password.
How it works
The client connects, the server presents its certificate, and the client validates the chain and hostname. The server then requests a client certificate. The client proves possession of the matching private key, and the server checks the chain, expiry, revocation status, and allowed identities. In TLS 1.3 the client certificate is sent after the handshake, encrypted under the session keys.
Platforms often map the certificate subject or SPIFFE ID to a workload identity, then authorize requests from that identity. Short-lived certificates, issued by an internal CA and rotated automatically, limit the value of a stolen key.
When to use it
mTLS fits east-west traffic inside a service mesh, partner APIs where both sides run infrastructure, and device fleets that can hold keys in secure storage. It is a strong fit for zero-trust designs because identity travels with the connection and does not depend on network location.
Trade-offs
Running a PKI is real work: issuance, rotation, revocation, and trust bundle distribution. Client certificates are awkward for browsers and public clients, and mobile apps can have keys extracted on compromised devices. When a proxy terminates mTLS, the backend sees an ordinary connection, so the proxy must forward a verified identity and the backend must trust only that path.
Example and misconceptions
A payment service accepts connections only from clients presenting certificates issued by its internal CA with a SPIFFE ID in the expected trust domain. A stolen database password no longer helps an attacker reach it, because the connection itself fails without a valid certificate.
The common misconception is that mTLS authorizes actions. It authenticates the connection; authorization still needs policy that maps the identity to allowed operations.
Related concepts: TLS, Zero Trust, and Certificate Pinning.