Summary

  • HTTP 工作组服务器次级证书草案第 03 版于 2026 年 11 月 2 日更新，仍是 Internet-Draft。它提出 SERVER_CERTIFICATE 帧，让 HTTP/2 或 HTTP/3 服务器在 TLS 连接建立后，证明自己持有另一网站证书对应的私钥。
  • 双方须先声明支持。RFC 9261 的导出认证器把额外证书的持钥证明绑定到现有 TLS 会话；客户端还要判断证书和服务器是否适合第二个来源站点。
  • 草案第 7.3 节点出迁移陷阱：更改 CNAME 会把新连接导向新服务商，旧服务商却可能在为其他站点建立的连接中继续出示已迁走站点的次级证书。这项持续服务风险需要服务商与客户处理。

设想一家出版商迁离托管服务商。它修改 CNAME，新连接已到达继任者；读者浏览器却仍与旧服务商托管的另一个站点保持 HTTP/2 连接。旧服务商还保存出版商网站的证书，并沿现有连接发来持钥证明。如果客户端据此接受旧连接服务迁走的网站，后续请求便可能走回旧路。这是按草案风险机制设计的测试情境。

技术诱因很明显。HTTP/2 和 HTTP/3 允许在服务器对多个来源站点均有权限时复用连接。TLS 握手中一张证书可以涵盖多个域名，但托管服务商可能希望各客户的证书独立续期和撤销。新草案试图同时保留证书分离和连接共享。真正难的问题是：第二个站点今天还授权这条连接吗？

一条连接添上一重身份

机制先要求双方明示支持。客户端和服务器都须在 SETTINGS 中把 SETTINGS_HTTP_SERVER_CERT_AUTH 设为 1；少了任一方，不能使用这套证书交换。随后服务器可随时发送 SERVER_CERTIFICATE 帧。HTTP/2 将其放在流 0，HTTP/3 放在控制流。帧内的导出认证器证明发送者在这次 TLS 会话中持有额外证书的私钥。只拿出一份证书文件，无法完成这项会话绑定的证明。

客户端先验证认证器，再检查证书能否为目标站点使用。两种失败不能混为一谈：认证器无效是连接错误；证书过期、撤销或不适用于请求，则是证书不可接受，草案建议客户端新建连接寻找有权服务的服务器。共享连接可以完好无损，第二站点却被拒绝。只看连接成功率的监控会漏掉这个分叉。

安全部分写得更尖锐。若次级证书及其私钥落入恶意服务器之手，攻击者只需引导客户端访问自己控制的某个 HTTPS 网站，就能在那条连接上展示另一个网站的失窃凭据。草案要求：如果客户端在初次 TLS 握手中本会为目标名称查 DNS，那么面对次级证书也应查 DNS。不查 DNS 时，ORIGIN 帧等另一种权限信号可以加强判断。证书证明谁握着钥匙；DNS 与站点授权告诉客户端今天该往哪里走。

DNS 换了方向，旧连接还在

第 7.3 节描绘的是日常迁移，无需失窃密钥。网站所有者改掉 CNAME，新连接抵达新服务商；旧服务商仍会为其他客户接收连接，且可能保留迁出网站的次级证书配置。它因而能在共享连接上继续声称服务该站点。草案认为这种行为符合旧服务商的配置，却很可能背离网站所有者的意愿；拟议协议没有内置的关门指令，只要求服务商事先提醒客户。

因此，退出计划需要一串独立证据。谁还保有私钥？哪些服务器仍发送次级证书？证书何时撤销或从配置中移除？客户端是否重新检查第二站点的权限？新 DNS 回答只说明新连接的方向，无法显示旧连接里的请求；旧连接清单也无法单独说明请求实际去了哪里。必须把两份记录接起来。

草案还禁止客户端在 TLS 会话恢复后沿用此前对次级证书的验证结论。服务器可以重新发送证书，客户端必须重新判断。同一条连接处理请求期间，可用证书集合也可能改变，客户端要准备重新评估请求权限。连接数量省下了，信任状态管理的账单却转到了客户端。

官方原始文件没有部署数量，也没有实测迁移事故。一次受控迁移若同时记录 DNS、现有连接、证书帧和请求去向，就能检验这条风险路径。当前可执行的结论已很具体：退出旧服务商时，撤掉次级证书通道应与更改 DNS 别名同样认真。街上的路牌换了，旧楼里的钥匙不会自行失效。

HTTP 草案 · RFC 9261 · RFC 9113 · RFC 9114 · RFC 8336