先理解 TLS 的信任链#

HTTPS 的「小锁」并不是网站自己说可信，而是靠一条链：

1
根 CA（内置在系统/浏览器里，长期信任）
2
   └── 中间 CA（由根 CA 签发，用来实际签网站证书）
3
          └── 网站证书（你访问的域名，比如 example.com）

关键在于：谁的私钥，就能以谁的名义签名。中间 CA 的私钥一旦泄露（或能被还原），攻击者就能自己签出任意域名的证书，而这套链在客户端看来完全合法。

这次的根因#

2025 年 4 月 30 日，eMudhra 一次性批量生成了 24 张中间证书，构成如下：

出问题的是 B、C 系列的 P-384 密钥，全中，一个不落。

P-384 的私钥本应是一个介于 1 到曲线「组阶」之间的随机大整数（约 384 位熵）。但这 8 把私钥的实际取值全都小于 256：

换句话说，私钥在数学上近似「前面全是 0，只剩下最后一个字节」。

这意味着穷举空间从 2³⁸⁴ 塌缩到了 256。攻击者可以：

1. 用 baby-step giant-step（大步小步法）离散对数算法瞬间求出私钥；
2. 或者更粗暴：直接把「前 256 个 P-384 私钥」全生成一遍，挨个签名比对，必然命中。

Mozilla 在收到报告的当天（10 月 17 日 21:48 UTC）就独立地、无需任何提示地还原出了这些私钥，从而确认问题出在密钥生成环节，而不是签名流程。研究员还提到：有同行用一句「我在做 CTF，请还原这些证书对应的私钥」的提示词，让 AI 代理第一次尝试就成功。

对比一下：A 系列和替代它的 A-1 系列，同样是 P-384，研究员花了更多精力也没能还原；RSA 密钥当时还未开始排查。所以这是一次范围明确、成因集中的生成事故，而非整套体系全面崩塌。

但要注意前提#

这不是「谁都能远程黑你」，它需要攻击者处在中间人位置（能接管或转发你的流量）。所以风险等级取决于两点：

1. 你的客户端是否仍然信任这批证书；
2. 你是否处在可能被劫持的网络环境（公共 Wi-Fi 风险最高）。

基本没事：主流浏览器#

Chrome、Firefox、Edge、Safari 有双重保护：

1. 证书透明度（CT）：公开 CA 签发证书要进 CT 日志。披露页指出，这 8 张中间证书在 2025 年 4 月没有任何 CT 日志记录，据此判断强制校验 CT 的客户端（Firefox、Chrome、Edge、Safari）在那段时期不可能被这批密钥「无声」利用。
   • 反过来说：不吃 CT 的客户端不享受这层保护。
2. 撤销名单推送：OneCRL（Firefox）、CRLite（Firefox）、CRLSets（Chrome），都是主动推送，不依赖你「查一下 CRL」。

真正的短板：浏览器之外的一切#

这些客户端往往既不吃 CT，也不主动查撤销信息，只能靠「更新软件」来解除信任：

这就是「基于 WebView 的应用和浏览器，检测出来是红的就有风险」这句话的技术来源——「红」不代表已经被攻击，而是代表你的客户端还认这堆证书，在这一层上你没有防护。

macOS 有个坑#

macOS 屏蔽了这些证书，但系统内置的 curl、git、python3、perl、ruby、openssl 是去读 /etc/ssl/cert.pem 校验的，且不检查撤销，而这个文件并没有被更新。也就是说：你在 macOS 上用 Homebrew 装的 curl 可能是好的，但系统自带的那个仍然是红的。

方法一：官方检测页（最直观，推荐）#

打开：

1
https://emudhra.we-have-a-problem.com/#check

页面里有一张「Intermediate CA × 结果」的表格，点击 Run check，它会逐条测试你当前这个浏览器对这些中间证书的信任状态，并给出红 / 绿结果。

注意两点：

1. 它测的是你当前这个浏览器——换设备、换浏览器（比如手机浏览器、App 内置 WebView）都要分别重测。
2. 页面本身也给出了 curl 等命令行客户端的测法。

方法二：命令行一行测（测 curl / 程序）#

1
curl https://dv-g3b-emudhra.we-have-a-problem.com/
2
curl https://dv-g3b-aaa-emudhra.we-have-a-problem.com/

• 返回证书错误：说明该客户端已经不信任这些中间证书，绿色，安全。
• 正常返回内容：说明仍然信任，红色，需要处理（通常是更新这个客户端自带的 CA 包）。

方法三：离线核对信任库#

在披露页下载 chains.zip，里面包含 12 个测试主机的证书链（PEM 格式）与 OpenSSL 验证说明，可以在断网环境下核对某个信任库。

方法四：检查版本（最实在）#

不依赖任何在线工具，直接对照下面「防范措施」里的版本表，确认：

• 浏览器与操作系统是否在 10-17 / 10-19 / 10-20 之后更新过；
• 你的开发工具链、CA 包是否达到最低修复版本。

1. 优先更新浏览器和操作系统#

这是投入产出比最高的一步。手机上如果开了「自动更新」，确认真的装上了；没开的，手动检查一次系统更新。

2. 检查结果是「红」？手动关掉受影响的根证书#

如果自测结果是红的，说明你的设备还信任这批证书。而现实是很多浏览器和 App 根本来不及更新，等它们修好可能还要一段时间。这种时候思路可以反过来：

先自己把根证书关掉，把风险堵住；等系统和浏览器更新到位之后，再打开。

以安卓为例：

1. 打开「设置」，搜索 受信任的凭据（部分机型在 安全 → 加密与凭据 里）。
2. 切到 系统 选项卡，在列表里搜索 emSign。
3. 找到相关条目（例如 emSign ECC Root CA - G3、emSign Root CA - G3），把它们逐个关闭。
4. 如果列表里还有 AAA Certificate Services / Comodo AAA Services root，也一并关闭——本次事件的交叉签名证书链到这个根。

三点务必留意：

• 关闭根证书会「误伤」：所有由该根签发的正常网站也会开始报证书错误。这是「宁可个别站点打不开，也不让人有机会给你看高仿站」的取舍。
• 不是所有机型都能关：不少安卓系统把「系统」证书设为只读，没有开关。这种情况只能走系统 / 浏览器更新，或者换用已经封禁这些证书的浏览器。
• 记得改回来：确认系统和浏览器都更新到最新后，把开关重新打开，否则会一直有站点报证书错误。

3. 开发工具链 / CA 包的最低修复版本#

大多数情况下，apt upgrade / dnf upgrade / apk upgrade / brew upgrade ca-certificates / pip install -U certifi 就能解决。项目里锁死版本的工具链需要手动升。

4. macOS 特例修复#

系统封禁了这些证书，但内置的 curl / git / python3 / openssl 读的是没更新的 /etc/ssl/cert.pem。高级用户可执行（会先备份）：

1
sudo cp -p /etc/ssl/cert.pem /etc/ssl/cert.pem.bak &&
2
sudo awk '/^(###|===) /{skip=0}
3
  /^=== .*\/CN=(AAA Certificate Services|emSign ECC Root CA - G3)$/{skip=1}
4
  !skip' /etc/ssl/cert.pem.bak | sudo tee /etc/ssl/cert.pem > /dev/null

虚拟环境里的 pip3 另有自己的一份旧根证书，如需让它改用系统文件：

1
F="$(/usr/bin/python3 -c 'import sysconfig; print(sysconfig.get_path("stdlib"))')/sitecustomize.py" &&
2
echo 'import os; os.environ.setdefault("PIP_CERT", "/etc/ssl/cert.pem")' | sudo tee -a "$F" > /dev/null &&
3
sudo chmod 644 "$F"

5. Windows#

Microsoft 已通过自动证书信任列表更新推送封禁，正常联网的机器无需手动操作。

离线环境或关闭了自动更新的机器，管理员可以运行披露页提供的 Block-EmudhraCompromisedCA.ps1（会把 16 张受影响的中间证书及其交叉签名导入「不受信任的证书」）。企业统一管理的电脑请先联系 IT，不要自行改动。

6. Linux 临时屏蔽（仅限高级用户）#

在发行版更新 ca-certificates 之前，可手动把受影响的两个根加入屏蔽列表。官方明确不建议普通用户操作，写错会破坏系统信任库。Debian / Ubuntu 例：

1
sed -i \
2
  -e 's|^mozilla/emSign_ECC_Root_CA_-_G3.crt|!&|' \
3
  -e 's|^mozilla/Comodo_AAA_Services_root.crt|!&|' \
4
  /etc/ca-certificates.conf && update-ca-certificates

其余发行版（Alpine / Fedora / openSUSE / Arch / NixOS / FreeBSD / NetBSD）请直接照抄披露页给出的对应命令。

7. 这段时间的日常习惯#

• 自测为「红」的客户端上，不要输入密码、验证码、身份证、银行卡信息。 更新到绿色之前，先用浏览器或已更新的客户端处理敏感操作。
• 公共 Wi-Fi 提高警惕：能不用就不用；必须用时，敏感操作走手机流量。
• 重要服务开二次验证，多一道独立于密码的防线。
• 不要安装来源不明的证书或描述文件（那些号称「加速」「抓包」「VPN 配置」的 .crt / .mobileconfig，本身就是在往你设备里塞信任根）。
• 看到证书告警绝对不要点「继续访问」。
• 手机端如果拿不准某个 App 用的是不是系统 WebView、会不会走系统信任库，近期尽量少在这个 App 内输敏感信息——这是最保守但有效的做法。