4. 证书管理现状梳理与证书生命周期归纳总结
说实话,我见过太多团队在大规模迁移 TLS 时,第一件事就是急着去改配置、换证书。结果呢?半年后才发现有些证书已经过期了,还有些根本找不到谁签发的。你想想看,迁移最怕的不是技术问题,是——你不知道自己手里到底有多少张证书。
4.1 为什么必须先做现状梳理
我个人习惯是这样的:凡是大规模迁移,第一步不碰命令行,而是先拉一份 证书资产清单。别小看这个动作,我在项目中遇到过好几次——客户说“我们一共就 50 张证书”,结果一排查出来 200 多张,其中 30 张已经过期,还有 20 张是自签名。要是不梳理清楚,迁移方案设计得再漂亮也会翻车。
我曾经接手过一个金融客户的项目,他们纸质台账上写着「3 张根证书、15 张服务器证书」。等我把所有服务器的 .pem 文件扫了一遍,发现实际有 42 张。原因很简单:每个团队各自用各自买的证书,没有统一管理。你以为这算完了?更离谱的是,其中 5 张证书的私钥竟然还放在共享文件夹里。所以,梳理现状不是走过场——它直接决定你下一步的迁移范围和安全基线。
4.2 证书资产发现——你应该查什么
梳理现状其实就干两件事:「全量发现」和「属性登记」。前者是找出所有证书藏在哪,后者是给每张证书打上标签。
4.2.1 全量发现手段
- 网络扫描:用
nmap --script ssl-cert扫的 443/8443 端口,拿到服务器证书列表。 - 配置审计:对 Nginx、Apache、HAProxy、Envoy 等代理的配置文件做 grep,提取
ssl_certificate、tls-certificate等路径。 - 文件系统遍历:用
find / -name "*.crt" -o -name "*.pem" -o -name "*.cert"扫一遍所有服务器。 - CMDB 拉取:如果公司有资产管理系统,直接拉取所有绑定 SSL 的域名和 IP。
- 容器集群:遍历
kubectl get secret --all-namespaces | grep tls,找出所有 Ingress 证书。
嗯,这里要注意:很多证书在侧边服务、内部 API、负载均衡上,不扫端口根本发现不了。我建议你把上述 5 种方法都跑一遍,再交叉去重,得到一份 去重后的证书资产列表。
小技巧:写个自动化脚本,每天凌晨扫一次并把差异输出到邮件。这样你就能知道——哪些证书是「新增」的,哪些是「删除」的。我自己的团队就在用这个方案,省掉了月报的手工核对时间。
4.2.2 证书属性登记表
每一张证书至少要记录以下属性。我通常用一张表格来管理:
| 字段 | 示例值 | 说明 |
|---|---|---|
| 证书序列号 | 04:7B:CE:2A... |
唯一标识,用于去重和吊销 |
| 通用名(CN) | *.example.com |
通配符还是单域名?影响迁移策略 |
| 颁发者(CA) | Let's Encrypt |
内部 CA 还是公共 CA?决定信任链 |
| 生效日期 / 过期日期 | 2024-01-01 ~ 2025-01-01 | 判断是否即将过期,必须记录到期提醒 |
| 私钥位置 | /etc/ssl/private/example.key |
私钥必须受保护,路径要可审计 |
| 部署位置 / 业务方 | 支付网关 / 交易组 |
谁在用这张证书?联系人是谁? |
| 证书类型 | DV / OV / EV | DV 可以自动续期,OV/EV 需要人工审核 |
你想想看,如果你连「证书在哪个负载均衡上」「谁负责续费」都不知道,迁移时你怎么做灰度切换?所以这张表得动态维护,最好跟 CMDB 联动。
4.3 证书生命周期——你真的理解它了吗
很多工程师觉得证书生命周期就是「申请→安装→过期→续期」,太粗糙了。我把它拆成 7 个阶段,每个阶段都有坑:
- 规划:选择 CA、确定域名规则、决定证书类型(单域/通配符/多SAN)、预评估成本。
- 申请:生成 CSR、提交给 CA 验证域名/组织、等待签发。注意 CSR 的密钥长度至少 2048,推荐 4096。
- 部署:安装证书到服务器、配置中间证书链、重启服务验证。千万别直接覆盖前人的文件——我曾见过有人把生产环境的 CA 证书替换掉,导致所有客户端握手失败。
- 监控:证书过期前 30 天、14 天、7 天、1 天分别告警。用
openssl x509 -enddate -noout或 Prometheus Blackbox Exporter 做轮询。 - 续期:重新签发新证书(不是重新颁发同序列号)。对于 Let's Encrypt,自动续期;对于商业 CA,通常提前 1 个月发起续费流程。
- 替换:灰度替换旧证书。比如先在 5% 的节点上部署新证书,确认无业务报错后再全量替换。
- 回收/吊销:旧证书到期后继续留存 CRL 或 OCSP 记录,直到新证书完全接管。不要立即删除——我曾在项目中因为删掉根证书的 key,导致无法撤销子证书的 CRL。
4.4 生命周期管理的三个常见误区
我见过太多团队在生命周期管理上栽跟头,列三个最常见的:
- 误区一:只关注服务器证书,忽略中间证书和根证书——中间证书其实也有有效期,而且经常比叶证书短。如果中间证书过期,服务端的证书链就不完整,客户端会报错。我记得某次线上故障就是根因在这里。
- 误区二:觉得续期就是重新部署一次,不需要测试——大错特错。新证书的密钥指纹不同,如果客户端做了证书锁定(Certificate Pinning),必须同步更新客户端。我在一个 IoT 项目上吃过这个亏:换了证书,设备全部连不上。
- 误区三:吊销后直接删文件——吊销证书后,CA 会签发 CRL 说明该证书已废。如果你把私钥和证书删了,以后想验证吊销链都没办法。正确的做法是把私钥移到离线存储,保留完整证书文件到吊销期结束。
4.5 制度化——从手工到自动化
梳理现状不是一次性的。我建议你把它变成 持续过程:
- 建立证书资产台账平台:用 ELK 或自定义数据库存储每张证书的属性,每天同步一次。
- 使用 ACME 协议自动申请/续期:Let's Encrypt 免费又好用,内部 CA 也可以跑 Smallstep CA。
- 设置自动告警:对接 Prometheus Alertmanager,证书剩余天数 < 30 就 P3 告警,< 7 就 P1。
- 生命周期流程可视化:在内部运维平台展示「从规划到回收」的状态,让每个阶段都有负责人。
我个人习惯的做法是:每次月会上拉出一张「证书健康度仪表盘」,展示剩余天数分布、最近续期成功率、待回收证书数量。这样管理层一目了然,也能倒逼业务方及时配合迁移。说白了,证书管理做得好不好,不看代码写得漂不漂亮,而看你的「发现能力」和「闭环能力」。