A backend can receive a perfectly valid Client-Cert header and still make the wrong authorization decision. RFC 9440 defines the header so a TLS-terminating reverse proxy can pass the certificate presented by the originating client to an origin server. The header carries identity evidence from the proxy. It does not create that evidence, and it does not make the origin server a TLS peer of the client.
That distinction matters whenever mutual TLS is used for machine-to-machine access. The proxy validates the client certificate against trusted authorities, checks the request path and policy, then forwards a normalized representation of the certificate. The application maps the certificate subject, SAN, or issuer information to an account or workload. If the application also accepts the same header from a path that does not pass through the proxy, an attacker can supply the identity directly.
Separate evidence from assertion
The certificate verification result and the HTTP header have different trust properties. The proxy has the TLS session and can decide whether the certificate chain is acceptable. The backend has only the header. RFC 9440 describes how the proxy encodes the originating client certificate, including a chain header for intermediates. It does not make an unverified certificate trustworthy.
Before forwarding, the proxy should remove any Client-Cert or Client-Cert-Chain field supplied by the client. The backend should accept those fields only from an authenticated proxy network or a mutually authenticated proxy connection. A direct listener on the backend, a debug port, or an alternate ingress that bypasses the proxy must reject the headers or use a different authentication mechanism.
The certificate policy needs the same care as the transport. Check the issuing chain, validity period, key usage, extended key usage, and revocation result according to the deployment. Map a certificate to one workload or account with an explicit rule. A valid certificate from the organization's CA is not sufficient if the application accepts any certificate from that CA for every service.
Make the normalized identity explicit
Proxies and frameworks may represent the certificate differently. Decide whether the backend consumes the leaf certificate, a chosen subject alternative name, a fingerprint, or a signed internal identity claim. Record which fields are stable during renewal and which fields are not. A certificate fingerprint is useful for inventory and audit, but rotating the certificate changes it. A workload identity in a SAN may survive rotation if the naming policy is stable.
Use a small number of representations. If one service reads the certificate serial number and another reads the subject common name, the same client can receive different identities across the estate. Normalize once at the proxy boundary and document the resulting identity format. Validate that the normalized identity cannot contain separators or syntax that changes the meaning of a downstream policy.
Header handling also affects caching. A response that varies by client certificate identity must not be stored under a key that omits that identity. Apply the cache rules in RFC 9440 or disable shared caching for protected resources. This is especially important when a proxy and application share a cache or when an internal API gateway caches responses before authorization.
Test the bypass, not only the success path
Start with the deployed network path. Send a request with a made-up client certificate header directly to the backend and confirm that it is rejected. Then send the same header through an untrusted proxy and confirm that the trusted proxy removes or overwrites it. Test a missing certificate, an expired certificate, a certificate from the wrong issuer, and a valid certificate mapped to another tenant.
Log the proxy result separately from the backend identity decision. Record the proxy instance, certificate fingerprint, mapped principal, route, and policy result. Do not log the complete certificate by default. Keep the audit trail long enough to investigate an identity change, and alert when the backend receives certificate-identity headers from an unexpected source network.
Mutual TLS becomes useful when the certificate validation, header normalization, backend admission, and authorization policy all describe the same identity. The Client-Cert field is a transport for that identity. The security property comes from preventing any other path from speaking the same language.