A service can require mutual TLS at its public edge and still have no TLS client certificate at the application server. The client proves possession of its private key to the TLS-terminating reverse proxy; the proxy then opens a separate connection to the origin. Unless certificate information is carried across that second hop, the origin cannot directly inspect the credential authenticated on the first connection.
Forwarding the certificate in an HTTP field solves the transport problem but changes the security boundary. The origin is no longer consuming identity evidence directly from its own TLS handshake. It is consuming a statement made by an intermediary about a different handshake.
RFC 9440 codifies this pattern with Client-Cert and Client-Cert-Chain. The mechanism is useful precisely because TLS termination is common, but its security properties depend on a strict distinction between client-supplied request fields and proxy-generated certificate metadata.
TLS authentication ends at the terminating proxy
In direct mutual TLS, the server requests a client certificate during the TLS handshake. The client presents a certificate and proves possession of the corresponding private key through the protocol’s certificate-authentication messages. Certificate validation policy then determines whether that authenticated key and certificate are acceptable.
A reverse proxy changes the topology:
client === mutual TLS ===> edge proxy === backend connection ===> originThe first TLS session terminates at the proxy. The backend connection is a different transport session with separate cryptographic state. Even when HTTPS or mutual TLS protects the backend hop, that session authenticates the participants in the backend connection; it does not recreate the original client’s TLS handshake.
An origin that needs the external client certificate for authorization, audit records, or token binding therefore needs an explicit representation of that certificate. RFC 9440 defines Client-Cert for the end-entity certificate and an optional Client-Cert-Chain field for the validation chain conveyed by the terminating proxy.
That representation is application-layer metadata. Its integrity comes from the deployment architecture around the header, not from the external client’s TLS transcript.
A forwarded certificate is an assertion by the proxy
The distinction matters because an X.509 certificate alone is not proof that the sender of an HTTP request possesses its private key.
If an origin receives a DER-encoded certificate in Client-Cert, it can parse the certificate, inspect names or extensions, calculate a thumbprint, and apply application policy. None of those operations independently proves that the current HTTP peer completed mutual TLS using that certificate.
The proof occurred earlier, between the external client and the terminating proxy. The origin’s security decision therefore has two parts: the proxy must correctly authenticate the client, and the origin must accept certificate metadata only when it can attribute that metadata to an authorized proxy.
This makes the proxy a security principal rather than a transparent transport convenience. A compromised or misconfigured terminating proxy can assert certificate information that the origin may treat as authenticated identity. Backend authorization cannot be stronger than the integrity of that assertion channel.
Client-controlled copies must not survive the edge
HTTP fields are client input unless the architecture makes them otherwise. An external client can send a field named Client-Cert in its request before the TLS proxy adds any metadata.
RFC 9440 requires the terminating reverse proxy to remove any incoming Client-Cert and Client-Cert-Chain fields before adding its own values. This prevents a client-provided value from being confused with proxy-generated certificate state.
The requirement also exposes a broader implementation constraint. Merely configuring a proxy to add a trusted field is insufficient if an untrusted copy can coexist, be concatenated, be selected first by a framework, or reach the origin through an alternate route. The field must have one authoritative producer at the trust boundary.
RFC 9440 defines Client-Cert as a singleton field. Multiple occurrences or a list of values are not valid representations of the field. Strict handling reduces ambiguity between HTTP components that might otherwise resolve duplicate fields differently.
The same principle applies to older deployment-specific certificate headers. A private header name does not make a field trustworthy. Integrity requires edge sanitization plus a backend path on which only the authorized intermediary can originate the assertion.
Backend reachability determines whether the header is credible
A correctly configured edge cannot protect an origin that clients can also reach directly.
Consider an origin that accepts Client-Cert whenever the field is present. If the public network can connect to that origin without traversing the designated TLS terminator, an attacker can bypass the mutual-TLS edge and submit the identity field directly. The application then has no reliable basis for distinguishing a proxy assertion from client input.
Network placement is therefore part of the authentication design. The origin needs a mechanism that restricts accepted requests to authorized intermediaries. Depending on the environment, that can involve private routing, firewall policy, authenticated service-mesh identity, mutual TLS on the backend connection, or another channel-authentication control.
Encryption by itself is not enough. A backend HTTPS listener that accepts connections from arbitrary clients protects traffic confidentiality but does not establish that a request carrying certificate metadata came from the approved terminating proxy.
The relevant property is authenticated provenance: the origin must be able to associate the request with a trusted proxy before treating the certificate field as external-client identity.
Multiple proxies expand the assertion chain
Real deployments often contain more than one intermediary. A request may pass through an ingress tier, regional proxy, service mesh, and application gateway before reaching the process that performs authorization.
RFC 9440 intentionally describes the certificate presented by the originating client to the TLS-terminating reverse proxy. Additional hops do not change that semantic target, but they do create more places where the field can be removed, replaced, duplicated, or exposed to an untrusted peer.
A robust chain needs an explicit ownership model. Components downstream of the TLS terminator either preserve the authenticated assertion over trusted links or translate it into another authenticated identity representation. Each hop that can originate or alter the field joins the trusted computing base for decisions derived from it.
This is materially different from assuming that all internal traffic is trusted. Internal networks commonly contain workloads with different privileges. If any such workload can connect to the origin and set the same header, the certificate assertion loses its security meaning even if the original edge behaves correctly.
Certificate chains carry data, not delegated validation guarantees
Client-Cert-Chain can carry the certificate chain used in validation of the end-entity certificate. That is useful when the origin needs chain information for application logic, but forwarding a chain does not automatically transfer every detail of the proxy’s validation policy.
Certificate acceptance can depend on trust anchors, name constraints, extended key usage, revocation policy, validation time, local policy, and implementation behavior. An origin that reparses a forwarded chain using different policy can reach a different result from the edge.
The architecture should therefore define which component owns certificate validation and which facts the application is allowed to infer. If the proxy is authoritative for client-certificate authentication, the origin should not treat the mere presence of a forwarded chain as an independent validation event.
Conversely, if application policy requires properties that the proxy does not validate, forwarding certificate material can permit the origin to inspect those properties, but the resulting design needs clear rules for malformed data, unsupported extensions, certificate rotation, and disagreement between edge and application policy.
Transporting certificate bytes and establishing certificate trust are separate operations.
Certificate-bound tokens make provenance stricter
OAuth mutual-TLS certificate-bound access tokens add another use for client-certificate state. RFC 8705 binds an access token to the certificate used by the client and requires the protected resource to verify that the certificate associated with the token matches the certificate used for mutual TLS.
When TLS terminates before the protected-resource application, the application may depend on trusted proxy metadata to obtain the external client certificate. The token check is then only as reliable as that metadata path.
A token containing a certificate thumbprint prevents ordinary bearer replay only when the resource can reliably establish the certificate presented by the caller. If an attacker can forge the forwarded certificate assertion, the proof-of-possession property at the application boundary collapses into trust in attacker-controlled metadata.
This does not make TLS termination incompatible with certificate-bound tokens. It means the terminating proxy and its authenticated connection to the resource server become part of the proof path. RFC 8705 and RFC 9440 address different layers of that arrangement: one defines certificate binding for OAuth tokens, while the other defines a standardized representation for carrying client-certificate information from a TLS terminator to an origin.
Logging needs to preserve assertion provenance
Client certificates are often used for audit identity as well as authorization. Proxy termination can make logs misleading if records store certificate subjects or thumbprints without recording where those values came from.
An origin log entry that says a request used certificate thumbprint X may mean that the local TLS stack authenticated X, or that a trusted edge asserted X, or that the application accepted a header without reliable provenance. Those states have very different evidentiary value.
Operational telemetry should distinguish the external client certificate from the identity of the backend peer. When backend mutual TLS is used, both identities can be relevant: the proxy certificate authenticates the immediate channel, while the forwarded client certificate describes the external handshake terminated earlier.
Keeping those identities separate also helps incident analysis. A certificate-authentication failure at the edge, a proxy-to-origin authentication failure, and an application rejection of certificate policy are different events at different boundaries.
TLS termination converts cryptographic state into delegated identity
Mutual TLS gives the endpoint participating in the handshake direct cryptographic evidence of client key possession. A TLS-terminating proxy prevents the origin from receiving that evidence directly because the origin is not a participant in the same session.
Certificate forwarding bridges the architectural gap by turning handshake state into an HTTP assertion. The conversion is safe only when the assertion has controlled provenance: external copies are stripped, the proxy is authoritative for the field, the backend authenticates its immediate peer, and alternate paths cannot bypass the intermediary.
The resulting boundary is explicit. The origin trusts the proxy to report a certificate that the proxy authenticated, and every authorization or token-binding decision based on that report inherits the security of the proxy-to-origin assertion channel.