2026年10月20日，易穆德拉（eMudhra）的八张中间CA证书私钥已泄露。这些证书链接到受谋智（Mozilla）、微软（Microsoft）、苹果（Apple）和谷歌浏览器（Chrome）根证书计划以及多家下游信任库信任的根证书。为证明密钥泄露，报告者韦恩（Wayne）在10月17日使用八张中间CA各自的私钥签署消息，并提交给根证书计划团队。
正文
2026年10月20日
eMudhra 的八个中间 CA 证书的私钥已泄露。它们链接到受 Mozilla、Microsoft、Apple 和 Chrome 根证书计划以及许多下游信任库信任的根证书。
我们如何得知？
为证明密钥确已泄露，最初的报告者 Wayne 在 10 月 17 日使用这八个中间 CA 各自的私钥签署了下面这条消息，并报告给根证书计划团队：
We have a problem here - Wayne
proof.zip 包含该消息，以及每个中间证书对应的证书、公钥和对该消息的签名。使用 OpenSSL 验证的命令是：openssl x509 -in EM-DV-TLS-CA-G3B.crt.pem -noout -pubkey | diff - EM-DV-TLS-CA-G3B.pub.pem 和 openssl dgst -sha384 -verify EM-DV-TLS-CA-G3B.pub.pem -signature EM-DV-TLS-CA-G3B.sig message.txt。
已采取了哪些措施？
根证书计划和许多下游信任库已采取行动保护用户。这些证书自 10 月 17 日起在 Firefox 和 Chrome 中被阻止，自 10 月 19 日起在 Apple 设备中被阻止，自 10 月 20 日起在 Microsoft 中被阻止。
该问题已于 10 月 19 日负责任地披露给下游信任库。许多信任库已发布更新，或正在发布更新。
后果是什么？
拥有任一受影响中间 CA 私钥的攻击者可以冒充任何网站或服务。
Mozilla、Microsoft、Apple 和 Chrome 已通过分发吊销信息的工具（如 OneCRL、CRLite 和 CRLSets）为其用户修复了此问题。
该 CA 也已吊销受影响的中间证书。但是，许多其他客户端不会获取吊销信息，需要通过软件更新来确保其不再信任受影响的中间证书。
你的客户端是否仍信任受影响的中间证书？
| 中间 CA | 链接到 | 结果 | | --- | --- | --- |
要检查 curl 或其他命令行客户端，可运行：curl https://dv-g3b-emudhra.we-have-a-problem.com/ 和 curl https://dv-g3b-aaa-emudhra.we-have-a-problem.com/。出现证书错误表示客户端不信任受影响的中间证书。
用户可采取哪些措施？
用户应尽快将浏览器和操作系统更新到最新版本。
开发者软件和包怎么办？
| 软件 | 已修复版本 | | --- | --- | | Go | 1.27.3, 1.26.10 | | Electron | 44.9.1, 43.8.1, 42.11.16 | | Python certifi | 2026.10.19 | | Rust rustls-webpki | 0.103.16 | | Rust webpki-roots / webpki-root-certs | 1.0.10 | | Homebrew ca-certificates | 2026-09-25_1 | | Node.js | 待定 | | Composer ca-bundle | 待定 | | NSS | 3.131.1 | | uv | 0.13.4 |
可在 github.com/galadran/we-have-a-problem.com 补充更多。
macOS 的 curl 有临时解决办法吗？
macOS 会阻止受影响的中间证书，但内置的 /usr/bin/curl 会依据 /etc/ssl/cert.pem 验证证书且不检查吊销状态，而该文件尚未更新。要从中移除受影响的根证书，先备份：sudo cp /etc/ssl/cert.pem /etc/ssl/cert.pem.bak，然后运行：awk '/^(###|===) /{skip=0} /^=== .*\/CN=(AAA Certificate Services|emSign ECC Root CA - G3)$/{skip=1} !skip' /etc/ssl/cert.pem.bak | sudo tee /etc/ssl/cert.pem > /dev/null。
Linux 有临时解决办法吗？
在发行版发布更新的 ca-certificates 软件包之前，专家用户可以在系统信任库中不信任受影响的根证书。不建议普通用户这样做。
在 Debian 和 Ubuntu 上，以 root 身份运行：sed -i -e 's|^mozilla/emSign_ECC_Root_CA_-_G3.crt|!&|' -e 's|^mozilla/Comodo_AAA_Services_root.crt|!&|' /etc/ca-certificates.conf && update-ca-certificates。
在 Alpine 上，以 root 身份运行：apk add ca-certificates && sed -i -e 's|^mozilla/emSign_ECC_Root_CA_-_G3.crt|!&|' /etc/ca-certificates.conf && update-ca-certificates。
在 Fedora、RHEL、CentOS Stream、Rocky Linux、AlmaLinux 和 Amazon Linux 2023 上，以 root 身份运行：先执行 d=/etc/pki/ca-trust/source/blocklist; [ -d $d ] || d=/etc/pki/ca-trust/source/blacklist，随后运行 trust extract --overwrite --format=pem-bundle --filter='pkcs11:object=Comodo%20AAA%20Services%20root;type=cert' $d/Comodo_AAA_Services_root.pem，再运行 trust extract --overwrite --format=pem-bundle --filter='pkcs11:object=emSign%20ECC%20Root%20CA%20-%20G3;type=cert' $d/emSign_ECC_Root_CA_-_G3.pem，最后执行 update-ca-trust。
在 openSUSE 和 SLES 上，以 root 身份运行：先执行 d=/etc/pki/trust/blocklist; [ -d $d ] || d=/etc/pki/trust/blacklist，再运行 trust extract --format=pem-bundle --filter='pkcs11:object=Comodo%20AAA%20Services%20root;type=cert' $d/Comodo_AAA_Services_root.pem，然后运行 trust extract --format=pem-bundle --filter='pkcs11:object=emSign%20ECC%20Root%20CA%20-%20G3;type=cert' $d/emSign_ECC_Root_CA_-_G3.pem，最后执行 update-ca-certificates。
在 Arch Linux 上，以 root 身份运行：trust extract --format=pem-bundle --filter='pkcs11:object=emSign%20ECC%20Root%20CA%20-%20G3;type=cert' /etc/ca-certificates/trust-source/blocklist/emSign_ECC_Root_CA_-_G3.pem，然后执行 update-ca-trust。
在 NixOS 上，在配置中加入：security.pki.caCertificateBlacklist = [ "Comodo AAA Services root" "emSign ECC Root CA - G3" ];。
NetBSD 有临时解决办法吗？
在 NetBSD 10 及更高版本上，以 root 身份运行：certctl untrust /usr/share/certs/mozilla/all/emSign_ECC_Root_CA_-_G3.pem，然后运行：certctl untrust /usr/share/certs/mozilla/all/Comodo_AAA_Services_root.pem。
信任库运营者可以采取哪些措施？
请参阅 Mozilla 开发者安全政策论坛中的这个讨论帖。
哪些中间证书受到影响？
impacted-intermediates.json 列出了这八个中间证书及其 Sectigo 交叉签名。roots.json 列出了它们所链接到的根证书。
评论
讨论整体充满对 Web PKI 与证书颁发体系的愤怒和荒诞感，主线分歧在于：这究竟是私钥被放到公开仓库之类的传统泄露，还是因私钥弱到仅相当于单字节「4」而暴露的系统性失效；多数人认为主流浏览器能靠吊销机制自动缓解，但大量非浏览器客户端、存量软件、物联网设备以及依赖印度政府服务的场景才是真正重灾区，也有人继续追问 CA（eMudhra）本身要承担什么后果。
认为所谓“泄露”实为私钥弱到荒唐的系统性失效
- 有评论称私钥似乎出现在 repository.emsign.com 的某个证书路径下，像是传统泄露；但更关键的分析指出，8 个被攻破 CA 的私钥都只有单个字节，其中一张证书的完整私钥就是 D=4、字面值「4」，几乎可以凭空推算出来。因此所谓“泄露”名不副实，本质是密钥生成彻底失败。（认可度：较多人） > 其中一个私钥的字面值就是「4」，我只能给「泄露」加上引号，否则说到这个词都想骂人。（@eqvinox）
认为 Web PKI 已病入膏肓，应换成按子树或分片限制的层级化信任体系
- 现有体系下一个中间 CA 的私钥就能冒充任何网站；为了吊销一张证书，竟要给 Go、Electron、webpki-roots 等发新版本，甚至可能走过一条已被攻破的 TLS 连接；大量软件包各自分发高敏的信任根，而且任何 CA 都能为任意域名背书。评论认为应改用 DNS 那种按层级委派、危害只限于被攻破实体子树的机制做域名验证，或按 ccTLD 等分片限制 CA 权力，并把信任分散，而不是集中在浏览器厂商和 Let's Encrypt。（认可度：较多人） > 握有任一被攻破中间 CA 的私钥，就能冒充任何网站；既然已有按层级委派、且危害只限于被攻破实体子树的机制，就应尽快用它做域名验证。（@account42）
认为浏览器可自动缓解，真正重灾区是其余生态与存量软件
- Firefox 十多年前就有 OneCRL，这次几小时内自动保护了用户，Chrome、苹果、微软也有类似工具，后来还有 CRLite 做叶证书吊销；但对浏览器之外的整个生态，吊销几乎没有投入，Go、Rust、Python、Electron、Homebrew、PHP 等都要靠手动升版本，存量软件与物联网设备的影响半径大到难以想象。也有评论确认：若 Tor 出口节点、VPN 或运营商拿到 CA 私钥，就能在浏览器仍显示 HTTPS 且无告警的情况下中间人劫持流量。（认可度：较多人） > Firefox 靠 OneCRL 在几小时内自动保护了用户，Chrome、苹果和微软也有类似工具，但对生态中其余缺乏吊销投入的客户端来说，这才是大灾难。（@galadran）
关注影响是否集中在印度政府服务与物联网，并追问 CA 责任
- 有评论查到该 CA（eMudhra）似乎主要服务印度政府相关网站，如报税等，因此影响可能集中在印度公民使用的政务服务上；同时大量物联网设备会突然变得可黑。也有人直接问：CA 本身会有什么后果？（认可度：少数人） > 从搜索看，这是否主要关联印度政府的报税等网站与服务，影响会集中在印度公民身上？（@albert_e）
有价值的补充
- 各生态具体修补版本已流出：Go 升到 1.27.3 或 1.26.10；Rust 的 rustls-webpki 升到 0.103.16，或 webpki-roots / webpki-root-certs 1.0.10；Python 的 certifi 升到 2026.10.19；Homebrew ca-certificates 升到 2026-09-25_1；Electron 升到 44.9.1、43.8.1 或 42.11.16（@dochtman）。
- PHP 客户端若不想等 composer/ca-bundle，可先用已更新到 2026-10-20 捆绑包的 paragonie/certainty（@CiPHPerCoder）。