mTLS (Mutual TLS)

Mutual TLS (mTLS) extends normal TLS by requiring the client to present a certificate as well as the server. Each side verifies the other's certificate against a CA it trusts before any application data flows.

Why it matters

Ordinary HTTPS authenticates only the server; users prove identity later with passwords or tokens. With mTLS, identity is established at the connection layer. It is common for service-to-service traffic in microservice and service-mesh setups, for APIs offered to a small set of partners, and for zero-trust access to internal tools. A request from a client without a valid certificate never reaches the application.

The tradeoff is operations: you must issue, distribute, rotate and revoke client certificates, and public browsers are a poor fit for it.

Example

An nginx server requiring client certificates:

ssl_client_certificate /etc/nginx/client-ca.pem;
ssl_verify_client on;

Test it with curl:

curl --cert client.pem --key client.key https://api.example.com/health

Common mistakes

• Letting client certificates expire unnoticed, which causes sudden failures in internal services.
• Trusting a broad public CA bundle for client auth instead of a dedicated private CA.
• Having no revocation or short-lifetime plan for stolen client keys.

Related

• Certificate authority
• Zero trust
• TLS handshake
• Key pair

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.