384 位曲线，实际密码是 4
2026 年 10 月 17 日，周六，研究者向 Apple、Google、Microsoft、Mozilla 和印度证书机构 eMudhra 报告了一个发现：eMudhra 的 8 张中间证书私钥，能在笔记本上一秒内破解。
这些证书用的曲线是 P-384，按设计，私钥应该是一个 384 位的随机数，可能的取值约有 10 的 115 次方种。实际的私钥是什么？47 个字节的 0，加一个字节。8 把钥匙分别是 4、56、115、155、156、230、66、237。其中一把，就是 4。
破这样的钥匙最多需要 255 次椭圆曲线点加运算，一台普通笔记本不到一秒。研究者从 Mozilla 公告附带的 16 张证书里，把 8 把私钥全部还原了出来。这些私钥从 2025 年 4 月证书签发那天起，就等于公开的。
图：击穿的挂锁。来源：Ars Technica
证书检查全都过了，问题在哪
一条 HTTPS 信任链从根证书往下逐级签发，每一级都要通过严格的格式检查：曲线合法、编码合法、签名结构合法。eMudhra 这 8 张证书，6 张 TLS 签发 CA（DV/OV/EV 各两代），2 张代码签名 CA，全部创建于 2025 年 4 月，5 月由 Sectigo 的 AAA Certificate Services 根交叉签名——每一项检查都通过了。
没有任何一项检查要求私钥真的是随机数。生成私钥的环节在机构自己手里，外部只能看到公钥。P-384 的数学强度撑起了 10^115 种可能，前提是那把钥匙真的从里面随机抽出来。 eMudhra 的问题就出在这个没人替你检查的环节上。
社区在讨论里猜测了几种成因：生成脚本按位置传参传错了变量，或者代码里 key[0] 恰好取到了包装密钥的字节。也有人反驳：密钥本来就该在硬件安全模块（HSM）内部生成，能在外面生成、还能错成这样，说明流程从一开始就不对。
浏览器连夜封杀，四天里做了什么
10 月 17 日当晚，Chrome 推送 CRLSet 拦截这 8 张证书，几小时后 Mozilla 用 OneCRL 跟上。10 月 20 日，Mozilla 公开事件并在 NSS 更新里直接移除 eMudhra 根证书；Chrome 确认该根进入 Chrome Root Store v43。
为什么动作这么快？研究者的判断是 Ian Carroll 那句话：「它们本质上是任何人都会分解的单字节密钥，问题无法被控制。」没有窃取时点可以追溯，密钥在 17 个月里任何一天都可能被任何人生成过伪造证书。
Chrome 补充了一条细节：这些 CA 从来没在证书透明度（CT，Certificate Transparency）日志里签发过 TLS 证书，所以伪证书在 Chrome 默认不会被信任。CT 能发现错误签发，但挡不住签发本身——而且大量软件根本不检查 CT。
图：信任链每一级都依赖上一级的检查，而最底层的密钥质量没人查。来源：Keytos
curl | sh 安装脚本排在风险名单最前
主流浏览器用户基本安全：拉黑加强制 CT，两道闸都关了。真正的暴露面在浏览器之外。
curl、Python、Node、Go、Java、git、各种包管理器，这些非浏览器 TLS 客户端默认信任磁盘上的 CA bundle，默认不查吊销，默认不查 CT。对这些客户端来说，吊销公告形同虚设——它们读到 eMudhra 的 CA bundle 时，8 位私钥的中间 CA 依然是可信任的签发者。
风险组合最锋利的地方在两处：一是 curl | sh 类安装脚本和软件自更新器，伪造证书意味着攻击者代码以用户权限甚至 root 权限直接跑起来；二是 CI/CD 流水线，构建容器里往往持有云密钥、registry token 和签名密钥。攻击者需要的全部装备，只是一台笔记本和不到一秒的算力。
eMudhra 辩护与退场
10 月 22 日，eMudhra 宣布退出全球 SSL/TLS 证书业务。公司口径有三点：全球 SSL/TLS 只占收入约 1%；数据主权与合规成本逐年上升，加上大厂免费签发，这块业务不划算；「围绕这次事件的社交媒体放大，带来的审视与 SSL/TLS 在我们业务里的分量完全不相称」。同时强调自己在 14 小时内吊销了受影响 CA，从未签发过终端实体证书，基础设施未被入侵。
社区不接受「不相称」的说法，追问集中在一点：17 个月里为什么没有任何内部流程发现这把私钥不是随机数。反驳意见落回同一个地方——包装密钥本该在 HSM 内部生成，能在外面生成，说明流程从第一天就是错的。
最后一环是人，且没有自动检查兜底
整件事里没有一个算法出错。曲线合法，编码合法，结构合法，交叉签名来自 Sectigo 这样的大根。8 张证书在 17 个月里通过了所有自动检查，问题只落在一件机器不会做、审计也不会默认做的事上：有没有人真的去看一眼，那把本该是 384 位的私钥，实际是不是一个 8 bit 的整数。
HTTPS 的信任链末端连着浏览器，但中间每一级 CA 的私钥质量，外部世界只能靠公钥倒推——eMudhra 这次倒推用了 17 个月，最后靠的是研究者手动检查。PKI 的安全边界一直落在纪律上，而纪律没有 curl 那种一行命令的自检。eMudhra 退出 SSL/TLS 业务换来事情落幕，但「谁检查检查者」这个环节，下一次未必还有一个占收入 1% 的选项可以放弃。
参考链接：
- Mozilla Bugzilla 公告与 NSS 更新说明
- Chrome Root Store v43 说明
- eMudhra 退出全球 SSL/TLS 业务声明
- Ian Carroll 的评论
- HN 讨论 (item?id=50177916)
