mTLS (Mutual TLS)

Mutual TLS is not a separate protocol but standard TLS with client authentication turned on. The server presents its certificate as usual, then requests one from the client; the client sends a client certificate and signs the handshake with its private key, and the server validates that certificate against a CA it trusts. After the handshake both ends know who the other party is, instead of only the client knowing the server.

Why it matters

mTLS is the workhorse of service-to-service authentication in zero-trust networks and service meshes such as Istio and Linkerd, of device identity in IoT, and of regulated APIs such as PSD2 open banking with QWACs. Identities usually come from a private CA with short certificate lifetimes and automated rotation. Because public CAs are removing the clientAuth EKU from TLS certificates (Let's Encrypt from 2026-02-11; Chrome requires serverAuth-only subscriber certificates from 2027-03-15), mTLS deployments should not depend on public server certificates for the client side.

Example

server {
    listen 443 ssl;
    server_name api.example.com;
    ssl_certificate        /etc/nginx/certs/fullchain.pem;
    ssl_certificate_key    /etc/nginx/certs/server.key;
    ssl_client_certificate /etc/nginx/certs/client-ca.pem;
    ssl_verify_client      on;
}

nginx exposes the verification result in $ssl_client_verify and the client subject in $ssl_client_s_dn, which the application can use for authorization.

Common misconceptions

• mTLS is a different protocol. It is ordinary TLS 1.2 or 1.3 with the optional client-authentication step enabled.
• mTLS replaces authorization. It proves identity; the application still has to decide what that identity may do.
• mTLS works through any proxy. If a load balancer performs TLS termination, the backend never sees the client certificate unless the proxy verifies it and forwards the identity.