eMudhra 中级 CA 泄露
一家印度证书颁发机构 eMudhra 签发了多个中级 TLS 和代码签名证书，其椭圆曲线私钥几乎可以被轻易猜出（单字节值，如“4”），这实际上使任何人在浏览器和操作系统厂商吊销之前，都能为任意域名伪造证书。评论者指出，主流浏览器的吊销和证书透明度机制降低了 Web 用户的风险，但大量内嵌自有 CA 存储的非浏览器客户端和 IoT 设备可能在未来多年内仍然脆弱。此事件重新点燃了对 Web PKI 模型的批评——即任何受信任的 CA 都可以为任何域名背书——并引发了对 DNSSEC/DANE、更严格的名称约束，以及更集中化或经过审计的吊销基础设施等替代方案的讨论。
事件概述
- 发现 eMudhra/emSign 的八个中级 CA 的私钥可以被轻易恢复。
- 这些是 P-384 ECC 密钥，其私有标量只是很小的整数（<256）；其中一个密钥字面上就是“4”。
- 这些中级 CA 由另一家大型 CA 交叉签名，因此它们可链到广泛受信任的根证书。
- 受影响的中级 CA 覆盖 TLS（包括 DV）以及至少两个受 Microsoft 信任的代码签名 CA。
技术根因（讨论中所述）
- eMudhra 的事件报告将问题归咎于一段与 Ultimaco HSM 一起使用的密钥生成仪式脚本中的缺陷。
- 正常密钥据称是在 HSM 上生成的，但一个 wrap/unwrap“测试”路径生成了弱的备用密钥。
- 由于标签相似，工作人员误用了这些弱密钥来创建 CSR，随后这些 CSR 又被 eMudhra 的根证书和交叉签名 CA 签名。
- CRL 起初是用“正确”的密钥签名的，但验证失败，之后又改用弱密钥重新签名；许多人认为这是一个重大的流程失误。
安全影响
- 任何拥有这些中级证书公钥的人都可以推导出私钥并签发看起来有效的叶子证书。
- 这使得对以下客户端的中间人攻击（MITM）不可检测：
- 信任受影响链路的客户端，且
- 不强制执行证书透明度（CT）。
- 需要 CT 的浏览器会拒绝未记录的滥用，而且在事件发生前，这些中级 CA 的叶子证书没有出现在 CT 日志中。
- 非浏览器 TLS（curl、IoT、VPN、嵌入式/工业系统）暴露尤为严重，因为许多系统不做 CT 检查，也很少更新信任库。
吊销与生态响应
- 主流浏览器使用集中式机制（CRLSet/OneCRL/CRLite 类似方案）快速阻止这些中级 CA；用户通常不需要软件更新。
- 操作系统和库的处理方式各不相同：Windows 可以集中阻断；Linux/Unix 通常只是分发 PEM bundle，因此 Go、rustls、Homebrew、Python 的 certifi、Electron 等都在发布紧急更新，硬性阻断这些中级 CA。
- 许多项目会内嵌自己的 CA bundle，这使得整个生态的修复速度缓慢且不均衡。
- 一些用户报告称，在移动版 Firefox 上，直到 CRL 更新传播后，拦截行为仍不一致。
关于 Web PKI 与替代方案的争论
- 有强烈批评认为，任何受信任的 CA 都可以为任何域名签发证书，因此安全性取决于最弱的 CA。
- 提案与反驳包括：
- DNSSEC/DANE：支持者喜欢将认证与 DNS 层级对齐；批评者指出其运维脆弱性、无法“消灭”行为不端的 TLD，以及比 Web PKI 更弱的监控与驱逐机制。
- 名称约束和 CAA：被认为使用不足或难以部署（NC），而 CAA 只约束签发，不约束客户端接受。
- 信任网（Web of trust）：有人认为它更符合人类社会直觉；另一些人则指出 PGP 的历史失败，以及事实上的中心化权威的出现。
- 一些评论者为 Web PKI 的“死刑”模型辩护：浏览器可以并且确实会驱逐 CA；而现实中你无法把一个 TLD 驱逐掉。
对 eMudhra 和 CA 的后果
- 许多人预计 eMudhra 的根证书会被主流根项目移除；有人将其与过去 CA 的“死刑”案例作比较。
- 一些人提到 eMudhra 通过相关品牌在美国大学证书生态中的角色，引发供应链担忧。
- 该事件凸显了人们认为 CA 审计的薄弱之处，以及允许本意用于密钥导出和广泛使用的中级 CA 的风险。
更广泛的教训（IoT、工具、信任库）
- IoT 以及其他无法更新或很少更新的设备，可能会一直信任这些中级 CA，直到它们过期（约 2039 年），从而成为长期 MITM 目标。
- 一些人把这看作“银色边缘”：对逆向受限设备进行良性 MITM 变得更容易。
- 该事件暴露出拥有大量碎片化信任库和定制 TLS 栈的代价，而不是使用一个可一致更新的平台机制。
- 文中讨论了若干工具和项目（例如 upki、Nix overlays），作为改进非浏览器软件集中化、自动化吊销的一种方式。