大型门户网站证书管理是贯穿业务全周期的隐性生命线，需覆盖自动巡检告警、统一密钥管控、多载体纳管及47天短周期自动化轮换。
大型门户网站的证书管理，从来不是配好 ssl_certificate 和 ssl_certificate_key 就完事的事。它是一条贯穿业务上线、流量增长、组织扩张与安全合规的隐性生命线——稍有松懈，就可能在凌晨三点弹出“此连接不安全”的告警，甚至引发全站 HTTPS 中断。
从人工盯表到自动续期：应对证书过期的生存战
早期，运维靠 Excel 表格记录数百个域名证书的到期时间，设置 Outlook 提醒提前 30 天处理。但随着站点数突破 2000+、CDN/SLB/边缘节点证书同步需求激增，手工操作开始频繁失守：漏续、私钥误传、证书链顺序错乱、NGINX reload 失败导致服务中断等问题集中爆发。2024 年一次跨部门协同疏漏，直接造成金融子站支付页证书过期 17 分钟，影响订单转化率 0.8%。
关键转变在于把“人盯”变成“系统巡检”：
- 平台每日自动扫描全网所有 HTTPS 端点，提取证书有效期、签发者、域名匹配度等字段
- 对剩余有效期 ≤60 天的证书触发一级告警（企业微信+邮件），≤15 天触发二级告警（电话+钉钉强提醒）
- 续期流程嵌入审批流：开发提单 → 安全组审核域名权限 → 自动 CSR 生成+CA 提交 → 验证通过后自动下载、解密、分发至目标集群
统一密钥生命周期：私钥不再散落各处
最初，私钥由不同团队自行生成并存于个人电脑或共享目录，部分甚至明文写在 Ansible 变量文件中。2023 年一次安全审计发现，12% 的生产环境私钥未加密存储，且无访问日志追踪。
重构后实行“一钥一策”管控：
- 所有私钥强制 AES-256 加密后存入 MySQL，密钥加密密钥（KEK）由 HSM 或 KMS 托管
- 私钥仅在部署时由平台解密注入内存，不落盘、不透出、不复用
- 每次证书申请/续期均生成全新密钥对，旧私钥自动标记为“已弃用”，7 天后物理清除
多环境多载体证书治理：NGINX、SLB、CDN 不再各自为政
一个主域名背后常对应 NGINX 入口层、云厂商 SLB、第三方 CDN、WAF、边缘计算节点等 5 类以上证书载体。过去各团队独立维护，常出现“CDN 证书已更新，SLB 还在用旧证书”的错配问题。
平台通过白屏化变更模块统一纳管：
- 支持按载体类型（nginx_conf / aliyun_slb / cloudflare_api / tencent_cdn）定义证书推送模板
- 变更前自动比对目标环境当前证书指纹，避免误覆盖
- 每次推送生成操作快照：谁、何时、向哪台机器/哪个 API 推送了哪个证书版本，全部可审计、可回滚
面向 47 天有效期的新基建准备
CABF 已正式通过 SC-081 提案，2026 年 3 月起 TLS 证书最长有效期降至 200 天，并将在 2029 年最终收窄至 47 天。这对证书管理体系提出质变要求：人工干预窗口几乎归零，自动化必须覆盖“申请→验证→签发→部署→监控→轮换”全链路。
vivo 互联网已在生产环境落地“双周期策略”：
- 平台默认按 45 天周期自动发起续期任务（预留 2 天缓冲）
- 所有证书配置项启用“自动重签”开关，CA 返回签发结果后 3 分钟内完成全链路分发
- 结合 OCSP Stapling + TLS 1.3 Early Data，确保证书轮换期间用户无感知
证书管理不是后台小功能，而是支撑亿级流量 HTTPS 稳定性的底层基础设施。它不炫技，但一旦失效，所有上层架构都失去可信基础。
