TLS 终结教会我们的事：爆炸半径

证书在终结节点过期，是一个可用性事件，而不是一个配置细节。

去年年底，我们边缘代理上的一张证书过期了。监控系统尽职地发出了告警，值班工程师续签了证书并重新加载了服务，总停机时间不到四分钟。从大多数指标来看，这算是个不错的结果。但事后复盘发现了一件令人不安的事：同一张证书还被用在其他六个地方。边缘节点承载着一个从未有人认真评估过的爆炸半径。

TLS 终结集中了风险。每个在同一进程、同一台机器、同一个密钥仓库中终结 TLS 的服务，都创造了一个续签单点。如果续签失败——无论是因为 ACME 客户端权限丢失、DNS 验证超时，还是私钥被意外轮换——该终结器背后的每一个虚拟主机都会停止服务。

我们现在对每个 TLS 终结器追踪三件事：

• 如果这个终结器停止工作，会影响多少个不同的服务？
• 真实的续签路径是什么——不是理论上的那条，而是每个月一号实际运行的那条？
• 在续签重试期间，是否可以用旧证书继续提供服务？

如果续签操作可以在终结器继续使用旧证书的同时成功完成，那你拥有的不是续签自动化，而是一个定时通知系统，告诉你出了点问题。

让终结器保持精简

每一个提供证书的服务都必须信任一个密钥仓库、一条续签路径和一个重载机制。这是大量的信任集中在一个点上，所以终结器应该尽可能少做其他事情。你在它上面堆叠的功能越多，单个文件过期造成的爆炸半径就越大。

这些都不是什么高深的理论。区别在于你是在自动化一个任务，还是在自动化一个结果。