Client-Cert
The HTTP Client-Cert request header carries the client certificate from a mutually authenticated TLS connection when a reverse proxy terminates TLS and forwards the request to an origin server.
Usage
When a reverse proxy handles mutual TLS (mTLS) Authentication on behalf
of backend servers, the TLS connection ends at the proxy. The origin server
behind the proxy needs access to the client certificate to make authorization
decisions or log client identity. The Client-Cert header solves this by
passing the base64-encoded client certificate from
the proxy to the origin as an HTTP header
using the Structured Field Byte Sequence format
(:base64data:).
The specification standardizes this practice. Before standardization, proxies and origin servers used vendor-specific headers or custom mechanisms to pass certificate data. The Client-Cert header provides a common format across different reverse proxy implementations.
The header carries only the end-entity certificate from the client. The certificate chain, if needed, travels separately in the Client-Cert-Chain header. This separation keeps the most commonly needed data in a single header while making the full chain available when validation or inspection requires the chain.
The proxy must remove any Client-Cert header present in the incoming request before adding its own value. This prevents clients from injecting forged certificate data.
Values
Base64-encoded certificate
The value is the client certificate from the mTLS connection, encoded as a Structured Field Byte Sequence (base64 with colon delimiters). The certificate is in DER format before encoding.
Example
A reverse proxy terminates an mTLS connection and forwards the request to the origin server. The Client-Cert header contains the base64-encoded client certificate in Structured Field Byte Sequence format. The origin server decodes the value to extract the certificate and verify client identity.
Client-Cert: :MIIBqDCCAU6gAwIBAgIBBzAKBggqhkjOPQQDAjA6MRswGQYDVQQK
DBJMZXQncyBBdXRoZW50aWNhdGUxGzAZBgNVBAMMEkxBIEludGVybWVkaWF0ZSBD
QTAeFw0yMDAxMTQyMjU1MzNaFw0yMTAxMjMyMjU1MzNaMBIxEDAOBgNVBAMMB2Ns
aWVudDEwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAATx4ECEj5vJzAOc4WEuAQFp
yqZsQvxcpCPDPdPV6sn7SLmyNUFGGVaeMbkA1VjBCdmMR5zjwNBRUmzLJcNmBmcR
o18wXTAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBSKAUUTbJWvY2RGVlbCzUUMR0ry
fDAOBgNVHQ8BAf8EBAMCA6gwHgYDVR0lBBcwFQYIKwYBBQUHAwIGCWCGSAGG-EIE
ATAKBggqhkjOPQQDAgNIADBFAiEAvO3h0K4BqJvvlqEVPzH-zpTGfEPPn2vY-SOK
n2j4pCYCIH-J3IvVD-dJdJ-GCLzRRhZ9Vg8ZfGxJZhQVQjsKfmk3:
The origin server receives the certificate and validates the client identity against an internal certificate authority or allowlist. The encoded format remains consistent across different TLS implementations and reverse proxy vendors.
Takeaway
The Client-Cert header enables reverse proxies to pass client certificates from mTLS connections to origin servers using the Structured Field Byte Sequence format (base64).