What is Mutual TLS (mTLS)? Client Certificate Authentication

In regular HTTPS, only the server proves its identity with a certificate. The client (browser) is anonymous — the server doesn’t know who’s connecting.

Mutual TLS (mTLS) adds a second step: the client also presents a certificate. Both sides authenticate each other. The server verifies the client’s certificate against a trusted CA, and the client verifies the server’s — hence “mutual.”

Regular TLS vs Mutual TLS

When to use mTLS

Service-to-service communication

Microservices talking to each other over the network. mTLS ensures only authorized services can connect — not just anyone who knows the URL.

Service A ←──mTLS──→ Service B
Both verify: "Are you who you claim to be?"

Zero Trust architecture

In zero trust, no network connection is trusted by default — even inside the corporate network. mTLS replaces network-level trust (firewalls, VPNs) with identity-level trust (certificates).

API security

Protect sensitive APIs beyond just API keys. A stolen API key can be used by anyone. A client certificate is bound to a specific private key — harder to steal and use.

IoT device authentication

Devices connect to a backend with client certificates provisioned during manufacturing. The server knows it’s talking to a genuine device, not a spoofed one.

How mTLS works

1. Client connects and initiates TLS handshake (same as regular TLS)
2. Server sends its certificate — client verifies it (same as regular TLS)
3. Server requests client certificate — sends a CertificateRequest message
4. Client sends its certificate — server verifies it against a trusted CA
5. Both sides compute session keys and encrypted communication begins

Step 3-4 are what make it “mutual.”

Nginx mTLS configuration

server {
    listen 443 ssl;
    server_name api.example.com;

    # Server certificate (same as regular HTTPS)
    ssl_certificate     /etc/ssl/server-fullchain.pem;
    ssl_certificate_key /etc/ssl/server-privkey.pem;

    # Client certificate verification
    ssl_client_certificate /etc/ssl/client-ca.pem;  # CA that signed client certs
    ssl_verify_client on;                            # Require client cert

    # Optional: pass client cert info to your app
    proxy_set_header X-Client-DN $ssl_client_s_dn;
    proxy_set_header X-Client-Verify $ssl_client_verify;
}

mTLS vs other authentication methods

mTLS and GetHTTPS

GetHTTPS issues server certificates — the certificates your web server uses to prove its identity. These are the standard SSL certificates used by every HTTPS website.

Client certificates for mTLS are typically issued by a private CA (your organization’s internal CA), not a public CA like Let’s Encrypt. Let’s Encrypt doesn’t issue client certificates — they only issue server certificates for public domains.

Frequently asked questions

Can I use Let’s Encrypt for mTLS?

For the server certificate: yes. For client certificates: no. Client certs need to be issued by a private CA you control — so you decide which clients are authorized. Tools like openssl, cfssl, or step-ca can act as your private CA.

Is mTLS the same as “client certificate authentication”?

Yes. “Mutual TLS,” “mTLS,” “two-way TLS,” and “client certificate authentication” all refer to the same thing — both sides present certificates during the TLS handshake.

Does mTLS replace API keys?

It can, but they serve different purposes. mTLS proves the transport-level identity (which service is connecting). API keys/JWTs prove the application-level identity (which user/permission). Many systems use both together for defense in depth.

Where is mTLS commonly used?

Kubernetes (service mesh with Istio/Linkerd), Cloudflare Access, AWS API Gateway (mutual TLS), Google Cloud’s BeyondCorp, and most enterprise zero-trust implementations.