In one line: mTLS = mutual TLS — both sides verify each other's certificate. Replaces "IP allowlist + shared token" inside private networks with cryptographic service identity.
What it is#
Plain HTTPS: client validates the server's cert. mTLS: the client also presents a cert during handshake; the server validates it against an internal CA.
Plain TLS: client → verifies → server cert
mTLS: client ⇄ mutually verify ⇄ server + client cert
Analogy#
Plain HTTPS is like walking into a mall — seeing the mall's signage is enough. mTLS is like entering a corporate building — security checks your employee badge before letting you in, and you verify this is the real front entrance (not a phishing setup).
Key concepts#
How it works#
A service mesh (Istio / Linkerd) makes this fully automatic via sidecars.
Practical notes#
-
Manual nginx mTLS:
ssl_client_certificate /etc/nginx/ca.crt; ssl_verify_client on; -
Auto mTLS in a service mesh: Istio / Linkerd enable mTLS between sidecars by default.
-
mTLS at the API gateway: common in finance / banking — mobile apps present client certs to prove "I'm the real app".
-
Cert lifecycle: cert-manager (K8s) / Vault PKI mint short-lived leaf certs automatically.
-
Revocation: CRL / OCSP are awkward in practice — short lifetimes + no renewal is the realistic revocation path.
Easy confusions#
One leak = repeated reuse.
Every handshake verifies — **cryptographically bound** to a specific service instance.