每个人都可以，
拥有SSL证书

腾讯云这则通知里有个信息容易被忽略：CFCA从九月中旬开始，默认用 Global RSA ROOT G2 签发公共可信 TLS 证书，原来的 CFCA EV ROOT 不再作为默认根。同时 DigiCert、GlobalSign、TrustAsia 的证书链也要跟着 Chrome 的根证书策略同步调整。

看起来只是 CA 机构换个根，但对线上业务来说，这种变更的杀伤力往往比证书到期更隐蔽。

根证书切换的本质，是浏览器信任锚的迁移。客户端验证证书链时，会从站点证书一路往上验到本地预埋的根证书。

一旦 CA 换了根，而客户端环境里没预载这个新根，整条链路就直接判定失败。报错通常长这样： unable to verify the first certificate 或者 certificate signed by unknown authority。

CFCA 原来的 EV ROOT 在国内政企、金融类客户环境里预载率极高，很多老版本操作系统、嵌入式终端、老旧网关只认这个根。

新签发的证书换到 G2 根之后，这些终端如果不更新根证书库，访问就会大面积报错。

这类问题最麻烦的地方在于——它不会在签发那一刻爆出来。证书部署上去，研发自测用的新系统、新浏览器都正常，测完上线，过两天客服开始接到反馈：某银行客户说打不开、某地政务终端说证书无效。

排查一圈才发现是终端根证书太老。

Google Chrome 推动单一用途根证书层级，也是同样的逻辑。

以前很多 CA 用同一个根同时签发 TLS 证书和邮件签名证书、代码签名证书，权限边界模糊。一旦某个用途的私钥出问题，整个根都要吊销，波及面太大。Chrome 要求把 TLS 签发迁到专用根，对 CA 而言更规范，对运维而言意味着未来几年这类根切换会反复出现。

面对这种不可控的外部变更，手工管理证书的团队几乎没法高效响应。想象一个场景：公司有八十个域名，证书分散在三家 CA，到期时间各不相同。某天收到通知说其中一家的根要切了，你得先人工筛出所有受影响证书，逐个登录 CA 后台申请重签，再登服务器替换，还要同步更新负载均衡、CDN、WAF 上的证书副本。

实际操作中多半会漏。漏掉的那个域名，就是事故。

自动化证书管理的价值在这种场景下会被放大。

ACME 协议是目前事实上的行业标准，Let's Encrypt、Google Trust Services、ZeroSSL 这些 CA 都基于它提供免费的短期证书签发。核心思路是：证书申请、验证、部署、续签全部走 API，不碰后台页面。

lcjmSSL 这类平台做的事，是把 ACME 的复杂度进一步收拢。多域名、泛域名、IP 证书一个入口处理，自动验证域名归属，提供简洁的 API 对接现有发布流程。

对运维来说，根切换不再是“逐个证书排查”的体力活，而是一次策略调整后批量续签、自动部署的动作。

证书从一年期向九十天短期化演进，加上根层级持续调整，留给手工操作的空间会越来越小。

与其每次被动应对，不如把证书生命周期交给自动化体系。根会继续切，但影响可以控制在分钟级。