What is Mutual TLS?
Also called mTLS, Two-Way TLS, Client Certificate Authentication.
Mutual TLS is a configuration of the TLS protocol in which both parties present certificates during the handshake, so the server authenticates the client as well as the client authenticating the server. Ordinary HTTPS authenticates only the server. Mutual TLS is widely used between internal services and for high assurance API access.
In a standard TLS handshake the server proves its identity with a certificate chaining to a trusted authority, and the client stays anonymous at the transport layer, authenticating afterwards with a token or key. Mutual TLS adds a certificate request in the other direction, so the connection itself carries a verified client identity before a single application byte is exchanged.
The security gain is that the credential is never transmitted. A client proves possession of a private key rather than sending a secret, so there is nothing in the request for an interceptor or a log file to capture. Certificates also carry an identity, a validity window, and a revocation path, which makes them a richer credential than an opaque string.
The cost is certificate lifecycle management. Every client needs an issued certificate, a private key it can protect, and a renewal path before expiry. Expired client certificates are a classic cause of sudden total outages, which is why automated issuance and rotation, often through an internal certificate authority or a service mesh, is effectively a prerequisite for adopting it at scale.
Deployment details matter. Terminating TLS at a load balancer discards the client identity unless it is forwarded explicitly in a trusted header, and revocation must actually be checked rather than assumed. Mutual TLS authenticates the connection; the application still decides what that identity is authorized to do.
Key points
- Both sides present certificates during the handshake
- No shared secret travels in the request
- Certificate issuance and rotation must be automated
- Expired client certificates cause abrupt outages
- Authenticates the connection, not the authorization decision
In practice
Two internal services communicate through a service mesh that issues each workload a short lived certificate identifying it. When the billing service calls the ledger service, the ledger verifies the presenting certificate and confirms it belongs to a workload permitted to write entries. No API key exists in either deployment, and a stolen network capture reveals nothing usable because the credential was never sent.