How to Set Up Mutual TLS (mTLS)
Mutual TLS turns a one-sided handshake into a two-sided one: the client proves who it is with a certificate, not just the server. It gives service-to-service traffic strong cryptographic identity without shared secrets — but only if both ends trust the right CA and you have a real plan for rotation. This guide covers issuing both certificates, wiring up two-way trust, and reading the handshake when it fails.
In plain words
Setting up mutual TLS means issuing certificates to both the client and the server so each authenticates the other — and PlayCISO has a free, browser-based Mutual TLS Lab to wire up two-way trust and watch the handshake pass or fail.
Issue server (serverAuth) and client (clientAuth) certs from a CA both ends trust, require client verification on the server, and plan rotation and revocation up front. mTLS fits machine-to-machine traffic you control — not public, human-facing web pages.
Step by step
- 1
Decide whether mTLS is the right tool
Mutual TLS makes both sides of a connection present certificates, so the server authenticates the client as well as the other way round. It shines for machine-to-machine traffic — service meshes, internal APIs, IoT fleets — where you control both ends and want cryptographic client identity instead of shared secrets. For public, human-facing web traffic it is usually the wrong fit; use normal TLS plus session auth there.
- 2
Stand up a CA to issue both sides
mTLS needs a certificate authority both ends trust. For internal use this is typically your own private CA (or an intermediate under one), not a public CA. Create the CA key and root certificate, protect the CA key carefully, and plan now for how you will issue, renew and revoke — a private PKI you cannot rotate becomes a liability faster than a public one.
- 3
Issue the server certificate
Generate a key and CSR for the server with its hostname(s) in the SAN, and have your CA sign it with extendedKeyUsage serverAuth. Install the leaf, its key and the issuing chain on the server. This is ordinary server-side TLS so far; what makes it mutual is the next step, where the server also demands a certificate from the client.
- 4
Issue client certificates
Generate a key and CSR per client and have the CA sign them with extendedKeyUsage clientAuth. The client’s identity lives in the subject or SAN (a service name, a SPIFFE ID, or a device identifier) and is what the server will authorize against. Keep each client’s private key on that client only, exactly as you would a server key.
- 5
Configure trust in both directions
On the server, enable client-certificate verification and point it at the CA bundle that signed your clients (for example ssl_client_certificate plus ssl_verify_client on; set require, not optional, when every caller must authenticate). On each client, present its certificate and key and trust the CA that signed the server. Both ends must trust the issuing CA for the other end, or the handshake fails.
- 6
Debug the common handshake failures
The frequent failures are: the client sent no certificate (it was not configured to, or verification was left optional); the server does not trust the client’s CA (wrong or incomplete CA bundle); the client does not trust the server’s CA; an expired or wrong-EKU certificate; or a name/identity mismatch in your authorization rules. Read the exact alert — bad certificate, unknown CA, certificate required — because each points to a different side of the config.
- 7
Plan rotation and revocation from day one
Both server and client certificates expire, so build renewal in before you deploy: short-lived client certs issued by an automated internal CA (the SPIFFE/SVID pattern) avoid manual churn, while longer-lived ones need a rotation calendar. Distribute new CA roots to both ends during an overlap window before retiring the old one, and have a working revocation path for a client whose key is lost.
Issue a client and server cert, wire up two-way trust, and watch a handshake succeed or fail with the real alert — all in your browser.
Related
Keys, certificates and trust across the PlayCISO labs.
Build and validate a certificate chainBoth sides of an mTLS handshake must build a complete, trusted chain.
Rotate TLS certificates without downtimemTLS means rotating client certs too — plan the overlap.
All PlayCISO labsHands-on, browser-based security labs across crypto, cloud and incident response.
Frequently asked questions
How is mutual TLS different from regular TLS?
In regular TLS only the server proves its identity with a certificate, and the client stays anonymous at the transport layer. In mutual TLS both sides present certificates, so the server cryptographically authenticates the client as well. That gives you strong, certificate-based client identity without shared API keys, which is why mTLS is popular for service-to-service and device communication.
Do I need a public CA for mTLS?
Usually not. Because both ends are under your control, a private internal CA (often an intermediate under your own root) is the normal choice and avoids per-client public CA costs and rate limits. The server trusts your CA to validate clients and the clients trust it to validate the server. Public CAs make sense only when an external party you do not control must connect.
Why does my mTLS handshake fail with "unknown CA" or "certificate required"?
Unknown CA means one side does not trust the authority that signed the other side’s certificate, typically a wrong or incomplete CA bundle. Certificate required means the server demanded a client certificate but the client presented none, often because the client was not configured to send one or the server was set to require rather than optional. Read the specific alert, because it tells you which side and which setting to fix.
How often should client certificates be rotated?
There is no single number, but short lifetimes are safer because a leaked client key is dangerous until it expires or is revoked. Automated internal CAs commonly issue very short-lived client certificates (hours to days) so rotation is continuous and manual revocation is rarely needed. If you issue longer-lived certs, keep a rotation calendar and a working revocation path, just as you would for server certificates.
When should I not use mTLS?
Avoid mTLS for public, browser-facing traffic where you cannot provision certificates to end users — the UX of client certificates in browsers is poor and user-facing auth belongs at the application layer. It also adds real operational weight: a CA, per-client issuance, and rotation for both ends. If you do not control both sides or cannot commit to running a PKI, a simpler model is usually the right call.