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

Mozilla根存储政策v3.1已经全面生效，Firefox信任库里的所有CA都开始按新规走。这次修订没有让现有证书立刻失效，但把根证书的职能边界、审计上报时限、最长使用年限和CT日志要求全部收紧。

对依赖老根链路的业务，真正的压力点在2028年底前那波根证书职能拆分。

最容易被忽略的是专用根证书机制。

以前不少CA的同一个根证书既给网站TLS认证用，又给S/MIME邮件加密用。新规要求新增根证书只能单独用于网站TLS认证或S/MIME邮件加密，禁止一证多用，存量双重用途老根证书需在2028年底前完成拆分。

用生活化的话说，这就像公司公章以前既能签合同又能签发票，现在要求分两个章，各管各的。

根证书在信任链里就是那个最终担保人，它一旦被吊销或调整用途，链路上所有已签发证书的信任都会受影响。

你可以用一条命令查看证书的Extended Key Usage：

openssl x509 -noout -text -in cert.pem | grep -A1 "Extended Key Usage"

如果同时看到TLS Web Server Authentication和E-mail Protection，就属于这次政策点名的双重用途证书。浏览器侧一旦触发根链问题，报错通常是SEC_ERROR_REVOKED_CERTIFICATE或MOZILLA_PKIX_ERROR_ADDITIONAL_POLICY_CONSTRAINT_FAILED。

另一个被低估的变化是根证书最大使用年限。根密钥生成满15年后自动撤销网站TLS信任标记，大量运营十余年的老一代根证书进入生命周期尾声。这跟身份证到期很像，人还在，但不能再坐高铁、住酒店。根证书本身没有失效，只是在Firefox侧不再作为网站TLS信任锚点。

这意味着后续续费、重签发证书会默认切换至新一代根链路。运维侧要关注的不只是证书到期时间，还包括证书链顶端的根是不是老根，切换后旧设备、旧系统是否内置了新根。部分老版本Android、iOS和嵌入式设备只认老根，新根链证书在这些终端上可能直接握手失败。

证书生命周期管理别只盯着过期时间

很多团队的证书监控还停留在过期前30天提醒。

Mozilla v3.1把CT日志要求也进一步收紧，限制绕过CT日志签发证书的场景。一旦CA违规，证书错误签发、密钥泄露等安全事件的上报时限被强化，违规CA可能被限期整改甚至移出Firefox根商店。

这时候手动管理证书的风险会集中暴露。

短周期证书、多域名、泛域名和IP证书的需求同时存在，每次续签还要确认根链变化、CT日志状态、客户端兼容性，人工脚本很难跟上节奏。

lcjmSSL这类基于ACME协议的免费证书平台，把Let's Encrypt、Google Trust Services、ZeroSSL的签发能力统一到一个API入口，支持多域名、泛域名和IP证书，自动完成申请、验证和部署。根链切换发生时，平台侧会跟随上游CA默认选择新根链，业务方不用在CSR生成和续期脚本上反复折腾。

对已经在用certbot或acme.sh的团队，命令本身没变，certbot renew --dry-run依然能验证续期流程，但脚本里若不检查根链和CT日志，根策略变化后可能出现证书续上了、终端却不信任的情况。

对运维来说，ACME自动化的价值不只是省事。

根策略收紧后，证书签发链路会越来越短、轮换越来越快，人工处理每一次根链切换和CT日志校验并不现实。把证书生命周期托管给支持ACME协议的平台，至少能让续期、吊销、重签这些动作从月级维护变成自动化流程。

2028年底前该做的事

Mozilla没有让现有证书立刻失效，但留给双重用途老根的时间窗口已经明确。2028年底前完成职能拆分，根密钥满15年自动撤销网站TLS信任标记，这两条都会推动CA加快根证书升级。

业务侧现在可以做的检查不多，但都很具体。导出线上证书，确认当前根证书的生成时间、Extended Key Usage和CT日志状态。对移动端和嵌入式设备做一次新根链兼容性验证。把仍靠人工续期的证书迁到支持ACME自动化的签发平台，避免根链切换时出现大面积更新。

根证书策略收紧并不是一次性事件，它更像一个起点。后续CA在Firefox根商店里的生存门槛会越来越高，证书生命周期管理也注定从手工操作转向自动化。谁先把自己的证书链条理顺，谁在2028年那波老根退役里就越从容。