Client-Cert-Chain
The HTTP Client-Cert-Chain request header carries the certificate chain used to validate the client certificate when a reverse proxy terminates mutual TLS and forwards the request to an origin server.
Usage
When a reverse proxy handles mutual TLS (mTLS) Authentication and passes the client certificate to the origin server using Client-Cert, the origin might need the full certificate chain to verify the certificate against a root certificate authority. The Client-Cert-Chain header provides this chain.
The header carries certificates in the validation path, starting with the certificate signing the client certificate and continuing through any intermediate certificates. The end-entity client certificate is always excluded and travels separately in the Client-Cert header. This separation keeps certificate data organized and prevents redundant transmission of the client certificate. The root certificate may be omitted when the origin server already possesses the trust anchor, and many deployments omit it.
Each certificate in the chain is base64-encoded as a
Structured Field Byte Sequence
(:base64data:) and
separated from the next by a comma and space. The
certificates appear in the order needed for
validation, with the issuer of the client certificate
first.
The Client-Cert-Chain header appears only when Client-Cert is also present. A proxy sending the chain without the client certificate violates the specification. The proxy must remove any Client-Cert-Chain header from the incoming request before adding its own value to prevent client forgery.
Values
Certificate chain list
The value is a comma-separated list of certificates, each encoded as a Structured Field Byte Sequence (base64 with colon delimiters). Each certificate is in DER format before encoding. The certificates appear in validation order, with the certificate issuing the client certificate appearing first, followed by any intermediate certificates in the chain. The end-entity client certificate is always excluded. The root certificate may be omitted when the origin server possesses the trust anchor.
Example
A reverse proxy terminates mTLS and forwards both the client certificate and the validation chain to the origin server. The Client-Cert-Chain header contains the intermediate certificate followed by the root certificate in Structured Field Byte Sequence format (base64). The values are the example certificates from the specification. The origin server uses these to verify the client certificate against its trusted root certificate authority.
Client-Cert: :MIIBqDCCAU6gAwIBAgIBBzAKBggqhkjOPQQDAjA6MRswGQYDVQ
QKDBJMZXQncyBBdXRoZW50aWNhdGUxGzAZBgNVBAMMEkxBIEludGVybWVkaWF0ZS
BDQTAeFw0yMDAxMTQyMjU1MzNaFw0yMTAxMjMyMjU1MzNaMA0xCzAJBgNVBAMMAk
JDMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE8YnXXfaUgmnMtOXU/IncWalRhe
brXmckC8vdgJ1p5Be5F/3YC8OthxM4+k1M6aEAEFcGzkJiNy6J84y7uzo9M6NyMH
AwCQYDVR0TBAIwADAfBgNVHSMEGDAWgBRm3WjLa38lbEYCuiCPct0ZaSED2DAOBg
NVHQ8BAf8EBAMCBsAwEwYDVR0lBAwwCgYIKwYBBQUHAwIwHQYDVR0RAQH/BBMwEY
EPYmRjQGV4YW1wbGUuY29tMAoGCCqGSM49BAMCA0gAMEUCIBHda/r1vaL6G3VliL
4/Di6YK0Q6bMjeSkC3dFCOOB8TAiEAx/kHSB4urmiZ0NX5r5XarmPk0wmuydBVoU
4hBVZ1yhk=:
Client-Cert-Chain: :MIIB5jCCAYugAwIBAgIBFjAKBggqhkjOPQQDAjBWMQsw
CQYDVQQGEwJVUzEbMBkGA1UECgwSTGV0J3MgQXV0aGVudGljYXRlMSowKAYDVQQD
DCFMZXQncyBBdXRoZW50aWNhdGUgUm9vdCBBdXRob3JpdHkwHhcNMjAwMTE0MjEz
MjMwWhcNMzAwMTExMjEzMjMwWjA6MRswGQYDVQQKDBJMZXQncyBBdXRoZW50aWNh
dGUxGzAZBgNVBAMMEkxBIEludGVybWVkaWF0ZSBDQTBZMBMGByqGSM49AgEGCCqG
SM49AwEHA0IABJf+aA54RC5pyLAR5yfXVYmNpgd+CGUTDp2KOGhc0gK91zxhHesE
YkdXkpS2UN8Kati+yHtWCV3kkhCngGyv7RqjZjBkMB0GA1UdDgQWBBRm3WjLa38l
bEYCuiCPct0ZaSED2DAfBgNVHSMEGDAWgBTEA2Q6eecKu9g9yb5glbkhhVINGDAS
BgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBhjAKBggqhkjOPQQDAgNJ
ADBGAiEA5pLvaFwRRkxomIAtDIwg9D7gC1xzxBl4r28EzmSO1pcCIQCJUShpSXO9
HDIQMUgH69fNDEMHXD3RRX5gP7kuu2KGMg==:,
:MIICBjCCAaygAwIBAgIJAKS0yiqKtlhoMAoGCCqGSM49BAMCMFYxCzAJBgNVBAY
TAlVTMRswGQYDVQQKDBJMZXQncyBBdXRoZW50aWNhdGUxKjAoBgNVBAMMIUxldCd
zIEF1dGhlbnRpY2F0ZSBSb290IEF1dGhvcml0eTAeFw0yMDAxMTQyMTI1NDVaFw0
0MDAxMDkyMTI1NDVaMFYxCzAJBgNVBAYTAlVTMRswGQYDVQQKDBJMZXQncyBBdXR
oZW50aWNhdGUxKjAoBgNVBAMMIUxldCdzIEF1dGhlbnRpY2F0ZSBSb290IEF1dGh
vcml0eTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABFoaHU+Z5bPKmGzlYXtCf+E
6HYj62fORaHDOrt+yyh3H/rTcs7ynFfGn+gyFsrSP3Ez88rajv+U2NfD0o0uZ4Pm
jYzBhMB0GA1UdDgQWBBTEA2Q6eecKu9g9yb5glbkhhVINGDAfBgNVHSMEGDAWgBT
EA2Q6eecKu9g9yb5glbkhhVINGDAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQ
EAwIBhjAKBggqhkjOPQQDAgNIADBFAiEAmAeg1ycKHriqHnaD4M/UDBpQRpkmdcR
FYGMg1Qyrkx4CIB4ivz3wQcQkGhcsUZ1SOImd/lq1Q0FLf09rGfLQPWDc:
The origin server reconstructs the certificate path from the Client-Cert header and the chain in Client-Cert-Chain. The validation walks from the end-entity certificate through each intermediate certificate to confirm the chain links to a trusted root certificate authority.
The chain without its ends
Client-Cert-Chain deliberately excludes the leaf certificate, already travelling in Client-Cert, and permits omitting the root, which verifiers hold locally. What remains is the intermediate path the backend needs to validate against its trust anchors, encoded as a list of DER certificates, each base64-wrapped in colons, split across repeated header lines where convenient.
Size is the operational constraint. Certificate chains resist header compression, since the bytes are large and mostly unique, and oversized chains surface as 431 at strict hops. Cloudflare's implementation, the one major shipped support, caps the chain at 16 KB and raises a companion flag rather than truncating, so a backend distinguishes a missing chain from one over budget.
The encoding detail blocking wider adoption is worth knowing: each certificate is base64-encoded individually, so a proxy holding the chain as one concatenated DER blob cannot emit the header without splitting the chain first, which is the stated obstacle in at least one proxy's open feature request.