TOPIC SECURITY
mTLS mutual TLS — both sides prove their identity, not just the server
IN 10 SECONDS
In regular TLS, only the client verifies the server's certificate. In mutual TLS (mTLS), the server also verifies the client's certificate. Both sides present certificates signed by a trusted CA. This ensures that not only is the server who it claims to be, but every connecting client is authenticated with a cryptographic identity — not just a password or API key.
GOTCHA Certificate management is the hardest part of mTLS. Every client needs a unique certificate, and they expire. Without automated certificate rotation (cert-manager, Vault PKI, SPIFFE), you'll have outages when certs expire. Start with short-lived certs (24h) and automated renewal.
HOW AN MUTUAL HANDSHAKE WORKS
01 Client initiates a connection and sends its `ClientHello` with supported ciphers.
02 Server responds with its certificate and requests the client's certificate (`CertificateRequest`).
03 Client sends its signed certificate and proves possession of the corresponding private key.
04 Server validates the client certificate against its trusted CA pool and extracts the client identity.
05 Encrypted channel both sides have mutually authenticated. Traffic is encrypted with the negotiated session keys.
POKE IT YOURSELF
openssl s_client -connect my-service:443 -cert client.crt -key client.key — test an mTLS connection
kubectl exec deploy/my-app -- ls /etc/certs — check certificates mounted in a pod
Drill this topic →
~85 sec read