Title: Support RFC 9440 (Client-Cert / Client-Cert-Chain) HTTP header fields

Title: Support RFC 9440 (Client-Cert / Client-Cert-Chain) HTTP header fields

Description:

RFC 9440 (Informational, July 2023) standardizes two HTTP header fields — Client-Cert and Client-Cert-Chain — that a TLS-terminating reverse proxy uses to convey mTLS client certificate information to backend origin servers. The certificate is DER-encoded, Base64-encoded, and wrapped in colons (e.g. :MIIDsT...Vw==:), with the chain expressed as a comma-separated list of such values, per the RFC 8941 structured-field syntax. Envoy currently forwards client certificate information only via its own x-forwarded-client-cert (XFCC) header, configured through forward_client_cert_details / set_current_client_cert_details. The XFCC format is Envoy-specific (semicolon-separated Key=Value pairs with URL-encoded PEM) and is not interchangeable with the RFC 9440 headers, so backends expecting the standardized format cannot consume Envoy's output without a custom translation step (Lua, ext_proc, etc.). It would improve interoperability if Envoy could natively emit RFC 9440-compliant Client-Cert and Client-Cert-Chain headers — for example, as an additional ForwardClientCertFormat option, or as dedicated fields under set_current_client_cert_details. Per RFC 9440 §4, any incoming Client-Cert / Client-Cert-Chain headers must be sanitized (removed/overwritten) before forwarding to prevent client spoofing; a compliant implementation should handle this. Prior art / related:

HAProxy: haproxy/haproxy#2235 Traefik: traefik/traefik#11713 nginx: nginx/nginx#178 Cloudflare shipped RFC 9440 fields (March 2026) Related Envoy issue (chain forwarding via XFCC): #6135

RFC: https://www.rfc-editor.org/rfc/rfc9440.html