Mutual TLS
Mutual TLS authenticates both ends of a connection with certificates, giving service-to-service identity beyond the transport layer.
Definition
Mutual TLS (mTLS) extends standard TLS so that the client and the server both present certificates and verify each other. The server proves its identity as usual, and the client proves its own, so the server can authorise the caller based on cryptographic identity rather than a shared token. Identity is carried in the certificate subject or SAN, enabling policy per service. It is the basis for zero-trust service meshes and for authenticated internal APIs.
Context and scope
Used for service-to-service authentication inside a cluster or across a private network, and for mTLS-enabled API gateways that require client certificates.
Common misconceptions
- mTLS replaces application authorisation — it authenticates identity at the transport; authorisation for specific actions is still application logic
- Certificates never need rotation — they expire, so rotation must be automated or services fail together at expiry
- Any certificate is acceptable — verification must check the chain and identity, or a self-signed certificate grants anyone access
Anti-patterns
- Disabling certificate verification to make a connection work, which defeats the entire mechanism
- Issuing long-lived certificates that outlive their services and cannot be revoked quickly
- Using one shared client certificate for every service, erasing the identity mTLS was meant to provide
Related concepts
Authoritative source
What it is
In ordinary TLS the server presents a certificate and the client checks it; the client stays anonymous. Mutual TLS adds the reverse: during the handshake the server also requests and verifies a client certificate, reusing the same PKI machinery. Once connected, both sides hold a verified identity, and the server can map the client certificate subject or SAN to a service account, replacing bearer tokens and shared secrets with cryptographic proof.
Why it matters
A token inside a network can be replayed by anything that can read it; a certificate private key is far harder to clone and can be bound to a workload identity. This makes mTLS the natural mechanism for zero-trust internal communication, where every call is authenticated regardless of network location. It also removes the operational burden of distributing and rotating shared secrets between services.
How to use it well
Automate the full certificate lifecycle — issuance, distribution, and rotation — because manual rotation is how expiry becomes an outage. Verify the chain and the expected identity, never merely that a certificate exists, and keep a revocation path for compromised keys. Reuse mTLS for transport identity and layer application-level authorisation on top, so identity and permission stay separate concerns with separate failure modes.