mTLS

How it works

mTLS (mutual TLS) is TLS in which both sides present a certificate. Ordinary TLS authenticates only the server, leaving the client to prove itself at a higher layer with a token or API key. In mTLS the server also requests a client certificate, validates it against a trusted CA, and can bind authorization to the identity in that certificate. The client's private key never crosses the wire, so there is no bearer credential for an attacker to capture and replay.

When it matters

It matters for service-to-service traffic inside a system, where the alternative is a long-lived shared secret sitting in an environment variable. It is the transport underneath most workload identity systems, including SPIFFE, and the default in service meshes. It is a poor fit for public-facing browser traffic, where certificate distribution to end users is a support burden nobody wants. Note that TLS inspection breaks mTLS by design, because the interception point cannot present the client's certificate.

Common misconceptions

• "mTLS means we do not need authorization." It authenticates the caller. What that caller may do is a separate decision, and skipping it produces a flat network where any authenticated service can call any other.
• "It is just a config flag." The hard part is certificate lifecycle: issuance, rotation, revocation, and what happens when a cert expires at 3am. That operational load is why SPIFFE and service meshes exist.
• "Client certificates are unforgeable proof of a person." They prove possession of a private key. If that key sits unprotected on a shared host, it proves possession of the host.