大规模设备证书轮换 - 第1节

1. 证书轮换概述：为什么需要大规模证书轮换？

说实话，我最早接触证书轮换这事儿，是在一次半夜的故障排查中。那会儿我还在做 CDN 平台运维，凌晨三点，突然大面积服务不可用。查了半天，发现是一张 CDN 节点证书过期了。嗯，就一张证书，影响了十几个地区的用户。

那次之后我才真正意识到——证书不是配好就能忘的东西。尤其在设备规模上来之后，证书管理就成了一个系统性工程。

为什么证书会过期？

你可能会想，为什么不能把证书有效期设成 100 年？

其实早期确实有人这么干。但后来行业发现，长期有效的证书一旦泄露，攻击者可以伪装你的身份好几年。所以 CA/B 论坛（证书颁发机构联盟）不断缩短证书有效期。我记得 2020 年还是 825 天，2023 年就缩到了 398 天。现在苹果和谷歌都在推动 90 天有效期。

这意味着什么？

意味着以前三年轮换一次，现在一年一次，未来可能一个季度一次。设备数量一上来，手动操作根本扛不住。

大规模证书轮换的典型场景

我简单列几个我在项目中见过的场景：

• IoT 设备集群：几十万台传感器，每台都有设备证书。轮换一次，光下发新证书就得跑好几天。
• 微服务网格：几百个服务实例，mTLS 双向认证。轮换时如果顺序不对，服务间通信直接断掉。
• 边缘节点：几千台 CDN 节点、边缘网关，分布在全国各地。证书更新不能中断业务。
• Kubernetes 集群：etcd、kube-apiserver、kubelet 都有自己的证书。我见过有人轮换 etcd 证书时顺序搞反，整个集群挂了半天。

这些场景有一个共同点：不能停。你不能说「大家等一下，我换个证书」。业务 7×24 小时跑着，轮换必须在线完成。

证书生命周期管理基础

证书不是「申请→安装→忘记」这么简单。我习惯把证书生命周期分成五个阶段：

阶段	关键动作	常见问题
申请	生成密钥对、CSR、提交 CA 签发	私钥强度不够、CSR 信息填错
分发	将证书+私钥部署到目标设备	传输过程中泄露、设备离线无法接收
使用	TLS 握手、mTLS 认证、代码签名	证书链不完整、OCSP 不可达
监控	检查有效期、吊销状态、密钥强度	监控遗漏、告警阈值设置不合理
轮换	签发新证书、替换旧证书、清理旧证书	新旧证书交替期间服务中断

这里我想特别强调一下监控阶段。很多人觉得证书装上就完事了，等到浏览器报「证书过期」才去处理。我建议你在证书到期前 30 天、14 天、7 天、3 天分别设置告警。别问我为什么是四个时间点——有一次我 7 天告警没收到，3 天告警才反应过来，结果那天是周五下午，CA 那边下班了……

轮换策略的核心原则

做了这么多年证书轮换，我总结出四条核心原则。说白了，就是四个字：稳、快、准、安。

原则一：零信任轮换

不要假设旧证书还能用。轮换时，新证书必须独立验证。我见过有人轮换时直接覆盖旧证书，结果新证书有问题，回滚都来不及。

正确的做法是：先部署新证书，验证通过后再移除旧证书。新旧并存一段时间，确保业务无感。

原则二：灰度发布

别一次性全量轮换。先拿一台设备试，观察 24 小时，没问题再扩大到 10%，再到 50%，最后全量。这个节奏我踩过坑——有一次我自信满满地全量推送，结果新证书的 OCSP 响应慢了三倍，所有设备握手延迟飙升。

原则三：可回滚

每次轮换前，确保旧证书还在设备上，或者至少能快速恢复。我建议保留至少两代证书：当前在用 + 上一代。这样出问题时，切回上一代只需要改个配置，不用重新签发。

原则四：自动化优先

手动轮换 10 台设备还行，100 台就开始出错，1000 台基本不可能。我见过一个团队，20 台服务器手动轮换，结果漏了 3 台，半夜被叫起来补换。所以，能自动化的地方，绝对不要手动。

知识体系总览

下面这张图是我自己整理的证书轮换知识体系。你可以把它当成这一章的「地图」，后面每个章节都会对应到其中的一个模块。

这张图把证书轮换拆成了四个层次：核心目标 → 四大原则 → 生命周期阶段 → 典型场景 & 技术栈。后面每一章都会围绕其中一个模块展开。

嗯，这一章就到这里。记住一句话：证书轮换不是一次性任务，而是一个持续的过程。后面我们会一步步深入每个环节，从工具选型到自动化脚本，再到灰度发布和应急回滚，把整个体系搭起来。