DigiCert G1 根证书 2026 年 4 月 15 日退役:Web PKI 最大规模信任迁移实战指南

PKI 体系 · 2026-06-17 · 6 阅读

前言

2026 年 4 月 15 日,Google Chrome 和 Mozilla Firefox 将正式从信任存储中移除三个 DigiCert 根证书:

  • DigiCert Global Root CA
  • DigiCert Assured ID Root CA
  • DigiCert High Assurance EV Root CA
这意味着:如果你的 TLS 证书仍然链向这些 G1 根,你的网站将在 Chrome 和 Firefox 中显示"不安全"警告——即使证书未过期、未吊销、一切正常。

这不是假设场景。根据 DigiCert 2023 年的数据,尽管大多数客户已在 2023 年 3 月迁移到 G2 层级,但仍有大量证书(尤其是长有效期证书、S/MIME 证书、代码签名证书、以及被遗忘的子域名证书)链向 G1 根。加上自定义信任存储、证书固定(Certificate Pinning)、IoT 设备、VPN 网关等长尾场景,受影响的范围远超预期。

更关键的是,G1 退役不是孤立事件。它是 2026-2027 年一系列 PKI 变革的第一波冲击波

日期事件影响面
2026-04-15Chrome/Mozilla 移除 G1 根信任所有链向 G1 的证书
2026-06-15Chrome 要求 CA 策略文件声明遵守 Chrome Root Program所有 CA 机构
2026-09-15Chrome 限制每个 CA 最多 2 个根证书大型 CA 机构
2027-02-10Sectigo 停止在公签证书中包含 clientAuth EKUmTLS 用户
2027-03-01DigiCert 停止在公签证书中包含 clientAuth EKUmTLS 用户
2027-03-15Chrome 要求所有下级 CA 支持自动化(ACME 或等效)所有 CA 机构
2027-03-15Chrome 不再信任包含 clientAuth EKU 的叶子证书公签 mTLS 用户
为什么现在就要关注? 因为 G1 退役是后续所有变革的"预演"。如果你的组织在 G1 迁移中手忙脚乱,后续的 clientAuth EKU 移除、自动化要求、根证书合并只会更加混乱。现在建立一套完整的证书资产清单和迁移流程,是应对整个 2026-2027 PKI 变革窗口期的最佳投资。

G1 退役的技术背景

什么是证书链和信任锚?

TLS 证书的信任建立在一个链式验证模型上:

CODE
叶子证书(你的网站证书)
    ↓ 签发
中间 CA 证书(Intermediate CA)
    ↓ 签发
根 CA 证书(Root CA)← 信任锚

浏览器内置了一个信任存储(Trust Store),包含所有被信任的根证书。当浏览器验证你的证书时,它会沿着证书链向上追溯,直到找到一个在信任存储中的根证书。如果找不到,验证失败,显示安全警告。

DigiCert 在 2023 年 3 月 8 日将默认签发层级从 G1 迁移到了 G2/G3。但"默认迁移"不等于"全部迁移":

  • 新签发的证书:默认使用 G2/G3 层级 ✅
  • 旧证书续期时:大多数情况下会自动迁移到 G2/G3 ✅
  • 长有效期证书:部分 2 年或 3 年证书在到期前不会续期,仍然链向 G1 ⚠️
  • 非 TLS 证书:S/MIME、代码签名等证书的迁移时间线不同 ⚠️
  • 自定义签发:通过 API 或特殊渠道签发的证书可能仍走 G1 ⚠️

哪些根证书会被移除?

根证书序列号受影响层级
DigiCert Global CA08:3B:E0:56:90:42:46:B1:A1:75:6A:C9:59:91:C7:4AG1 标准证书
DigiCert Assured ID Root CA0C:E7:E0:E5:17:D8:46:FE:8F:E5:60:FC:19:9D:B5:A8G1 中间 CA
DigiCert High Assurance EV Root CA03:9E:ED:B8:0B:E7:A0:3C:90:98:A3:50:E2:85:21:6D:35:A2G1 EV 证书
注意:DigiCert 的 G2 和 G3 根证书不受影响。如果你的证书已经链向 G2/G3,你不需要做任何事情。

受影响范围评估

谁需要关注?

以下场景中的组织极有可能受到影响:

  • 长有效期证书持有者:如果你在 2023 年之前购买了 2 年或 3 年的 TLS 证书,且尚未续期,它可能仍链向 G1。
  • S/MIME 和代码签名证书用户:这些证书类型的时间线与 TLS 不同。DigiCert 对非 TLS 产品的 G1 迁移时间表与 TLS 不完全一致。
  • 使用自定义信任存储的组织:如果你的应用程序、设备或系统手动维护了一个 CA 信任列表(而非使用操作系统或浏览器的默认信任存储),且其中包含 G1 根证书,你需要手动更新。
  • IoT 设备和嵌入式系统:这些设备通常不会自动更新信任存储,且可能硬编码了 G1 根证书。
  • 使用证书固定的应用程序:如果你的应用通过 Certificate Pinning 固定了某个 G1 链的证书或公钥,G1 退役后验证会失败。
  • B2B 集成和反向代理:合作伙伴之间的 mTLS 连接、API 网关的后端连接、反向代理的证书链验证——这些场景中任何一端链向 G1 都会导致连接失败。

实际影响有多大?

根据 crt.sh 和 Censys 的公开数据,截至 2026 年初:

  • 全球约有 3-5% 的公开 TLS 证书仍链向 G1 根(考虑到证书总量数亿张,这是一个绝对数量巨大的数字)
  • 在非 Web 场景(VPN、邮件网关、IoT)中,G1 链的比例可能更高,因为这些环境的证书更新周期更长
  • 企业内部的私有 PKI 如果交叉签发了 G1 根,也会受到影响

排查方法:你的证书是否受影响?

方法一:在线检测

使用 openssl s_client 检查你的证书链:

BASH
# 检查证书链中的根证书
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | \
  openssl x509 -noout -issuer -subject

# 查看完整证书链
echo | openssl s_client -servername example.com -connect example.com:443 -showcerts 2>/dev/null | \
  grep -E "^\s+[0-9]+ s:|^\s+[0-9]+ i:"

方法二:批量扫描脚本

以下 Python 脚本可以批量检测域名列表中的 G1 链证书:

方法三:使用在线工具

迁移实战:从 G1 到 G2/G3

步骤一:建立完整证书清单

在开始迁移之前,你需要知道你有多少证书、在哪里、由谁管理。这包括:

步骤二:分类处理

根据证书类型和来源,制定不同的迁移策略:

证书类型迁移方式紧急程度
DigiCert 标准 TLS 证书通过 DigiCert CertCentral 控制台重新签发🔴 高
DigiCert EV TLS 证书需要重新验证组织身份后签发🔴 高
DigiCert S/MIME 证书联系 DigiCert 确认迁移时间线🟡 中
DigiCert 代码签名证书需要重新验证后签发🟡 中
Let's Encrypt 证书不受影响(Let's Encrypt 不使用 G1)✅ 无需操作
内部 CA 签发的证书检查是否交叉签发了 G1 根🟡 中

步骤三:重新签发并部署

对于每个受影响的 DigiCert 证书:

  • 登录 DigiCert CertCentral 控制台
  • 找到受影响的证书,点击"重新签发"(Reissue)
  • 在大多数情况下,你不需要重新生成私钥(但建议评估是否需要轮换)
  • 下载新的 G2/G3 链证书
  • 部署到服务器,验证证书链

步骤四:验证迁移结果

BASH
# 验证新证书不再链向 G1
echo | openssl s_client -servername your-domain.com -connect your-domain.com:443 2>/dev/null | \
  openssl x509 -noout -subject -issuer

# 验证完整证书链
echo | openssl s_client -servername your-domain.com -connect your-domain.com:443 -showcerts 2>/dev/null | \
  awk '/BEGIN CERTIFICATE/,/END CERTIFICATE/{print}' | \
  while openssl x509 -noout -subject -issuer 2>/dev/null; do :; done

# 使用 SSL Labs 验证
# 访问: https://www.ssllabs.com/ssltest/analyze.html?d=your-domain.com

2026-2027 PKI 变革全景:不只是 G1 退役

G1 退役只是开始。以下是未来 12 个月内企业 PKI 团队需要应对的完整变革清单:

Chrome Root Program v1.8 核心要求

Google Chrome 在 2026 年 2 月 5 日发布了 Root Program Policy v1.8,引入多项重大变更:

1. 根证书数量限制(2027 年 9 月 15 日生效)

每个 CA 在 Chrome Root Store 中最多只能有 2 个自签名根证书。目前一些大型 CA(如 DigiCert、Sectigo)拥有 5-10 个根证书。这意味着 CA 必须进行根证书合并,企业可能需要更新信任存储配置。

2. 强制自动化支持(2027 年 3 月 15 日生效)

所有未过期、未吊销的下级 CA 证书必须集成自动化解决方案(ACME 或等效方案)。这意味着:每个 CA 签发的每一种证书类型都必须支持自动化签发和续期。CA 必须在 CCADB 中披露自动化方案,并通过"自动化测试证书"证明其能力。

3. 多用途根证书淘汰(2026 年 6 月 15 日开始)

Chrome 将逐步淘汰同时用于多种用途(TLS + 代码签名 + S/MIME 等)的根证书。所有根证书必须专用于 TLS 服务器认证

Client Authentication EKU 移除

从 2027 年 3 月起,Chrome 将不再信任包含 clientAuth 扩展密钥用途(EKU)的叶子证书。这意味着:

  • 公签 mTLS 将不再可行:你不能再用公共 CA 签发的证书做双向 TLS 认证
  • 影响场景:API 网关的 mTLS 认证、服务网格的 sidecar 认证、零信任架构中的设备认证
  • 替代方案
- 使用私有 PKI 签发客户端证书 - 迁移到基于 OAuth 2.0 / JWT 的认证机制 - 使用 DigiCert 的 X9 PKI 产品(专为非 TLS 用途设计)

对国密体系的影响

对于使用国密算法的企业,2026-2027 年的 PKI 变革带来特殊考虑:

  • Chrome Root Program 不直接约束国密 CA:国密 CA(如 CFCA、BJCA、沃通)不在 Chrome Root Store 中,Chrome 不直接信任国密证书。但 Firefox 和国产浏览器(如 360、QQ 浏览器)的信任策略可能受此影响。
  • 双证书方案需要同步迁移:如果企业的"国密 + 国际"双证书方案中,国际证书链向 G1,那么只需要更新国际证书到 G2/G3。国密证书不受影响。
  • 自动化要求对国密 CA 的压力:Chrome 的自动化要求虽然不直接约束国密 CA,但会推动整个行业向 ACME 自动化方向发展。国密 CA 可能需要加快 ACME 或等效自动化协议的部署。
  • clientAuth EKU 对国密 mTLS 的影响:如果企业使用国密证书做 mTLS,Chrome 的 clientAuth EKU 移除不直接影响国密证书(因为 Chrome 不信任国密证书),但国产浏览器可能跟进类似策略。

企业应对策略:建立 PKI 变更管理框架

面对 2026-2027 年的密集变革,企业需要建立一个PKI 变更管理框架,而不是一次次被动应对。

1. 建立证书资产清单(Certificate Inventory)

这是所有后续工作的基础。清单应包含:

2. 建立变更日历

将所有已知的 PKI 变革日期纳入变更管理日历:

  • 2026-04-15: DigiCert G1 根退役
  • 2026-06-15: Chrome 多用途根淘汰开始
  • 2026-09-15: Chrome 要求 CA 策略文件声明合规
  • 2027-02-10: Sectigo 移除 clientAuth EKU
  • 2027-03-01: DigiCert 移除 clientAuth EKU
  • 2027-03-15: Chrome 强制自动化要求
  • 2027-03-15: Chrome 移除 clientAuth EKU 信任
  • 2027-09-15: Chrome 限制每 CA 最多 2 个根
  • 2029-03-15: 证书有效期最终降至 47 天

3. 建立自动化基线

无论你是否使用 DigiCert,都应该在 2026 年底前实现:

  • ACME 或等效自动化:所有公网证书的签发和续期自动化
  • 证书过期监控:在过期前 30/14/7/3/1 天发送告警
  • CT 日志监控:监控你的域名是否出现在 CT 日志中,发现未授权的证书签发
  • 证书链验证:定期检查所有部署的证书链是否仍然有效

4. 建立供应商沟通机制

与你的 CA 供应商建立定期沟通:

  • 订阅 DigiCert、Sectigo、Let's Encrypt 等的安全公告
  • 确认你的证书是否需要迁移以及迁移时间线
  • 了解供应商的自动化支持能力

检查清单

  • [ ] 扫描所有公网证书,确认是否有链向 G1 根的
  • [ ] 扫描所有内网证书(包括 S/MIME、代码签名),确认 G1 依赖
  • [ ] 检查 IoT 设备、VPN 网关、邮件网关的信任存储配置
  • [ ] 检查应用程序中的证书固定(Certificate Pinning)配置
  • [ ] 检查 B2B 集成和 API 网关的证书链验证配置
  • [ ] 对受影响的证书执行重新签发和部署
  • [ ] 验证迁移后的证书链不再包含 G1 根
  • [ ] 更新证书资产清单,记录根证书层级信息
  • [ ] 将 2026-2027 年 PKI 变革日历纳入变更管理流程
  • [ ] 评估 clientAuth EKU 移除对 mTLS 架构的影响
  • [ ] 评估 Chrome 根证书数量限制对信任存储管理的影响
  • [ ] 与 CA 供应商确认自动化支持计划

总结

DigiCert G1 根证书的退役,是 Web PKI 从"购买一次管一年"向"持续自动化管理"转型的标志性事件。它不是一个孤立的证书更新,而是 2026-2027 年一系列 PKI 变革的开端。

对于企业 PKI 团队来说,现在最重要的是三件事:

  • 立即行动:排查并迁移所有 G1 链证书,避免 4 月 15 日后的服务中断
  • 建立清单:建立完整的证书资产清单,这是应对后续所有变革的基础
  • 拥抱自动化:无论是 47 天证书有效期、强制自动化要求、还是 clientAuth EKU 移除,最终的解决方案都是自动化证书管理
记住:在 Web PKI 变革的浪潮中,没有"观望"的选项。

参考来源