10 月 17 日 20:06（UTC），Mozilla 收到一份由 Chrome 根证书计划转来的报告：印度证书机构 eMudhra 的 8 张中间证书私钥已经泄露，报告附上了全部 8 把私钥的控制证明。21:48，Mozilla 在不知道报告人方法的情况下自己也还原出了这些私钥——按 Mozilla 在事件单（Bugzilla 2083449）里的说明，这 8 把 P-384 私钥的数值全都小于 256，几乎全是零，瞬间就能算出来。8 张里 6 张是 TLS 中间证书，受 Chrome、Mozilla、微软、苹果四大根证书计划信任；另外 2 张用于代码签名，受微软信任。这些密钥来自 2025 年 4 月 30 日的一次密钥生成仪式。
时间线
- 10 月 17 日：Firefox 在 22:59（UTC）通过 OneCRL 完成拦截。
- 10 月 18 日：09:38（UTC）eMudhra 吊销了这 8 张证书（原因 caCompromise）。eMudhra 说这些中间证书没有签发过终端证书；但私钥既然谁都能算出来，任何人都可以用它们伪造任意域名的证书。
- 10 月 20 日：Mozilla 宣布紧急撤销对根证书 emSign ECC Root CA - G3 的信任，为的是保护那些不检查吊销信息、或者没办法单独拉黑某张中间证书的客户端；Chrome 根证书计划同日表示走同样的路。eMudhra 当天停止从这个根下的所有中间证书签发，并估计约 3 万张证书需要迁移，其中约 97% 是通过 ACME 签发的。
- 10 月 22 日：eMudhra 宣布，董事会决定主动退出全球 SSL/TLS 证书业务。
为什么服务器要自己动手
浏览器有快速吊销机制，拨一下开关就能拦住。服务器上的程序不一样：curl、wget、Python、PHP、Node、Java、Go 发起 HTTPS 请求时，大多依赖系统信任库或者自带的证书包，浏览器更新对它们没有任何作用。Cloudflare 10 月 20 日的说明里专门提醒：更新 SDK 不一定改变底层的校验策略，要看它最终用的是哪个信任库；打完补丁后看到证书报错，千万不要用关闭证书校验的办法来消除。
VPS 上要做的事
- Ubuntu：10 月 20 日的 USN-8944-1 从 ca-certificates 里删除了 emSign ECC Root CA - G3，22.04 的修复包是
20260816ubuntu0.22.04.1，24.04 是20260816ubuntu0.24.04.1；10 月 21 日的 USN-8947-1 同时更新了 NSS，删除这个根和「Comodo AAA Services root」。 - Debian：DSA-6572-1 删除同样两个根，Debian 13 是
20250419+deb13u1；Debian 12 是 DLA-4845-1，20250419~deb12u2。 - 升级后执行
ls /etc/ssl/certs | grep -i emsign_ecc_root_ca_-_g3，没有输出就说明这个根已经不在系统信任库里了。 - 自带证书包的程序要单独升级：Python 的 certifi 从
2026.10.18版起不再包含这个根（我们逐个版本核对过包里的证书文件）。Go 程序在 Linux 上默认用系统信任库，升级 ca-certificates 就覆盖了大部分情况；为了兜住少数系统信任库没有更新的情形，Go 在 10 月 19 日发布的 1.26.10 / 1.27.3 里给 crypto/x509 加了黑名单（GO-2026-6809 / CVE-2026-111943），自己编译的 Go 程序建议用新版本重新编译。Docker 镜像里也有自己的 ca-certificates，要重建镜像、重启容器，见 VPS 上的 Docker 入门。 - 改完要重启相关服务，已经在运行的进程不会重新加载信任库。
这件事和大多数站长自己的证书没有直接关系：你用的如果是 Let's Encrypt 或其他 CA，证书不需要更换，配置方法见 Let's Encrypt SSL 证书配置教程。但它再次说明，防范伪造证书要靠多层手段，.gh、.sl、.as 注册局被劫持那篇讲过的 CT 监控和 CAA 记录在这里同样适用。