DigiCert G1 根证书 2026 年 4 月 15 日退役:Web PKI 最大规模信任迁移实战指南
前言
2026 年 4 月 15 日,Google Chrome 和 Mozilla Firefox 将正式从信任存储中移除三个 DigiCert 根证书:
- DigiCert Global Root CA
- DigiCert Assured ID Root CA
- DigiCert High Assurance EV Root CA
这不是假设场景。根据 DigiCert 2023 年的数据,尽管大多数客户已在 2023 年 3 月迁移到 G2 层级,但仍有大量证书(尤其是长有效期证书、S/MIME 证书、代码签名证书、以及被遗忘的子域名证书)链向 G1 根。加上自定义信任存储、证书固定(Certificate Pinning)、IoT 设备、VPN 网关等长尾场景,受影响的范围远超预期。
更关键的是,G1 退役不是孤立事件。它是 2026-2027 年一系列 PKI 变革的第一波冲击波:
| 日期 | 事件 | 影响面 |
|---|---|---|
| 2026-04-15 | Chrome/Mozilla 移除 G1 根信任 | 所有链向 G1 的证书 |
| 2026-06-15 | Chrome 要求 CA 策略文件声明遵守 Chrome Root Program | 所有 CA 机构 |
| 2026-09-15 | Chrome 限制每个 CA 最多 2 个根证书 | 大型 CA 机构 |
| 2027-02-10 | Sectigo 停止在公签证书中包含 clientAuth EKU | mTLS 用户 |
| 2027-03-01 | DigiCert 停止在公签证书中包含 clientAuth EKU | mTLS 用户 |
| 2027-03-15 | Chrome 要求所有下级 CA 支持自动化(ACME 或等效) | 所有 CA 机构 |
| 2027-03-15 | Chrome 不再信任包含 clientAuth EKU 的叶子证书 | 公签 mTLS 用户 |
为什么现在就要关注? 因为 G1 退役是后续所有变革的"预演"。如果你的组织在 G1 迁移中手忙脚乱,后续的 clientAuth EKU 移除、自动化要求、根证书合并只会更加混乱。现在建立一套完整的证书资产清单和迁移流程,是应对整个 2026-2027 PKI 变革窗口期的最佳投资。
G1 退役的技术背景
什么是证书链和信任锚?
TLS 证书的信任建立在一个链式验证模型上:
叶子证书(你的网站证书)
↓ 签发
中间 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 CA | 08:3B:E0:56:90:42:46:B1:A1:75:6A:C9:59:91:C7:4A | G1 标准证书 |
| DigiCert Assured ID Root CA | 0C:E7:E0:E5:17:D8:46:FE:8F:E5:60:FC:19:9D:B5:A8 | G1 中间 CA |
| DigiCert High Assurance EV Root CA | 03:9E:ED:B8:0B:E7:A0:3C:90:98:A3:50:E2:85:21:6D:35:A2 | G1 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 检查你的证书链:
# 检查证书链中的根证书
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 链证书:
#!/usr/bin/env python3
"""
G1 根证书影响检测器
检测域名列表中是否存在仍链向 DigiCert G1 根证书的 TLS 证书
"""
import ssl
import socket
import sys
from cryptography import x509
from cryptography.hazmat.backends import default_backend
# DigiCert G1 根证书的 SHA-1 指纹
G1_ROOT_FINGERPRINTS = {
"A8985D3A65E5E5C4B2D7D66D40C6DD2FB19C5436": "DigiCert Global Root CA",
"039EEDB80BE7A03C9098A350E285216D35A2": "DigiCert High Assurance EV Root CA",
"0CE7E0E517D846FE8FE560FC199D5B5A8": "DigiCert Assured ID Root CA",
}
def get_certificate_chain(hostname: str, port: int = 443) -> list:
"""获取目标主机的完整证书链"""
context = ssl.create_default_context()
context.check_hostname = False
context.verify_mode = ssl.CERT_NONE
try:
with socket.create_connection((hostname, port), timeout=10) as sock:
with context.wrap_socket(sock, server_hostname=hostname) as ssock:
# 获取对端证书链(PEM 格式)
chain = ssock.getpeercert(chain=True)
if chain:
return [x509.load_der_x509_cert(cert, default_backend())
for cert in chain]
# 备选方案:通过二进制数据获取
der_cert = ssock.getpeercert(binary_form=True)
if der_cert:
return [x509.load_der_x509_cert(der_cert, default_backend())]
except Exception as e:
return []
def check_g1_in_chain(chain: list) -> dict:
"""检查证书链中是否包含 G1 根证书"""
result = {
'has_g1': False,
'g1_root_name': None,
'chain_info': []
}
for cert in chain:
# 计算 SHA-1 指纹
fingerprint = cert.fingerprint(hashes.SHA1()).hex().upper()
# 格式化为 OpenSSL 风格(冒号分隔)
fp_formatted = ':'.join(fingerprint[i:i+2] for i in range(0, len(fingerprint), 2))
subject = cert.subject.get_attributes_for_oid(x509.oid.NameOID.COMMON_NAME)
subject_cn = subject[0].value if subject else str(cert.subject)
result['chain_info'].append({
'subject': subject_cn,
'fingerprint': fp_formatted,
'is_g1': fp_formatted in G1_ROOT_FINGERPRINTS
})
if fp_formatted in G1_ROOT_FINGERPRINTS:
result['has_g1'] = True
result['g1_root_name'] = G1_ROOT_FINGERPRINTS[fp_formatted]
return result
def main():
# 从命令行参数或文件读取域名列表
if len(sys.argv) > 1:
domains = sys.argv[1:]
else:
# 默认测试域名
domains = ['example.com', 'www.example.com']
affected = []
clean = []
errors = []
for domain in domains:
print(f"[*] 检查 {domain}...", end=' ', flush=True)
chain = get_certificate_chain(domain)
if not chain:
print("❌ 无法获取证书链")
errors.append(domain)
continue
result = check_g1_in_chain(chain)
if result['has_g1']:
print(f"⚠️ 发现 G1 根: {result['g1_root_name']}")
affected.append({
'domain': domain,
'g1_root': result['g1_root_name'],
'chain': result['chain_info']
})
else:
print("✅ 未受影响")
clean.append(domain)
# 输出汇总
print(f"\n{'='*60}")
print(f"检查完成: {len(domains)} 个域名")
print(f" 受影响 (G1 链): {len(affected)}")
print(f" 未受影响: {len(clean)}")
print(f" 检查失败: {len(errors)}")
if affected:
print(f"\n⚠️ 受影响的域名:")
for item in affected:
print(f" - {item['domain']} → {item['g1_root']}")
if errors:
print(f"\n❌ 检查失败的域名:")
for d in errors:
print(f" - {d}")
if __name__ == '__main__':
# 需要: pip install cryptography
from cryptography.hazmat.primitives import hashes
main()方法三:使用在线工具
- SSL Labs Server Test — 查看证书链详情
- crt.sh — 通过 CT 日志查询证书信息
- DigiCert 官方提供了 G1 到 G2 中间 CA 映射表
迁移实战:从 G1 到 G2/G3
步骤一:建立完整证书清单
在开始迁移之前,你需要知道你有多少证书、在哪里、由谁管理。这包括:
# 扫描本机所有证书文件
find /etc/ssl /etc/letsencrypt /etc/nginx -name "*.pem" -o -name "*.crt" 2>/dev/null | \
while read f; do
echo "=== $f ==="
openssl x509 -in "$f" -noout -subject -issuer -dates 2>/dev/null
echo ""
done
# 扫描所有监听 TLS 端口的本地服务
ss -tlnp | grep LISTEN | awk '{print $4}' | sed 's/.*://' | sort -u | \
while read port; do
echo "=== Port $port ==="
echo | openssl s_client -connect "localhost:$port" -showcerts 2>/dev/null | \
grep -E "^\s+[0-9]+ s:|^\s+[0-9]+ i:"
echo ""
done步骤二:分类处理
根据证书类型和来源,制定不同的迁移策略:
| 证书类型 | 迁移方式 | 紧急程度 |
|---|---|---|
| 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 链证书
- 部署到服务器,验证证书链
步骤四:验证迁移结果
# 验证新证书不再链向 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.com2026-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 认证、零信任架构中的设备认证
- 替代方案:
对国密体系的影响
对于使用国密算法的企业,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)
这是所有后续工作的基础。清单应包含:
{
"certificates": [
{
"domain": "www.example.com",
"issuer": "DigiCert",
"root_hierarchy": "G2",
"valid_from": "2025-01-01",
"valid_to": "2026-01-01",
"eku": ["serverAuth"],
"deployment": ["nginx-primary", "aws-elb"],
"auto_renewal": true,
"owner": "ops-team@example.com",
"last_verified": "2026-04-01"
}
]
}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 移除,最终的解决方案都是自动化证书管理
参考来源
- DigiCert G1 Root Removal 2026 - EncryptedFence
- Chrome Root Program Policy v1.8
- DigiCert 根战略调整 - DigiCert Knowledge Base
- Chrome 不再支持客户端认证 EKU - SSL.com
- Sectigo 停止客户端认证 EKU - Sectigo
- Let's Encrypt 停止 TLS 客户端认证 - Let's Encrypt
- Cisco: TLS clientAuth 证书变更指南 - Cisco
- Salesforce: PKI 即将发生的强制变更
- DigiCert G1 到 G2 中间 CA 映射表
- Chrome 博客:TLS 证书自动化的力量
- CA/Browser Forum 基线要求