An edge proxy authenticates callers with mutual TLS, and the application behind it needs to know which client certificate was presented. How should that identity reach the application, and what is the classic way this arrangement is defeated?

## Termination consumes the authentication In mutual TLS the client proves possession of a private key during the handshake. That proof is bound to *that connection* and to the handshake transcript; it cannot be copied, replayed, or handed onward. So when a proxy terminates, the client's authenticated connection ends there. Whatever the application learns about the caller is now an *assertion made by the proxy*, not evidence the application can check. That is not a flaw — centralising certificate validation at the edge is usually the point. But it changes the security question from "is this certificate valid?" to "do I trust the entity telling me about it, and can anyone else pretend to be that entity?" ## Carrying the identity The proxy validates the chain, revocation status and whatever name constraints you require, then puts the result in a request header on the forwarded request. Common contents are the certificate's subject distinguished name, a SAN entry such as a URI or DNS name, a fingerprint, or the whole certificate escaped for the application to parse. The de-facto format is Envoy's `x-forwarded-client-cert`, a list of key-value pairs including `By`, `Hash`, `Subject`, `URI` and `DNS`, which several other proxies and meshes emit or consume. An application reading that header should be conservative: pin to the specific field it cares about, require an exact match against an allowlist of expected identities rather than a substring test on a distinguished name, and treat a missing header as "unauthenticated", never as "internal, therefore fine". ## The two ways it breaks **The header is not stripped.** If the proxy only *adds* the header when a certificate was presented, and passes it through otherwise, any client can send the header itself and the application will believe it. The rule is unconditional: at the trust boundary, delete or overwrite the identity header on every inbound request before evaluating anything. "Append if present" is not good enough — the application usually reads the first or last element, and an attacker who knows which one wins controls it. **The application is directly reachable.** Even a perfectly stripping proxy is irrelevant if the application's port answers to anything else on the network. Anyone who reaches it — a compromised neighbouring workload, a developer's jump host, a mis-scoped firewall rule, a service that follows a redirect to an internal address — sends a forged header straight to the app: ``` curl -H 'x-forwarded-client-cert: Subject="CN=payments-admin"' \ http://orders.internal:8080/admin/refund ``` No certificate, no proxy, full impersonation. This is why the header approach is only as strong as the network path, and network paths are exactly the thing that quietly changes over two years of platform evolution. ## Making the path enforceable Order the defences from weakest to strongest: 1. **Network policy or firewalling** so only the proxy's addresses may open the app's port. Real, but it is an assertion about topology, and it fails open when someone adds a rule. 2. **Re-encrypt from the proxy with the proxy's own client certificate**, and have the application *require* mutual TLS on its listener. Now the app authenticates its immediate peer cryptographically: the identity header is trustworthy because only a peer holding the proxy's key could have sent it. This is the answer that survives a network change, and it is why re-encryption and mTLS between hops belong in the same conversation. 3. **A signed assertion rather than a bare header** — the proxy mints a short-lived token naming the verified client, which the application validates against the proxy's public key. This survives an extra hop and does not depend on the header being stripped, at the cost of running a signing key and clock discipline. ## When to not terminate at all Sometimes the application genuinely must see the client certificate — a regulatory requirement that the authenticating endpoint is the application itself, or a protocol that binds credentials to the client's TLS key. No amount of header forwarding satisfies that, because the binding cannot be delegated. Then the honest answer is passthrough: the proxy forwards bytes, the application completes the mutual handshake, and you give up edge routing and inspection for that route. Being able to state that trade — and to say which requirement forces it — is what separates a good answer here from a list of headers. ## Operating it Two practical notes. Client certificates expire, and unlike server certificates nobody visits the site and notices; track client-certificate expiry per caller and alert well ahead, because the failure mode is a partner's integration dying at 3am. And decide up front what revocation means for you — a proxy that never checks revocation is issuing lifetime credentials, so short-lived client certificates are usually a better lever than a revocation infrastructure you will not maintain.