Skip to content

Archive

Mutual TLS

2 articles
Cybersecurity 17 Sep 2026 10 min read

Mutual TLS Identity Can Disappear at a Terminating Proxy

Mutual TLS Identity Can Disappear at a Terminating Proxy A service can require a client certificate at its public endpoint, accept only certificates chained to an approved authority, and still deliver an unauthenticated request to the application behind it. The TLS check may be completely correct. The gap appears when a reverse proxy terminates that TLS connection and opens a different connection to the backend. Mutual TLS authenticates endpoints of a particular TLS connection. It does not automatically attach the authenticated client identity to HTTP requests after that connection ends, and it does not cause a second TLS connection to inherit the first connection’s peer. Once a proxy becomes the TLS server for the external client, the proxy is the component that possesses the verified client-certificate result. Any backend identity derived from that result crosses a new trust boundary.

Cybersecurity 15 Sep 2026 7 min read

Mutual TLS Moves Client Identity Into the Handshake

Mutual TLS Moves Client Identity Into the Handshake An internal API can receive a perfectly encrypted TLS connection and still have no cryptographic evidence about the process at the other end. Ordinary server-authenticated TLS proves the server’s identity to the client and protects traffic in transit, but the application still needs another mechanism to identify its caller. Mutual TLS, commonly shortened to mTLS, adds certificate-based client authentication to that exchange. The server requests a client certificate, validates the presented chain according to its trust policy, and verifies a signature proving possession of the corresponding private key. The result is a transport connection associated with a cryptographic client identity before ordinary application requests are processed.