eMudhra CA 密钥泄露：企业现在应检查和修复什么

2026 年 10 月 17 日（星期六），一名安全研究人员报告：印度证书颁发机构 eMudhra 运营的八个中间 CA，其私钥任何人都能从公开的证书中推算出来。这些密钥每一个都是小于 256 的数字，其中一个就是数字 4。八个中间 CA 里有六个可以签发受 Apple、Google、Microsoft 和 Mozilla 信任的 TLS 证书，另外两个可以为 Windows 软件签名。

报告发出一小时四十分钟后，Chrome 拦截了这六个 TLS 密钥，Firefox 当晚也完成了拦截。对浏览网页的人来说，危险在周六晚上就已解除。

其他一切却并非如此。服务器、容器、Java 应用、Python 脚本、支付集成和联网设备，都用自己的那份受信任证书颁发机构列表来校验证书，而这些副本大多只有在有人安装更新时才会变化。在此之前，用这些密钥中任何一个签名的证书，不管是哪个域名的，都会被当作真证书放行，而这些密钥自 10 月 20 日起就已公开。

同一周，GoDaddy 开始吊销 404,607 张证书，原因是证书中的策略信息与它自己公布的文件不符。它的客户必须自己下载并安装替换证书。

本指南写给需要回答“我们受影响吗？”的人：IT 和运维负责人、CTO，以及业务依赖网站、API 或联网产品的创始人。内容包括：根据 Mozilla、Google、eMudhra、GoDaddy 和各软件厂商公布的事件记录整理的事件经过；今天要检查什么；本周要更新什么；以及要建立哪些机制，让下一次同类事件成为例行工作。本文所有内容截至 2026 年 10 月 22 日，事件仍未结束。

事件经过

eMudhra 于 2025 年 4 月 30 日在一次密钥仪式上创建了这八个中间 CA。它于 10 月 19 日在 Mozilla 的事件工单中发布的说明是：一次密钥封装与解封步骤的测试（作为对其常规流程的偏离事先获批）存在缺陷，在硬件安全模块中、在预期密钥旁边又生成了第二组弱密钥。两组密钥的标签相似，生成证书请求时误用了弱密钥，而 eMudhra 的根证书为这些请求签了名。同样的请求也发给了 Sectigo，Sectigo 于 2025 年 5 月 14 日用其 AAA Certificate Services 根证书为全部八个中间 CA 做了交叉签名。eMudhra 表示，它“尚未确认确切的根本原因”。

Mozilla 这样描述结果：“P384 私钥是在 1 与群的阶之间随机选取的整数。受影响的 8 个密钥使用的整数全都小于 256。”Mozilla 于 UTC 时间 20:06 收到报告，并在 21:48 自行恢复出了这些密钥，而且是“在对原报告者所用方法一无所知的情况下”。这名研究人员说，他是用 Google 的开源库 paranoid_crypto 找到这些密钥的，“开箱即用”。这些弱密钥在公开受信任的证书链中存在了近 18 个月。

这八张证书：

每个密钥都对应两张证书。一张由 eMudhra 的 emSign Root TLS CA - G3 或 emSign Root CS CA - G3 签发，二者向上链接到 emSign ECC Root CA - G3；另一张是 Sectigo 由 AAA Certificate Services 签发的交叉证书。第二条路径很关键，因为有些从未包含 eMudhra 根证书的信任库，仍然信任这个 Sectigo 的老根证书。

有人遭到攻击吗？

目前没有人报告滥用，而就浏览器而言，有充分的理由认为并未发生。Chrome 和其他强制执行 Certificate Transparency（证书透明度，CT）的客户端一样，只接受已记录在公开 CT 日志中的证书。Google 的说法是：在它实施拦截之前，没有任何链接到这六个中间 CA 的 TLS 证书被记录在日志中，因此“这些 CA 签发的任何伪造证书都不可能被用来攻击强制执行 CT 的客户端”。

浏览器之外，情况就不同了。Mozilla 的事件页面写道：“浏览器生态之外的许多客户端并不强制执行 Certificate Transparency。我们不知道攻击者是否利用了这一有缺陷的密钥生成来针对这些客户端。”这个窗口从 2025 年春天就已打开，对每个客户端而言，只有在它更新之后才会关闭。eMudhra 表示，它不知道有任何证据表明这些密钥在披露之前就已被恢复出来；Cloudflare 则表示，其审查未发现自身服务上存在主动利用。

既然密钥已经公开，伪造证书就毫无技术门槛了。Mozilla 的事件页面列出了一些测试服务器，它们出示用已泄露密钥签发的证书，任何人都可以用来检查自己的客户端（命令见下文）。

伪造证书能让攻击者做什么：能够拦截你的软件与其调用的某个服务之间流量的人（在共享网络上，或者通过被攻陷的路由器、被投毒的 DNS 应答），可以冒充该服务，读取你的软件发送的内容（包括 API 密钥和个人数据），并篡改它收到的内容。在 Microsoft 的拦截送达某台机器之前，用这两个代码签名密钥之一签名的软件在该机器上都能通过 Windows 的签名检查。

哪些人受影响

这里有三个相互独立的问题，一家公司可能三个都有。

1. 仍然信任已泄露密钥的软件

几乎每家公司都有这个问题：任何发起 HTTPS 调用的程序，只要其信任库中仍包含 emSign ECC Root CA - G3 或 AAA Certificate Services，且尚未收到针对这八个密钥的拦截，就在此列。常见的位置：

• 10 月 20 日或 21 日之前构建的 Linux 服务器和容器镜像。例如，未打补丁的 Debian 12 同时信任两条链。
• 自带列表的语言运行时：Node.js、Python 的 certifi、Java 的 cacerts、PHP 的 Composer 证书包、Rust 的 webpki-roots。
• macOS 命令行工具。Mozilla 的事件页面称，系统自带的 curl、git、python3、perl、ruby 和 openssl 依据 /etc/ssl/cert.pem 校验证书，且不检查吊销状态，而 Apple 尚未更新该文件。
• 没有接收 Microsoft 对其不允许证书列表自动更新的 Windows 机器，通常是因为组策略关闭了这项更新，或者网络处于离线状态。
• 自带 CA 文件的专用设备、联网设备和第三方软件，例如负载均衡器、VPN 网关、SDK 和嵌入式控制器。

每个运行时都要单独检查。在我们 10 月 22 日做的一次测试中，一台未打补丁、装有 Node.js 24.18 的 Debian 12 机器接受了终止于 eMudhra 根证书的那条链，拒绝了终止于 Sectigo 根证书的那条，而同一台机器上的 Python 两条都接受。

2. 自身证书链接到被移除根证书的公司

Mozilla 和各 Linux 发行版已移除 emSign ECC Root CA - G3，Chrome 将于 10 月 27 日跟进。该根证书下的有效证书，会在每个客户端完成更新后在该客户端中失效。Google 的要求是：持有此类证书的网站运营者“必须立即从 Chrome Root Store 所收录的另一个 PKI 体系获取并安装新的 TLS 证书”。

10 月 21 日，Chrome 在 CT 中统计到该根证书下约有 30,800 张未过期的证书。其中 30,791 张来自 InCommon 的两个中间 CA。InCommon 是 Internet2 为美国大学和科研机构运营的证书服务，通过 eMudhra 的平台 CERTInext 签发 ECC 证书。另有 18 张来自 eMudhra 自己的中间 CA。eMudhra 表示，约有 30,000 张证书需要迁移，其中约 97% 是通过 ACME 签发的，它正在从另一个体系签发替换证书。

如果你的网站以 Full (strict) 模式部署在 Cloudflare 之后，而源站出示的是该根证书下的证书，Cloudflare 表示，这次取消信任“会导致故障”，并要求客户“检查你们的自定义源站证书和服务器配置”。

eMudhra 另一个根证书 emSign Root CA - G1 下的 RSA 证书，到目前为止未受影响。Mozilla 表示“目前”不会移除该根证书；Chrome 则“正在密切调查 eMudhra 其余 CA 证书是否应继续收录”。如果你依赖任何类型的 eMudhra 或 CERTInext 证书，现在就准备好第二家证书颁发机构。

3. GoDaddy 客户

GoDaddy 的情况与 eMudhra 无关，但它发生在同一周，波及的网站要多得多。10 月 15 日，GoDaddy 向 Mozilla 报告，其 GoDaddy 和 Starfield 体系签发的证书所携带的证书策略信息（策略 OID 和 CPS 链接）与其自身 CP/CPS 中的证书模板不符。CP/CPS 是证书颁发机构说明自己签发哪些证书的文件。这并不是证书的安全缺陷。但根据 Baseline Requirements（基线要求，即每家公共证书颁发机构都要遵守的规则），这仍然是必须在五天内吊销证书的理由。

受影响的证书共 404,607 张，其中 396,055 张为域名验证（DV）证书。到 10 月 18 日 UTC 时间 23:45 的截止时间，GoDaddy 吊销了 170,566 张，到次日上午共吊销 227,422 张；其客户通知称，其余证书已于 10 月 21 日吊销。GoDaddy 会重新签发证书，但安装要由客户自己完成：“你网站的访客可能会看到安全警告，在安装新证书之前，你的网站可能无法访问。”

今天要检查什么

1. 你自己的服务器发出的是什么证书？对每个公开主机名，列出它所出示证书链中的签发者：

h=www.example.com
openssl s_client -connect "$h:443" -servername "$h" -showcerts </dev/null 2>/dev/null | grep -E '^ +i:'

如果某一行出现 eMudhra、emSign、某个 EM ... G3B 或 G3C 证书颁发机构，或者 InCommon Intermediate CA - DVG3C、OVG3C 或 EVG3C，就说明该证书必须在 10 月 27 日之前更换。单独出现 AAA Certificate Services 是正常的，因为许多普通的 Sectigo 证书链仍然包含它。对于邮件和目录服务，加上 -starttls smtp（或 imap、ldap）和相应的端口。内部主机、负载均衡器和 CDN 后面的源站也要检查。

2. 有哪些证书是为你的域名签发的？CT 列出了公共证书颁发机构为你的域名签发的每一张证书，包括公司里没人记得申请过的证书：

curl -s 'https://crt.sh/?q=%25.example.com&output=json&exclude=expired' | jq -r '.[].issuer_name' | sort | uniq -c

输出还会显示你的公司实际在用哪些证书颁发机构，这正是下文所述清单的起点。

3. 你的客户端信任已泄露的密钥吗？Mozilla 的测试服务器出示的是用已泄露密钥签发的证书，所以出现证书错误才是好结果。两类都要测试：第一个主机链接到 eMudhra 的根证书，第二个链接到 Sectigo 的根证书，同一个信任库可能拦下其中一个，却放行另一个。

curl -sS -o /dev/null https://dv-g3b-emudhra.we-have-a-problem.com/ && echo "TRUSTED: update this system"
curl -sS -o /dev/null https://dv-g3b-aaa-emudhra.we-have-a-problem.com/ && echo "TRUSTED: update this system"

curl 只能代表 curl 自己。请在应用实际运行的环境中，通过每个应用自己的 TLS 栈发出同样的请求：

node -e "require('https').get('https://dv-g3b-emudhra.we-have-a-problem.com/', () => console.log('TRUSTED')).on('error', e => console.log('rejected:', e.code))"
python3 -c "import urllib.request; urllib.request.urlopen('https://dv-g3b-emudhra.we-have-a-problem.com/'); print('TRUSTED')"
python3 -c "import requests; requests.get('https://dv-g3b-emudhra.we-have-a-problem.com/'); print('TRUSTED')"

这两行 Python 并不重复：urllib 使用操作系统的信任库，requests 使用 certifi。每一行都要再用 dv-g3b-aaa-emudhra 主机运行一遍。对于 Java，从相关的 JVM 向测试服务器发起任意一次 HTTPS 调用，并列出其信任库中是否包含这两个根证书之一（Java 9 及以上版本；Java 8 请使用 -keystore $JAVA_HOME/jre/lib/security/cacerts）：

keytool -list -v -cacerts -storepass changeit | grep -E 'Owner: .*(emSign ECC Root CA - G3|AAA Certificate Services)'

信任库中有某个根证书，单凭这一点并不能证明存在暴露，因为 Go、Node.js、Deno 和 Rust 的 rustls-webpki 现在无论信任库里有什么，都会拦截这八个密钥。测试服务器才能给出定论。

4. 企业内的 Windows 机器。Microsoft 没有就此事件发布任何内容，但 Windows 自动下载的不允许证书列表自 10 月 20 日起已拦截全部八个密钥。例外是组策略关闭了根证书自动更新的机器，以及无法连到 Windows Update 的网络；它们需要通过其他方式获得该列表。certutil -verifyCTL Disallowed 可以显示某台机器缓存的副本。Mozilla 的事件页面为单台机器提供了一个脚本，并说明它“不建议用于企业托管的设备”。

5. GoDaddy 证书。检查每台服务器实际出示的是哪张证书：

echo | openssl s_client -connect www.example.com:443 -servername www.example.com 2>/dev/null | openssl x509 -noout -issuer -serial -startdate

如果签发者是 GoDaddy 或 Starfield，就把序列号与你 GoDaddy 账户中的证书进行比对。凡是 GoDaddy 显示“Install your new certificate”（安装新证书）的地方，服务器上用的仍是已被吊销的那张。

始终遵守一条规则：不要靠关闭证书校验来让错误消失。用 Cloudflare 的话说：“重要的是，不要通过禁用校验来解决这些错误。”不校验证书的客户端会信任所有伪造证书，而不只是这些。

本周要更新什么

修复有两种。移除这两个根证书，能为使用该信任库的客户端堵住所有路径，但也会让它们之下的有效证书失效。像 Go、Node.js、Deno、Electron、rustls-webpki、Composer 和 Windows 那样，按公钥哈希拦截这八个密钥，既能堵住漏洞，又不会破坏其他任何东西。如果你的平台提供第二种方式，优先采用它。

“尚无”表示截至 10 月 22 日还没有发布任何内容。在据此做计划之前，请再核实一次。

有四件事常让团队措手不及：

• 容器镜像保留旧列表。10 月 20 日或 21 日之前构建的镜像会一直信任这些密钥，直到基于更新后的基础镜像重新构建为止；而重新拉取同一个标签，只有在基础镜像已经重建之后才有用。重新构建、重新部署，并询问你所运行镜像的供应商。
• 进程保留已加载的内容。程序在启动时读取信任库，所以更新之后要重启长期运行的服务。Node.js 还补充说，从升级前恢复的 TLS 会话不会被重新校验。
• 应用自带 CA 文件。SDK 和应用常常自带 cacert.pem 或 ca-bundle.crt。在代码仓库和镜像中搜索这些文件，例如使用 find / -xdev \( -name 'cacert*.pem' -o -name 'ca-bundle*.crt' \) 2>/dev/null，并且要预料到不止一份：比如 pip 就自带一份 certifi。
• 设备要等厂商。书面询问每家厂商，产品使用哪个信任库、更新何时发布。在更新发布之前，该设备会信任它所调用的每个服务的伪造证书，因此要限制它能访问的范围。

如果你像 Debian、Ubuntu ESM、Fedora 和 Red Hat 的规避方法那样手动移除 AAA Certificate Services，之后要测试与使用 Sectigo 证书的服务之间的连接：一些较老的服务器发送的证书链仍以该根证书结尾。

下一次之前要建立什么

证书颁发机构留下如此脆弱的密钥实属罕见。大规模吊销却不罕见。以下是 Mozilla 的 bug 跟踪系统中记录的 2026 年几次大规模吊销：

这五起中没有一起是安全故障。每一起都是证书与证书颁发机构自己的文件不一致，而 Baseline Requirements（第 4.9.1.1 节）仍然要求在五天内吊销。如果密钥泄露，或者域名验证不再可靠，期限是 24 小时。没有人能替你延期。在 DigiCert 2024 年吊销 83,267 张证书的事件中，Chrome Root Program 写道，它“无权批准例外”；一家客户取得了阻止吊销其证书的法院命令，但该命令四天后被撤销。

替换进行得如何，很能说明问题。7 月，HARICA 利用 ACME Renewal Information（ARI，ACME 续期信息）通知客户的 ACME 客户端提前续期，并自行重新签发了其他证书；在它两次吊销中规模较大的那一次，截止时间到来时，87% 的受影响名称已被替换。GoDaddy 的客户需要自己下载并安装每一张替换证书，到截止时间，GoDaddy 吊销了 42% 的受影响证书。

无论如何，续期周期都在缩短：

• 根据 CA/Browser Forum 的 SC-081 投票决议，公共 TLS 证书的有效期自 2026 年 3 月 15 日起上限为 200 天。该上限将于 2027 年 3 月 15 日降至 100 天，于 2029 年 3 月 15 日降至 47 天，届时域名验证结果只能复用 10 天。
• Let's Encrypt 将于 2027 年 2 月 10 日把默认证书有效期改为 64 天，一年后再改为 45 天。
• 公共 TLS 证书正在失去客户端认证用途。Let's Encrypt 已于 2026 年 7 月 8 日停止签发带此用途的证书，而 Chrome Root Program 要求自 2027 年 3 月 15 日起签发的证书只能用于服务器认证。如果你把公共证书用作双向 TLS（mutual TLS）的客户端证书（这在 B2B API 集成中很常见），这些连接就需要一个私有证书颁发机构。

到了 100 天，再到 47 天，手动安装证书就不再是现实的选择。一家按这个节奏实现自动化的公司，也就为下一次大规模吊销做好了准备。这需要做到：

1. 两个方向都要清楚自己有什么。一份清单列出你对外提供的每一张证书，包括主机名、签发者、到期时间、续期方式和负责人。第二份清单列出你的软件所依赖的每一个信任库：操作系统软件包、每个语言的证书包、应用或设备内的每个 CA 文件。上文的 CT 查询是第一份清单的起点；软件物料清单（SBOM）或依赖清单是第二份清单的起点。
2. 自动化签发和安装。凡是能运行 ACME 的地方都使用 ACME，并配合 ARI（RFC 9773），让证书颁发机构可以通知你的客户端提前续期。设备无法运行 ACME 的，使用厂商的自动化工具，或者在它前面放一个能运行 ACME 的组件来终结 TLS。
3. 准备好第二家证书颁发机构。在第二家证书颁发机构开好一个可用且经过测试的 ACME 账户，并在 DNS 中设置同时允许两家的 CAA 记录。当一家证书颁发机构被取消信任或大规模吊销时，切换就只是一次配置变更。
4. 监控你域名的 CT 记录。为你的域名每签发一张新证书，都收到一条告警。出现意外签发的当天，你就会知道。
5. 把信任库当作依赖来管理。通过常规补丁流程更新信任库，并按计划重新构建镜像，而不是只在代码变更时才构建。
6. 围绕两个倒计时编写处置手册（runbook）。24 小时和五天：由谁决策，谁有每个系统的访问权限，哪些系统需要手动操作，如何联系每家厂商。每年演练一次，在一个经得起失误的服务上更换证书。自 2025 年起，公共证书颁发机构必须保有并测试自己的大规模吊销计划；它们的客户需要准备另一半。

如果你开发的产品由他人运行

如果你的产品内含信任库（设备、安装型应用、SDK），你的客户只有在你的更新送达之后才受到保护。发布更新，并告诉客户哪些版本已修复。Mozilla 对信任库运营者的建议是：如果软件能做到，就拦截这八个中间 CA，否则“考虑移除对签发这些中间 CA 的根证书的信任是否合适”。

网络韧性法案在这里有两方面的关联。它的通报义务自 2026 年 9 月 11 日起生效，涵盖被主动利用的漏洞，而本案没有利用的报告。它的基本要求自 2027 年 12 月 11 日起适用，其中包括漏洞能够通过安全更新得到处理；信任列表无法更新的产品将不符合这些要求。受 NIS2 约束的客户会问供应商处理这件事有多快，事先把答案写下来会有帮助。

仍未解决的问题

• eMudhra 剩下的根证书。Chrome 于 10 月 21 日向 eMudhra 提出了十二个问题，尚未就 emSign Root CA - G1 宣布任何决定。Mozilla 表示“目前”不会移除它。
• eMudhra 的迁移路径。它告诉 Mozilla，会把客户迁移到其 G1（RSA）体系；它的状态页面则提到“另一个独立运营、公开受信任的 CA 体系”。Chrome 已询问究竟是哪一个。
• Microsoft 和 Apple。两家都没有发布声明，也没有从各自的信任库中移除这两个根证书中的任何一个。
• 待发布的修复。截至 10 月 22 日，Red Hat、Amazon Linux、Temurin 和 Corretto 都还没有发布任何修复；Bun 的修复已合并，但尚未发布。
• 根本原因。eMudhra 尚未确认，并表示将重新核查其做过的每一次密钥仪式。
• Sectigo。在另一起自 9 月 5 日起悬而未决的案例中，Sectigo 拒绝吊销扩展密钥用法与其 CPS 中某句话不符的证书，理由是那句话有歧义。10 月 18 日，它统计仍有约 7,200 万张此类证书处于有效状态。公开讨论中有些参与者呼吁取消对它的信任；目前没有任何根证书计划宣布决定。持有 Sectigo 证书的公司应关注此案。

从哪里获得帮助

证书问题很少以证书问题的面目出现。它表现为结账页面打不开、集成停止同步、设备不再上报数据，而且通常发生在周末。我们帮助企业平稳度过像这样的一周，不出现停机，并把一切安排好，让下一次成为例行工作：

• 暴露面检查。我们找出你的系统在哪里发起或接受 TLS 连接、各自使用哪个信任库、你对外提供哪些证书，范围包括容器、Java 服务、与银行、支付和物流服务商的集成，以及设备。
• 修复。更新、重建镜像、拦截密钥或更换证书，全部按你的变更流程执行，并用 Mozilla 的测试服务器确认结果。
• 面向 2027 年的自动化。在服务器、负载均衡器和专用设备上部署带 ARI 的 ACME，配置第二家证书颁发机构、CAA 记录、CT 监控和处置手册，为 2027 年 3 月 15 日起的 100 天证书做好准备。
• 没人愿意碰的系统。老旧的 Java 应用、专用设备以及自带信任库的嵌入式客户端，正是我们的遗留系统与代码维护服务要解决的问题。

如果你不确定自己是否受影响，请把你运行的域名和平台写信发到 office@c9group.dev，或者预约通话。我们会告诉你首先该检查什么。