谷歌新规：从 2027 年 3 月 15 日起，所有类型 SSL 证书都必须支持证书自动化

一、DV SSL 证书自动化已基本普及，但 OV/EV 证书自动化仍处边缘

Let's Encrypt 已占全球 SSL 证书市场的绝对主导地位(近 50%)，发行了超过 10 亿张有效 SSL 证书，每日签发量超千万张。在整个 SSL 证书生态中，DV SSL 证书占比超过 95%，这得 益于 ACME（自动化证书管理环境）协议的广泛应用，让域名验证和证书申请完全实现了无人 值守的自动化，这意味着国际市场已经基本普及了 DV SSL 证书自动化。

然而，这一繁荣背后隐藏着一个巨大的市场接受度的反差：CA 机构通过几十年的努力说服以后接受 OV 证书，但 OV/EV 证书的自动化签发却几乎没有进展，因为传统观点长期认为， OV 和 EV 证书需要人工完成组织身份验证，因此“不适合”自动化签发流程。

这一认知在国际上已开始被突破，国际头部 CA 已推出面向 OV 和 EV 证书的 ACME 自 动化方案，通过“一次人工身份审核、后续全自动化”的模式，用户只需完成一次单位身份的预 鉴证，后续的 OV/EV 证书申请、更新和吊销均可通过 ACME 协议自动完成。这表明，OV/EV 证书的自动化在技术上完全没有问题，真正的障碍在于 CA 是否愿意投入改造其证书签发系 统。

二、谷歌 V1.8 政策：不向 CCADB 证明自动化能力，就淘汰这个 CA

作为证书自动化的主要推动方—谷歌也认识到这个市场反差问题，于 2026 年 2 月 5 日发 布了谷歌浏览器根认证计划 V1.8 版本。其中最关键的一条要求是：从 2027 年 3 月 15 日起， 如果某个 PKI 层级签发的新证书中包含任何基线要求证书政策 OID（即 2.23.140.1.x 系列，涵 盖 DV、OV、IV 和 EV 全部四种证书类型），但该层级在 CCADB 中缺乏自动化解决方案的证 明披露，谷歌浏览器就将启动 CA 淘汰程序。

请注意：2027 年 3 月 15 日同时也是缩短 SSL 证 书有效期为 100 天的起始日期。

让我们逐句拆解这条规则的杀伤力。

第一，触发条件是什么？

任何 CA 下属的任意一个中级根 CA（即一个 PKI 层级），只要用这个中级根 CA 签发了任意一张包含“基线要求证书政策 OID”的新证书，即无论这张证书是 DV、OV 还是 EV，只要这张证书含有证书类型 OID 的签发行为就自动触发了 CA 向 CCADB 披露自动化能力证明的义务。换句话说，只要 CA 还在签发 TLS/SSL 证书，就必须为签发该证 书配备并证明其自动化能力。

第二，什么算“自动化解决方案的证明披露”？

CA 必须为每个类型的 SSL 证书的自动化 方案实际运行一个“测试网站”，该网站所呈现的 SSL 证书必须完全由该 CA 根通过自动化方案 签发，并且证书必须至少每 30 天自动更新一次。换言之，谷歌要求 CA 用连续不断运行、定 期自动更新的“活”证书来证明其自动化能力，而不是在 CCADB 里放一纸空文描述和承诺。

请注意：这个自动化更新能力是要求在明年 3 月 15 日之前具备每 30 天更新一次证书的自动化能 力，而不是国际标准要求的 2029 年 3 月 15 日起的 47 天有效期，证书可以是 100 天的，但必 须每 30 天自动更新一次。

第三，如何证明自动化方案“真实有效”？ 

CA 必须为每个披露的自动化方案实际运行一个 “测试网站”，该网站所呈现的 SSL 证书必须完全由该自动化方案签发，并且证书必须至少每 30 天自动更新一次。换言之，谷歌要求 CA 用连续不断运行、定期自动更新的“活”证书来证明 自动化能力，而不是在 CCADB 里放一纸空文描述和承诺。

请注意：这个自动化更新能力是要 求在明年 3 月 15 日之前具备每 30 天更新一次证书的自动化能力，而不是国际标准要求的 2029 年 3 月 15 日起的 47 天有效期。

第四，不披露或者披露后被发现造假，后果是什么？

政策原文写得非常清楚：一旦谷歌 检测到违规，例如发现某个中级根 CA 签发了新的证书，但其对应的 PKI 层级在 CCADB 中根 本没有自动化方案证明；或者即使有提交自动化证明，但是用于证明自动化能力的测试网站并 没有做到每 30 天更新一次证书，谷歌就会为该中级根 CA 设定一个淘汰日期（phase-out date）， 这个日期定在违规检测后的 90 天。

90 天之后，谷歌浏览器将不再信任这个中级根 CA 签发的 任何新证书，甚至在更新根证书库时直接将根 CA 移出信任列表。

第五，这条规则给了 CA 多长时间缓冲？

政策自 2026 年 2 月 5 日发布，但实际执行起始 日为 2027 年 3 月 15 日。也就是说，全球所有 CA 还有大约 13 个月的时间去改造自己的证书 签发系统、建立自动化的 DV/OV/EV 证书签发流程，并在 CCADB 中完成披露，但到今天就 只剩下 9 个月了。对于已经具备自动化能力的 CA，这只是一项合规披露工作；但对于那些至 今仍然完全依赖人工手动签发 DV/OV/EV 证书的 CA，这意味着必须在一年之内完成从“人工 模式”到“自动化模式”的彻底转型，否则其 SSL 证书业务将在 2027 年 3 月 15 日之后被谷歌浏 览器直接掐断。对于已经具备自动化基础的 CA，这只是一项合规披露工作；但对于那些至今 仍然完全依赖人工手动签发 DV/OV/EV 证书的 CA，这意味着必须在一年之内完成从“人工模式”到“自动化模式”的彻底转型，否则其 SSL 证书业务将在 2027 年之后被谷歌浏览器直接掐 断。

第六，政策背后的深层逻辑是什么？ 

很多人误以为谷歌只是“建议”CA 拥抱自动化，或者 认为 OV/EV 证书因为涉及身份验证可以豁免。但 V1.8 版本彻底打破了这一幻想：政策明确将 OV 和 EV 证书的 OID（2.23.140.1.2.2 和 2.23.140.1.1）列入了必须提供自动化证明的范围，没有任何例外。谷歌之所以如此强势推进，根源在于 CA/浏览器论坛的基线 BR 要求早已为自动化扫清了技术障碍。

首先，BR 的 3.2.2.4 节明确规定，CA 在验证企业身份时可以采用“可靠的 外部数据源”，例如政府数据库、征信机构等，并不必然依赖人工线下核查，这意味着 OV 和 EV 证书的身份验证环节完全可以被标准化、自动化地完成。其次，IETF 早在 2019 年就发布 了 RFC 8555（即 ACME 协议），BR 也早已将其采纳为行业标准，为证书的自动化申请、域名 验证和吊销提供了完整的技术框架。

谷歌此次强制要求 CA 在 CCADB 中披露其自动化方案， 本质上就是将 BR 已经允许的“自动化验证”和已经采纳的“ACME 标准”从“可选项”升级为“必 选项”。因此，谷歌强制要求所有类型 SSL 证书全部支持自动化，既是对 BR 既有精神的落地， 也是为证书有效期不断缩短政策的落地铺路，也是回应了用户对 OV 证书的自动化需求。

 总而言之，谷歌 V1.8 政策不是一份建议书，而是一张带有明确时间表和执行机制的“最后 通牒”。它向全球 CA 发出了一个清晰无误的信号：要么让你的 OV/EV 证书也能像 DV SSL 证 书一样全自动签发，要么你就放弃签发 OV/EV SSL 证书，或者放弃谷歌浏览器信任。

谷歌新规给我们带来的最重要启示是：所有类型 SSL 证书的自动化签发不是“可选项”，而 是浏览器信任的“必选项”。证书有效期缩短是大势所趋，唯有自动化才是未来。

如果您的证书还没有部署自动化功能请联系我们，咨询海域云caas服务产品。