eMudhra 证书颁发机构（CA）的八个中间证书私钥已确认泄露。与安全事件中常见的密钥被盗不同，此次泄露源于密钥本身极其脆弱：其中一个私钥仅仅是数字 4，其他包括 56 和 115 等。安全研究人员在笔记本电脑上从公开证书中恢复这些密钥，耗时不到一秒。
事件时间线与响应
10 月 17 日（星期六），安全研究人员向苹果、谷歌、微软、Mozilla 及 eMudhra 报告了私钥泄露问题。当晚，Chrome 通过 CRLSet 更新阻止了相关证书，Firefox 随后也通过 OneCRL 进行了封锁。10 月 20 日（星期二），Mozilla 公开披露此事，发布 NSS 更新移除 eMudhra 根证书；Chrome 亦确认将在 Chrome Root Store v43 中移除该根证书。
受影响的八个中间证书包括六个 TLS 颁发 CA（涵盖 DV、OV 和 EV 类型，每类两代）以及两个代码签名 CA，均创建于 2025 年 4 月，并于 2025 年 5 月由 Sectigo 的 AAA Certificate Services 根证书进行交叉签名。
技术成因：单字节弱密钥
这些密钥基于 P-384 椭圆曲线。理论上，P-384 私钥应为一个随机的 384 位数字（约 10¹¹⁵ 种可能性），使得反向推导在计算上不可行。然而，eMudhra 生成的私钥 d 仅由单个字节构成，前 47 个字节均为零。
由于单个字节仅有 256 种可能值，攻击者只需计算 1 × G 到 255 × G，即可在毫秒级时间内通过暴力破解匹配出私钥。这意味着，整个信任链仅建立在 8 比特的安全性之上。研究人员验证发现，所有八个密钥均可瞬间被破解，且由此生成的公钥在证书结构中完全合法，常规检查无法发现异常。
“它们是固有的弱单字节密钥，任何人都可以进行分解，且问题无法得到控制。”——安全研究员 Ian Carroll
风险评估：非浏览器客户端面临长期威胁
对于主流现代浏览器（Chrome、Firefox、Safari），风险相对可控。这些浏览器强制实施证书透明度（CT）日志检查，且未发现有链接到这些 CA 的 TLS 证书出现在 CT 日志中，加之快速的吊销机制，有效阻断了伪造证书的信任。
然而，庞大的非浏览器 TLS 客户端生态系统面临严重且长期的风险。包括 curl、Python、Node.js、Go、Java、git、包管理器以及各类守护进程在内的客户端，通常依赖本地 CA 捆绑包，默认不检查证书吊销状态（CRL/OCSP）且不验证 CT。因此，即使 eMudhra 和 Sectigo 已吊销中间证书，这些客户端仍可能信任由弱密钥签名的伪造证书。
高风险场景包括：
- 自动安装与更新程序：如 rustup、nvm、Homebrew 及 IoT 固件更新器，若通过 HTTPS 下载未签名脚本，可能执行攻击者代码。
- CI/CD 管道：GitHub/GitLab 运行器、Jenkins 等在共享网络中获取依赖，可能泄露云密钥和令牌。
- 服务器间 API 调用：支付网关、Webhook 及云 SDK（AWS CLI、Terraform 等）可能遭受中间人攻击，泄露 API 密钥和客户数据。
- IoT 与嵌入式设备：摄像头、路由器、医疗设备等固件往往冻结至 2039 年，无法及时更新根存储，长期暴露于风险之中。
- Windows 代码签名：Windows 系统直接信任 eMudhra 代码签名根证书，恶意软件若使用泄露密钥签名，在不检查吊销的系统上将被视为合法软件。
测试显示，在默认配置下，curl、Python 和 Node.js 均接受了使用泄露密钥签名的伪造 api.stripe.com 证书。Windows CryptoAPI 在未开启吊销检查时也接受了该证书链。
应对建议
针对可更新设备，建议立即执行以下操作：
- 更新 CA 捆绑包：升级操作系统
ca-certificates、certifi、Node.js 等软件包，并在基础镜像更新后重新构建容器镜像。 - 隔离不可更新设备：对于路由器、打印机及固件冻结的 IoT 设备，由于其信任链将持续至 2039 年 7 月证书过期，需通过网络隔离或其他补偿性控制措施降低风险。
据 eMudhra 在 Mozilla 事故工单中的解释，此次事件系 HSM 脚本错误及人为失误所致：仪式期间生成了第二个弱密钥对，因名称相似误用于生成 CSR。值得注意的是，AI 代理仅需简单提示即可恢复这些 CA 私钥，进一步凸显了密钥强度的致命缺陷。