1. 引言

1. 引言

HTTPS 应用的一种相当常见部署模式是: 源 HTTP 应用服务器位于反向代理之后, 由反向代理终止来自客户端的 TLS 连接. 该代理可从互联网访问, 并将客户端请求分派到私有或受保护网络中的适当源服务器. 源服务器不能由客户端直接访问, 只能通过反向代理到达. 这种部署的后端细节通常对客户端不透明; 客户端向代理服务器发出请求, 并看到仿佛源自代理服务器本身的响应. 虽然代理和源服务器之间通常也会使用 HTTPS, 但客户端为 HTTPS 建立的 TLS 连接只存在于客户端自身和反向代理服务器之间.

这种部署模式存在多种变体, 例如 n 层架构、内容分发网络、应用负载均衡服务和入口控制器.

虽然 TLS 客户端证书认证并非极其普遍, 但有时会被采用; 在这种情况下, 源服务器通常需要客户端证书信息来执行其应用逻辑. 这类逻辑可能包括访问控制决策、审计日志记录, 以及将签发的令牌或 Cookie 绑定到证书, 包括对这些绑定进行相应验证. 应用需求不同, 从证书中需要的具体细节也不同. 为了让这类应用部署在实践中正常工作, 反向代理需要把客户端证书信息传递给源应用服务器. 在撰写本文时, 传递这类信息的一种常见方式是在分派给源服务器的 HTTP 请求中, 使用非标准字段携带证书 (采用某种编码) 或其各个组成部分. 该方案可以工作, 但独立开发的组件之间的互操作性可能很繁琐, 甚至因各自实现选择而无法实现, 例如使用或可配置哪些字段名、暴露证书的哪些部分、或者证书如何编码. 对这种常见功能采用一种众所周知且可预测的方法, 可以改善并简化独立实现之间的互操作性.

本文档的范围是在描述现有实践的同时, 将足以促进更好、干预更少的互操作性的具体细节规范化. 因此, 本文档描述两个 HTTP 头字段, "Client-Cert" 和 "Client-Cert-Chain"; 终止 TLS 的反向代理 (TLS terminating reverse proxy, TTRP) 会将它们添加到发送给后端源服务器的请求中. Client-Cert 字段值包含发起客户端与 TTRP 之间相互认证 TLS 连接中的终端实体客户端证书. 可选地, Client-Cert-Chain 字段值包含用于验证终端实体证书的证书链. 这使后端源服务器能够在其应用逻辑中使用客户端证书信息. 尽管 TTRP 和源服务器之间可能存在额外代理或跳数 (甚至它们之间也可能使用相互认证的 TLS 连接), Client-Cert 头字段的范围有意限制为: 向源服务器暴露发起客户端在其连接到 TTRP 时所出示的证书.