八个中级CA私钥泄露！印度eMudhra证书事件梳理与自查指南
前言
印度eMudhra的八个中级CA私钥泄露！拿到私钥的攻击者可以给任意网站签发"系统都认"的证书，全网的HTTPS加密流量都可能被中间人攻击！不过好在大部分主流浏览器已经在动手封禁了，大家只需要及时更新系统和浏览器就好，注意更新后用这个工具 （https://emudhra.we-have-a-problem.com/#check） 检查一下，具体详见后文的“快捷自查”。
但是这事儿还有个影响，curl、pip、git和各种后端程序用的证书库，跟浏览器不是一套东西。你的服务器中没中招，值得花几分钟查一下。
这件事具体有多大影响？
八个eMudhra中级CA证书的私钥已被泄露。这些中级证书，链接到受Mozilla、Microsoft、Apple和Chrome根证书计划以及许多下游信任存储所信任的根证书上。
根源是CA自己犯的错：这些中级证书的私钥在生成时就有缺陷，任何人都可以直接从证书文件里恢复出私钥。从2025年4月这批证书创建那天起，这个问题就一直存在。
后果一句话：拥有任何一个已泄露中级CA私钥的攻击者，都可以冒充任何网站或服务。
那为什么普通用户暂时安全？因为这些中级证书在证书透明度（CT）日志里没有条目——Firefox、Chrome、Edge和Safari这类强制执行CT的客户端，不可能信任没进日志的证书链，所以浏览器场景基本无从攻击。但浏览器生态之外的大量客户端并不强制执行CT，有没有攻击者利用这些缺陷密钥攻击过它们，目前未知。
事件是怎么被发现的？
10月17日，最初的报告者Wayne用这八个中级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 时间线：各方反应有多快？
Mozilla、Microsoft、Apple和Chrome已通过各自的吊销信息分发工具为其用户修复了此问题：
OneCRL：https://blog.mozilla.org/security/2015/03/03/revoking-intermediate-certificates-introducing-onecrl/
CRLSets：https://www.chromium.org/Home/chromium-security/crlsets/
该CA本身也已吊销受损的中级证书。但注意：许多其他软件客户端不读取吊销信息，它们需要更新软件才能确保不再信任这些受损的中级证书。
快捷自查：你中招了吗？
浏览器用户：打开官方检查器 https://emudhra.we-have-a-problem.com/ （检查锚点页：https://emudhra.we-have-a-problem.com/#check ）。
全部为绿色即浏览器客户端已更新；有红色请更新浏览器客户端以确保证书安全。
命令行用户（重点检查这一项），在终端运行：
curl https://dv-g3b-emudhra.we-have-a-problem.com/
curl https://dv-g3b-aaa-emudhra.we-have-a-problem.com/ 如果出现证书错误——恭喜，报错才是好事，说明该客户端已不再信任受损的中级证书；如果正常返回内容，说明你的curl还在信任这批"问题钥匙"，赶紧往下看修复方法。
离线检查：chains.zip打包了检测站点十二个主机提供的PEM格式证书链，以及使用OpenSSL验证它们的说明，适合在不方便联网的环境里排查。
修复首选：更新到最新版本
用户应尽快将浏览器和操作系统更新到最新版本。以下为各软件已发布修复的版本：
补充信息持续更新在 https://github.com/galadran/we-have-a-problem.com ，有新动态可以去这里确认。
各系统临时解决方案
在发行版发布更新的ca-certificates包之前，高级用户可以在系统信任存储中取消信任受影响的根证书（Comodo AAA Certificate Services和emSign ECC Root CA - G3）。不建议普通用户这样做，动手前确认自己清楚每条命令在干什么。
macOS
macOS本身会阻止受损的中级证书，但系统内置的curl、git、python3、perl、ruby和openssl会根据 /etc/ssl/cert.pem 验证证书而不检查吊销状态，且该文件尚未更新。备份后从中移除受影响的根证书：
sudo cp -p /etc/ssl/cert.pem /etc/ssl/cert.pem.bak &&
sudo awk '/^(###|===) /{skip=0} /^=== .*\/CN=(AAA Certificate Services|emSign ECC Root CA - G3)$/{skip=1} !skip' /etc/ssl/cert.pem.bak | sudotee /etc/ssl/cert.pem > /dev/null 系统内置的pip3，以及基于内置python3创建的虚拟环境中的pip，使用的是它们自己那份过时的根证书副本。要让它们改用修复后的系统文件，运行：
F="$(/usr/bin/python3 -c 'import sysconfig; print(sysconfig.get_path("stdlib"))')/sitecustomize.py" &&echo 'import os; os.environ.setdefault("PIP_CERT", "/etc/ssl/cert.pem")' | sudo tee -a "$F" > /dev/null &&sudo chmod 644 "$F" nix-darwin用户请额外遵循NixOS的说明。
Linux
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/blacklisttrust 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/blacklisttrust 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"]; Windows
Microsoft已通过Windows的自动证书信任列表更新（https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/certificate-trust#automatic-certificate-trust-list-updates ）发布了针对这些证书的阻止规则，接收这些更新的计算机不需要此临时解决方法。离线或禁用了自动更新的机器，可以下载并检查 Block-EmudhraCompromisedCA.ps1，然后从PowerShell终端运行（需要PowerShell 5.1或更高版本以及内置的Windows PKI模块）：
powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\Block-EmudhraCompromisedCA.ps1 该脚本会将16个受损的中级证书和交叉签名导入到LocalMachine\Disallowed（不受信任的证书）中。此缓解措施只添加阻止规则、不修改受信任的根证书颁发机构，适用于使用Windows系统证书信任存储和链验证的客户端（包括Schannel TLS和Authenticode）；使用独立CA捆绑包的应用程序仍需要自己的更新。企业管理的设备不建议使用，你的IT部门会管理部署，应用本地更改前先联系他们。
BSD系
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 FreeBSD 14或更高版本，以root身份运行：
cp /etc/ssl/certs/14bc7599.0 /usr/share/certs/untrusted/14bc7599.pem
cp /etc/ssl/certs/ee64a828.0 /usr/share/certs/untrusted/ee64a828.pemcertctl rehash 持续跟踪
事件起因的进一步技术信息，记录在Mozilla bug跟踪器的初始事件报告：https://bugzilla.mozilla.org/show_bug.cgi?id=2083449
受损的八个中级证书及其Sectigo交叉签名列表：https://emudhra.we-have-a-problem.com/impacted-intermediates.json ；它们链接到的根证书列表：https://emudhra.we-have-a-problem.com/roots.json
检查器背后的服务器会匿名记录每个用户代理成功连接的次数（意味着它仍信任受损的中级证书），系统仅记录计数：https://statistics-emudhra.we-have-a-problem.com/ ；包含每个JA4指纹计数的JSON转储文件：https://statistics-emudhra.we-have-a-problem.com/stats.json
信任存储运营者可以参考Mozilla dev-security-policy论坛中的此主题：https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/0R3XLJL6FuE
总结
这次事件非常恶劣，虽然各方的迅速动作已经尽量压低了影响，但是要保护我们自己的隐私安全，仍然需要我们自查自纠。给朋友们一个自查自纠的清单：
浏览器打开检查器，看颜色，有红就更新；
服务器和本机终端跑一遍那两条curl，报证书错误才是安全状态；
对照补丁版本表，把系统、curl、Python、Node这些常用环境的信任库更新到位。
本文信息整理自 Dennis Jackson（https://github.com/dennisjackson） 发布的站点，这是该社区众多贡献者（https://github.com/galadran/we-have-a-problem.com/graphs/contributors） 的工作成果，源代码位于GitHub（https://github.com/galadran/we-have-a-problem.com） ，欢迎提交PR。向负责任披露的Wayne和快速响应的各信任存储运营者致意。
推荐阅读：
