mTLS
Mutual TLS authenticates both sides of a connection with certificates, not just the server. It's the backbone of zero-trust service-to-service auth. Each service presents a cert the other validates.
- Zero-trust service meshes.
- High-security B2B APIs where client certs replace shared secrets.
- Public APIs to browsers (use OAuth/JWT).
- Small internal systems where network trust + tokens suffice.
Definition
An extension of TLS where the client also presents a certificate. Both parties verify the other's identity via a CA (internal or public), giving strong cryptographic auth without passwords or tokens per call.
Why it exists
In a service mesh, you can't trust the network. mTLS gives every connection a verified peer identity, used for authorization and encryption, rotated automatically by a control plane like SPIFFE/istio.
How it works
A CA (often internal, e.g. cert-manager + a private CA, or SPIRE) issues short-lived certs to workloads. The proxy/sidecar enforces mTLS on every connection and maps cert identity (SPIFFE ID) to policy. Certs rotate frequently to limit blast radius.
Scaling limits
Cert distribution and rotation at thousands of services needs automation. Revocation (CRL/OCSP) is operationally hard; short-lived certs sidestep it.
Cost shape
Handshake CPU per connection (use connection pools). The real cost is the PKI infrastructure and rotation automation.
Alternatives
- JWT bearer tokens — Per-request auth without PKI, but tokens can be stolen and need revocation.
- Network ACLs — Trust the network; no per-connection identity.
Failure modes
- Cert rotation breaking if old certs expire before reload.
- A compromised CA issuing rogue service certs.