In standard TLS, only the server proves its identity with a certificate. In mutual TLS (mTLS), both sides authenticate, like two people showing their ID cards to each other before exchanging information. This guide explains how mTLS works, where to use it, how to deploy it, and the pitfalls to avoid.
Mutual TLS (mTLS) is an extension of the standard TLS protocol where both the client and the server authenticate each other using digital certificates. In regular TLS (what you use when browsing an HTTPS website), only the server presents a certificate. The client verifies the server's identity but remains anonymous. With mTLS, the server also requests a certificate from the client, and both parties verify each other's identity before any application data is exchanged.
Think of it like entering a secure building: in regular TLS, you verify the building is who it claims to be (checking the sign on the door). In mTLS, the building also checks your ID badge before letting you in. Both sides prove their identity.
mTLS uses the same certificate chain and trust model as regular TLS. Both certificates must be signed by a certificate authority that the other party trusts. The client certificate is typically a client authentication certificate with the appropriate key usage extensions.
Zero Trust architecture operates on the principle of "never trust, always verify." In a Zero Trust model, every connection, whether from inside or outside the network perimeter, must be authenticated and authorized. mTLS is a natural fit because it provides cryptographic identity for every connection.
With mTLS, every service, workload, and device has a cryptographic identity (a certificate). The network itself is no longer the trust boundary. A compromised machine on the internal network cannot access services because it doesn't have a valid client certificate. This eliminates the "castle and moat" model where everything inside the firewall is trusted.
The mTLS handshake extends the standard TLS handshake with an additional step where the server requests and validates the client's certificate. Here are the six key steps.
The client initiates the TLS handshake by sending supported cipher suites, TLS version, and random data. This is identical to a standard TLS handshake.
The server responds with its chosen cipher suite and presents its own certificate chain. The client verifies the server's certificate against its trust store.
The server sends its key exchange parameters (Diffie-Hellman or ECDHE). Both sides will use these to derive the shared session keys.
This is what makes it "mutual." The server sends a CertificateRequest message, specifying which certificate types and CAs it will accept. The client must respond with a matching certificate. If the client has no valid certificate, the handshake fails.
The client sends its certificate chain and a CertificateVerify message: a signature over the handshake transcript using its private key. The server verifies the certificate chain and the signature, confirming the client possesses the private key.
Both sides exchange Finished messages and begin encrypted communication. Both identities are verified, the channel is encrypted, and application data can flow securely.
Microservices authenticating each other without API keys or tokens. Each service has its own certificate, and the service mesh enforces mTLS between all services. No shared secrets to rotate.
Service meshes like Istio and Linkerd use mTLS to encrypt and authenticate all inter-pod traffic. SPIFFE identities are encoded in certificate URIs, providing workload-level identity.
Enterprise Wi-Fi and wired network authentication using client certificates. EAP-TLS uses mTLS to authenticate devices before granting network access. No passwords to phish.
Certificate-based VPN authentication replaces username/password with mTLS. Both the VPN client and server authenticate with certificates, providing stronger security and eliminating credential theft risks.
IoT devices use mTLS to authenticate with cloud backends. Each device has a unique certificate provisioned during manufacturing. The backend verifies the device certificate before accepting data.
PostgreSQL, MySQL, and MongoDB support mTLS for client authentication. Applications prove their identity with certificates instead of database passwords, reducing the risk of credential leaks in config files.
Here are configuration examples for the two most common reverse proxies. Both require a CA certificate file that lists the CAs whose client certificates are trusted.
server {
listen 443 ssl;
server_name api.example.com;
# Server certificate
ssl_certificate /etc/nginx/tls/server.crt;
ssl_certificate_key /etc/nginx/tls/server.key;
# mTLS: require and verify client certificates
ssl_client_certificate /etc/nginx/tls/trusted-ca.crt;
ssl_verify_client on;
ssl_verify_depth 2;
# Pass client cert DN to upstream
proxy_set_header X-Client-DN $ssl_client_s_dn;
}transport_socket:
name: envoy.transport_sockets.tls
typed_config:
"@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.DownstreamTlsContext
require_client_certificate: true
common_tls_context:
tls_certificates:
- certificate_chain: { filename: "/certs/server.crt" }
private_key: { filename: "/certs/server.key" }
validation_context:
trusted_ca: { filename: "/certs/trusted-ca.crt" }
The trusted-ca.crt file should contain the certificate of the CA(s) that issued your client certificates. Only clients presenting certificates signed by these CAs will be allowed. You can use your private PKI to issue both server and client certificates from the same trust hierarchy.
| Method | Strength | Weakness |
|---|---|---|
| mTLS | Cryptographic identity, phishing-resistant, no shared secrets | Certificate lifecycle complexity |
| API Keys | Simple to implement | Shared secret, no encryption, easily leaked |
| OAuth 2.0 / JWT | Flexible, delegated authorization | Token theft, requires token infrastructure |
| IP Whitelisting | Zero overhead | No identity, spoofable, breaks with dynamic IPs |
Best practice: Use mTLS for service-to-service authentication (the transport layer identity) and complement it with OAuth/JWT for authorization (what the service is allowed to do). This provides defense in depth: even if a token is stolen, it can't be used without the matching client certificate.
Every client needs a unique certificate and private key. Distributing, installing, and configuring certificates across hundreds of services or thousands of devices is a significant operational challenge. Without automation, this becomes a bottleneck that slows deployments.
When a client certificate expires, the mTLS handshake fails and the service is completely unreachable. Unlike a web browser that can show a warning, API clients simply get a connection error. With shorter certificate lifespans, expiry outages become far more likely without automated renewal.
Each server must be configured with the correct CA certificate(s) to trust. If you add a new issuing CA or rotate your intermediate CA, you must update the trust store on every server that accepts client certificates. Missing a single server causes connection failures for clients using the new CA.
mTLS failures are notoriously hard to debug. Error messages are often cryptic (tlsv1 alert unknown ca) and don't indicate whether the problem is an expired certificate, a missing intermediate, a trust store misconfiguration, or a key mismatch. Good logging and certificate monitoring are essential.
mTLS adds one extra certificate verification per connection compared to standard TLS. For high-frequency, short-lived connections, this can add measurable latency. Use connection pooling, TLS session resumption, and consider ECDSA certificates (smaller and faster to verify than RSA) to minimize impact.
Automated client certificate issuance: Evertrust PKI issues client certificates via ACME, EST, and REST APIs. Services and devices can request and renew their mTLS certificates automatically, eliminating manual certificate distribution.
Complete mTLS visibility: Evertrust CLM discovers and monitors all client and server certificates in your mTLS deployments. Get alerts before any certificate expires, preventing those hard-to-debug mTLS connection failures.
Private PKI for Zero Trust: Build your entire mTLS infrastructure on Evertrust's private PKI. Issue server certificates, client certificates, and workload identities from a single trust hierarchy with consistent policies and full audit trails.