The header value contains the client certificate from the mutually-authenticated TLS connection between the client and reverse proxy, which enables the backend origin server to utilize the certificate in its application logic. This document aspires to standardize an HTTP header field named Client-Cert that a TLS terminating reverse proxy adds to requests that it sends to the origin or backend servers. A standardized approach to this commonly functionality could improve and simplify interoperability between implementations. This solution works to some extent but interoperability between independently developed components can be cumbersome or even impossible depending on the implementation choices respectively made (like what header names are used or are configurable, which parts of the certificate are exposed, or how the certificate is encoded). A common way this information is conveyed in practice today is by using non-standard headers to carry the certificate (in some encoding) or individual parts thereof in the HTTP request that is dispatched to the origin server.
In order for these types of application deployments to work in practice, the reverse proxy needs to convey information about the client certificate to the origin application server. The specific details from the certificate needed also vary with the application requirements. Such logic might include access control decisions, audit logging, and binding issued tokens or cookies to a certificate, and the respective validation of such bindings. ¶Īlthough not exceedingly prevalent, TLS client certificate authentication is sometimes employed and in such cases the origin server often requires information about the client certificate for its application logic. The deployment pattern is found in a number of varieties such as n-tier architectures, content delivery networks, application load balancing services, and ingress controllers. Although HTTPS is also usually employed between the proxy and the origin server, the TLS connection that the client establishes for HTTPS is only between itself and the reverse proxy server. The backend details of this type of deployment are typically opaque to clients who make requests to the proxy server and see responses as though they originated from the proxy server itself.
The origin servers are not directly accessible by clients and are only reachable through the reverse proxy.
The proxy is accessible to the internet and dispatches client requests to the appropriate origin server within a private or protected network. A fairly common deployment pattern for HTTPS applications is to have the origin HTTP application servers sit behind a reverse proxy that terminates TLS connections from clients.
0 kommentar(er)
