2026 年 10 月 17 日，有研究者向 Apple、Google、微软、Mozilla 和 CA 机构 eMudhra 同时报告了一个问题：eMudhra 签发的 8 张中间证书，私钥是数字 4、56、66、115、155、156、230、237 这类单字节整数。
这些证书用的是椭圆曲线 P-384。按规范，私钥应该是 384 位的随机数，取值范围约 3.9 × 10¹¹⁵，暴力枚举没有现实可能。但当私钥只有 4、56 这样的值时，攻击者只需要算 1 倍基点、2 倍基点……一直算到 255 倍基点，就能把私钥还原出来。全部 16 张证书对应的 8 个私钥，安全研究员 Scott Helme 在一台普通笔记本上不到一秒就恢复了。
看起来完全合法
问题出在最容易被自动化检查忽略的地方：这 8 个私钥虽然熵极低，但结构上没有任何破绽。用 4 去乘椭圆曲线基准点，得到的公钥是曲线上的合法点，编码正确，曲线参数正确，签名算法验证通过。证书链条、有效期、扩展字段全部正常。
要发现异常，只能拿小整数挨个试，而主流 CA 审计流程里没有这一步。这就是它能在公网上安静存活 17 个月的原因。
这 8 张中间证书在 2025 年 4 月签发，包含 6 张 TLS 签发 CA（DV / OV / EV 各两代）与 2 张代码签名 CA；2025 年 5 月它们又被 Sectigo 的 AAA Certificate Services 根交叉签名，受影响的证书因此扩大到 16 张。有效期的终点是 2039 年 7 月。
另一个尴尬的细节来自 eMudhra 自己的说明：他们称私钥始终存放在硬件加密机（HSM）里。如果这句话成立，那 HSM 只是在忠实地保管一个数值为 4 的私钥——硬件合规和密钥质量是两件事。社区讨论里有人总结得更直接：密钥在 HSM 里，所以他们大概从来没办法看一眼密钥内容，也就没人发现随机数发生器根本没在工作。
图：涉事的 CA 机构 eMudhra 标识。它的 8 张中间证书在公网上静默暴露了 17 个月。来源：Scott Helme 博客转引 eMudhra 官网
用私钥 4 签 Stripe 证书，curl 认了
私钥等价于公开，剩下的事情就是伪造。
Scott Helme 用私钥 4 为 api.stripe.com 签了一张证书，在本地跑 openssl s_server，然后用默认配置的客户端去连。结果是这样：Linux 和 macOS 上的 curl 输出 SSL certificate verify ok；Python 的握手正常完成；Node.js 返回 authorized: true；Windows 的 CryptoAPI 只要没打开吊销检查，也照单全收。
这里的分界线是信任库的形态。浏览器的信任是中心化、可远程更新的：Chrome 在 10 月 17 日当晚就把涉事证书推入 CRLSet 拦截，几小时后 Mozilla 通过 OneCRL 跟进，10 月 20 日 Mozilla 发布公告并随 NSS 更新移除 eMudhra 根，Chrome 随后在第 43 版根证书库里清理了信任。另外，浏览器的强制证书透明度（CT）日志也帮了忙——安全团队核查后确认，这批弱私钥没有在 CT 日志里留下伪造痕迹，所以普通用户日常上网没有直接受害。
而命令行工具、服务端 SDK、IoT 设备用的是另一套逻辑：信任库是随程序分发的静态文件，默认不查吊销列表，也从不看 CT 日志。浏览器里已经作废的证书，在这些地方依然是合法凭据。
图：数字信任链的失效点不在算法，在密钥的生成环节。来源：Ars Technica
撤销只覆盖了浏览器
把受影响面列出来，能看清风险尾巴有多长。
curl | sh 这类安装脚本（rustup、nvm、Homebrew）如果走 HTTPS 校验，攻击者可以伪造源站，把恶意程序以管理员权限装进开发机。CI/CD 更难处理——GitHub Actions、GitLab Runner、Jenkins 的容器里往往放着云平台密钥和发布凭证，这类机器通常不会有人去手动清理信任库。跨服务调用（支付接口、webhook、OAuth）依赖基础镜像自带的 CA 包，同样在射程里。还有 Windows 的代码签名：eMudhra 的两张代码签名 CA 一旦被伪造，签名过的可执行文件在不查吊销状态的机器上会被当作合法发布。
Filippo Valsorda 的说法是，这一次的清理工作量会超过 Heartbleed：被遗忘的 Linux 服务器、无人维护的容器镜像、还在用自己那份根证书副本的老命令行工具，会构成一条很长的尾巴。Ben Cartwright-Cox 推测成因是示例代码误进了生产，同时指出真正离谱的地方在于一年半里没有任何审计环节发现它。Ian Carroll 的表述是：这些单字节密钥人人都能还原，一旦扩散就无法收容。
尾巴长达 13 年
运维侧能做的事其实很有限。可控的机器上，删掉 eMudhra 的根证书或把中间证书加入黑名单是标准动作；用 OpenSSL 的系统要确认系统证书库已经更新。不可控的部分才是主要问题：家用路由器、摄像头、工控设备、车机、POS 机里的信任库出厂固化，厂商一旦停止维护，除了换设备没有别的办法，而证书要等到 2039 年 7 月才自然过期。
对做产品的人来说，这件事的教训落在设计上。硬编码一份根证书副本能省一次网络查询，代价是此后十几年再也没有撤销通道；把安全边界完全押在”没人会去看私钥”上，也会在某个随机数发生器没初始化的下午失效。
参考链接：
- Scott Helme 技术博客
- We Have A Problem 事故报告
- Ars Technica 深度报道
- Mozilla 官方安全博客
- Hacker News 社区技术讨论
