What is Mutual Authentication with mTLS?
Mutual TLS, or mTLS, is TLS with certificate authentication for both endpoints. The server proves control of its private key and the client also presents a certificate and proves control of the matching private key. Each endpoint must validate the other certificate against its trust policy and expected identity. mTLS gives the TLS channel mutual peer authentication, confidentiality, and integrity. It does not decide what an authenticated identity is allowed to do.
Why it matters
Server-only TLS does not authenticate the client at the transport layer. Mutual authentication lets both endpoints reject a peer that cannot prove the expected certificate identity.
How it works
- The server presents its certificate and proves control of the matching private key during the TLS handshake.
- The server requests a client certificate, and the client presents it and proves control of its private key.
- Each endpoint validates the peer certificate, expected identity, trust chain, and handshake proof before it uses the encrypted channel.
Example
An internal administration service accepts traffic from Pomerium only when Pomerium presents a client certificate issued by the service's trusted certificate authority.
Pomerium boundary
Pomerium supports downstream mutual TLS between a client and Pomerium and upstream mutual TLS between Pomerium and a protected service. Deployment-level downstream mTLS settings define trusted client certificate authorities and enforcement. Route-level upstream TLS settings define the client certificate, custom certificate authority, and expected upstream server name.
Limits and non-claims
- Mutual TLS authenticates the connection peers, but application policy must still authorize each operation.
- Certificate issuance, storage, rotation, revocation, and recovery add operational work.
- A valid certificate cannot protect a compromised endpoint that can use its private key.
Evaluation checklist
- Which exact client and server names, chains, usages, and validity rules must each peer verify?
- How does the authenticated certificate identity map to the requested resource and action?
- Can key theft, proxy termination, stale revocation data, or a direct path defeat the expected boundary?
