SECURITY / A CONCEPT NOTE
mTLS
mutual TLS — both sides prove their identity, not just the server
Overview · mechanism
pitfall · examples
01 / THE SHORT VERSION
The idea in a few sentences.
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.
02 / FOLLOW THE MECHANISM
How an mutual handshake works
Client
initiates a connection and sends its
ClientHellowith supported ciphers.Server
responds with its certificate and requests the client's certificate (
CertificateRequest).Client
sends its signed certificate and proves possession of the corresponding private key.
Server
validates the client certificate against its trusted CA pool and extracts the client identity.
Encrypted channel
both sides have mutually authenticated. Traffic is encrypted with the negotiated session keys.
04 / COMMAND NOTES
Read the command, then the result.
Inspect the flags and arguments before trying an example. Snippets can need local setup, replacement values, or resources in your own environment.
test an mTLS connection
openssl s_client -connect my-service:443 -cert client.crt -key client.keycheck certificates mounted in a pod
kubectl exec deploy/my-app -- ls /etc/certs05 / CHECK YOURSELF
Could you explain mTLS to a teammate?
Try it out loud in two sentences: what it is, and the one detail that changes the picture. If you stall, the gap is the part to reread.
Up next in Security & identitySBOMa full inventory of every software component in your application