CA 私钥可以被猜中之后：从 eMudhra 事件看证书信任链
TL;DR
从 eMudhra 弱私钥事件，弄懂 CA 如何签发证书、浏览器如何建立信任，以及吊销为何不总能阻断风险。
2026 年 10 月，一位研究人员发现，eMudhra 的八张中间 CA 证书对应的私钥弱到可以从公开证书中恢复。六张用于 TLS，另外两张用于代码签名。Mozilla 在收到报告后独立恢复了这些私钥，确认问题出在密钥生成，而不是签名算法被攻破。
我最初想弄明白的不是事件有多轰动，而是一个更基础的问题：**为什么掌握一把中间 CA 的私钥，就可能冒充与它没有业务关系的网站？**要回答它，得先把证书的签发和验证走一遍。
网站证书签发流程
浏览器建立信任的流程
弱密钥进入签发流程
这八把私钥对应 P-384 椭圆曲线，本应从很大的合法范围内随机选取；Mozilla 发现它们的数值全部小于 256。公开证书中已有公钥，只需逐一尝试这个很小范围内的候选私钥，算出对应公钥并比对，就能恢复私钥。问题不在于 P-384 不安全，而在于实际选出的私钥几乎没有不可猜测性。
这也解释了风险的范围：网站私钥泄露，通常首先影响该网站；一个不受域名范围限制的 TLS 中间 CA 私钥泄露，则可能被用来为任意域名签发假证书。攻击者还需要拦截或控制用户连接才能实际冒充网站；CA 私钥本身不能直接解密过去记录的 HTTPS 流量。
eMudhra 对密钥生成仪式的初步解释是：原本在硬件安全模块中生成了正常密钥，后来为测试密钥的封装和解封（wrap/unwrap）加入额外步骤；代码又产生第二组弱密钥。两组密钥标签相近，工作人员误用弱密钥生成 CSR，并由根 CA 为其签发中间 CA 证书。程序生成异常密钥与签发流程选错密钥是两道先后失守的环节。具体代码为什么产生这样小的整数，仍待完整根因报告。
更值得注意的是，2025 年同一批中的六个 TLS 中间 CA 曾出现证书吊销列表（CRL）签名验证失败。eMudhra 当时把问题归为 CRL 生成时选错密钥；这次又解释，最初签 CRL 的是原本预期的正常密钥，而公开的中间 CA 证书却对应另一组弱密钥。那次异常至少说明证书公钥与预期使用的签名密钥不一致，但当时没有把问题追查到密钥生成和中间 CA 签发环节。关于当时发现了什么、为何没有进一步审计，根证书计划仍在追问。
吊销中间 CA 与撤销根信任
eMudhra 表示，出问题的八个中间 CA 没有签发过终端用户证书。这不等于风险不存在：拥有相应私钥的外部人员仍可能自行签发假证书。事发后，这些中间 CA 被吊销，浏览器也部署了阻断措施。
但不同客户端处理吊销信息的方式并不一致。有的应用使用旧信任库或自带证书包，未必能及时获知某张中间 CA 证书已被吊销。Mozilla 因而进一步决定从其信任库移除相关的 emSign ECC Root CA - G3：这样做会保护无法单独阻断中间证书的客户端，但代价是该根之下其他正常签发的证书也需要迁移。受影响的是中间 CA 私钥；移除根信任是风险处置，不是说根私钥也已被证明泄露。
总结
CA 的责任不止于申请时核验域名，还包括密钥生成、对象选择、证书签发、吊销信息发布，以及发现异常后能否追溯到真正的原因。证书链把一次签发变成广泛可接受的信任；同样地，签发链上一个环节选错密钥，影响也不会停在那一张证书上。
