代理网关证书到期并不只是“记住一个日期”。客户端可能要验证代理入口的证书，代理还要验证上游服务，TLS 检查设备又会增加新的信任边界。长连接甚至可能把错误部署隐藏到连接回收之后，让故障看起来突然发生，实际上风险早已持续数周。
这份运行手册把证书续期变成可重复执行的运维流程，适用于正向代理、HTTPS 代理入口、API 网关、区域出口网关及托管代理集群。重点不是单次换证，而是让盘点、预警、预检、灰度、验证、回滚和证据留存形成闭环。
一、先画清全部 TLS 边界
按真实连接路径盘点，而不是只看架构图。逐一记录应用到代理网关、代理经 CONNECT 到目标站、代理到控制面或鉴权服务、负载均衡到代理节点、检查设备到客户端或源站、健康检查器到网关等所有会终止或发起 TLS 的位置。
每个边界至少记录主机名、预期证书颁发方、负责人、续期方式、部署对象、回滚负责人，以及是否依赖 SNI。还要确认 IPv4 与 IPv6 是否落到相同证书集；双栈环境经常出现一条路径已更新、另一条仍保留旧证书的情况。
盘点中不要保存私钥、令牌、代理密码或完整会话信息。监控通常只需要指纹、序列号、颁发者、有效期和公开证书链。
二、监控客户端实际收到的证书
只检查服务器磁盘上的证书文件并不可靠。应从客户端视角探测每个生产主机名，并覆盖各区域、负载均衡池、地址族和关键端口。采集叶证书的主体与备用名称、完整中间证书链、UTC 格式的生效和到期时间、SHA-256 指纹或序列号、协商协议、使用的主机名与地址族，以及可获得的节点或区域标识。
探针必须用正常信任库验证证书链和主机名。如果探针只读取到期时间，证书链缺失或名称不匹配时仍可能显示“正常”。
建议设置多级阈值：到期前 45 天确认所有权，30 天确认续期已启动，14 天安排部署，7 天升级处理，24 小时进入事件响应。实际窗口应结合证书寿命和变更流程调整。
三、把“到期风险”和“部署风险”分开
新证书有效，并不代表上线一定安全。部署前逐项检查：
- 访问主机名出现在证书备用名称中。
- 证书在所有节点时钟上已经生效。
- 所需中间证书完整且顺序正确。
- 不导出私钥的前提下确认公钥证书与私钥匹配。
- 密钥类型和签名算法兼容最老的受支持客户端。
- 每个 SNI 名称都会选择正确证书。
- IPv4、IPv6、各区域和灾备监听器使用目标证书包。
- 健康检查验证的主机名和信任路径与真实客户端一致。
时钟偏差要单独测试。若在证书生效时间刚到时部署，时钟落后的节点可能拒绝证书。应保持时间同步，并预留安全重叠窗口。
四、在具有代表性的环境中演练
测试矩阵至少包含当前客户端、最老受支持客户端、IPv4 与 IPv6、各鉴权方式、一条 CONNECT 隧道、平台支持时的一次直接 HTTPS 代理请求，以及一条长期复用连接。
演练必须回答三个问题：新连接能否完成 TLS 与鉴权；代理能否建立并验证上游连接；热加载或替换节点时，已有连接如何变化。
还应主动模拟缺少中间证书、主机名错误、不受信任证书链和时钟越界。监控应能区分这些原因，而不是全部归为“超时”。进一步排查可使用HTTPS 代理 TLS 排错指南；如果连接池干扰结果，可参考代理连接池管理。
五、通过重叠、金丝雀和明确回滚条件上线
不要把全量替换当作第一次生产测试。按以下顺序操作：
- 将新证书包加载到一个小型金丝雀池。
- 从节点外部确认指纹和完整证书链。
- 发送包含代理鉴权和真实上游请求的合成流量。
- 观察握手失败率、连接延迟、HTTP 状态分布、鉴权错误和上游 TLS 错误。
- 按区域和地址族逐步扩大流量。
- 在观察窗口结束前保留上一份证书包。
- 所有监听器和恢复路径通过验证后再下线旧包。
开始前就定义回滚触发器，例如 TLS 错误显著上升、出现新的名称不匹配、证书链缺失或金丝雀转化失败。触发后应回滚证书包或摘除故障池，绝不能用关闭证书验证来掩盖问题。
六、验证时强制建立新连接
连接复用可能制造假象。轮换前建立的 TCP/TLS 会话可以继续工作，却完全没有看到新证书。因此必须分别测试已有会话和强制新建的会话：前者验证平滑连续性，后者确认新证书确实已被呈现并受到信任。
部署后只回收一小部分连接，先从多个客户端网络验证新握手，再观察正常连接池是否恢复。除非产品设计明确要求，否则不要同时终止整个集群的连接。
七、用证据给故障分类
- 已到期或尚未生效：检查续期时间、节点时钟及 SNI 实际选择的证书。
- 主机名不匹配：比较请求名称、证书备用名称和监听器配置。
- 未知颁发者：检查客户端信任库及目标环境是否应信任该颁发方。
- 证书链不完整：检查网关证书包及所有必需的中间证书。
- 仍呈现旧证书：查找过期节点、备用监听器、IPv6 路径和负载均衡池。
- 握手成功但代理请求失败：把入口 TLS、代理鉴权、CONNECT 策略、上游 TLS 和源站行为分别验证。
- 仅部分客户端失败：比较协议版本、签名算法、信任库年龄、SNI 行为和检查策略。
所有时间使用 UTC。客户端标识应哈希或脱敏，只保留比较节点所需的证据，不保留敏感载荷。
八、关闭变更并改进下一次轮换
上线完成后再次探测全部端点，归档新指纹、颁发者、有效期、部署时间和负责人，并确认到期告警追踪的是线上监听器，而不是某个未被使用的本地文件。
复盘失败探针、慢区域和手工步骤，把重复检查逐步自动化，同时保留可读的回滚说明。代理凭据轮换可按代理凭据轮换指南单独协调；证书和凭据可以共享维护窗口，但二者的失败模式不同。
运维检查清单
- 已盘点全部主机名、区域、端口、IPv4 与 IPv6 路径。
- 探针从客户端侧验证主机名、证书链和有效期。
- 每级到期告警均有负责人和升级路径。
- 新证书通过备用名称、链、密钥匹配、SNI 和兼容性检查。
- 当前及最老受支持客户端均完成演练。
- 金丝雀流量包含鉴权与真实上游请求。
- 已有连接与新建连接分别验证。
- 回滚标准和旧证书包均已就绪。
- 没有引入任何证书验证绕过。
- 最终指纹与日期已记录，且未写入秘密信息。
常见问题
只检查到期时间够吗？
不够。客户端还会验证主机名、信任链、生效时间、算法兼容性和相关策略。监控必须对公开监听器执行正常验证。
为什么只有一个区域仍看到旧证书？
常见原因是旧节点、次级负载均衡、IPv6 监听器、灾备池或长连接。应强制新建连接，并记录解析地址和证书指纹。
轮换后要重启全部代理节点吗？
只有网关明确要求时才需要。优先使用平滑加载、金丝雀节点和受控连接排空，以保持容量和已有会话稳定。
能否临时关闭 TLS 验证恢复服务？
这会引入新的安全与完整性风险。应回滚到最后可信证书包、摘除错误节点，或修复证书链和主机名。
合规说明
仅在获得授权的代理基础设施和端点上使用本流程。妥善保护私钥与凭据，最小化连接数据留存，遵守适用地区的隐私与安全要求，不得为了让错误部署表面“恢复”而削弱 TLS 验证。
