2.4. Processing Rules

2.4. Processing Rules

This section outlines the applicable processing rules for a TTRP that has negotiated a mutually authenticated TLS connection to convey the client certificate from that connection to the backend origin servers. This technique is to be used as a configuration or deployment option, and the processing rules described herein are for servers operating with that option enabled.

A TTRP negotiates the use of a mutually authenticated TLS connection with the client, such as is described in [TLS] or [TLS1.2], and validates the client certificate per its policy and trusted certificate authorities. Each HTTP request on the underlying TLS connection is dispatched to the origin server with the following modifications:

1. The client certificate is placed in the Client-Cert header field of the dispatched request, as described in Section 2.2.

2. If so configured, the validation chain of the client certificate is placed in the Client-Cert-Chain header field of the request, as described in Section 2.3.

3. Any occurrence of the Client-Cert or Client-Cert-Chain header fields in the original incoming request MUST be removed or overwritten before forwarding the request. An incoming request that has a Client-Cert or Client-Cert-Chain header field MAY be rejected with an HTTP 400 response.

Requests to the TTRP made over a TLS connection where the use of client certificate authentication was not negotiated MUST be sanitized by removing any and all occurrences of the Client-Cert and Client-Cert-Chain header fields prior to dispatching the request to the backend server.

Backend origin servers may then use the Client-Cert header field of the request to determine if the connection from the client to the TTRP was mutually authenticated and, if so, the certificate thereby presented by the client. Access control decisions based on the client certificate (or lack thereof) can be conveyed by selecting response content as appropriate or with an HTTP 403 response, if the certificate is deemed unacceptable for the given context. Note that TLS clients that rely on error indications at the TLS layer for an unacceptable certificate will not receive those signals.

When the value of the Client-Cert request header field is used to select a response (e.g., the response content is access-controlled), the response MUST either be uncacheable (e.g., by sending Cache-Control: no-store) or be designated for selective reuse only for subsequent requests with the same Client-Cert header field value by sending a Vary: Client-Cert response header. If a TTRP encounters a response with Client-Cert or Client-Cert-Chain in the Vary header field (Section 12.5.5 of [HTTP]), it SHOULD prevent the user agent from caching the response by transforming the value of the Vary response header field to *.

Forward proxies and other intermediaries MUST NOT add the Client-Cert or Client-Cert-Chain header fields to requests or modify an existing Client-Cert or Client-Cert-Chain header field. Similarly, clients MUST NOT employ the Client-Cert or Client-Cert-Chain header field in requests.