一句话结论
eMudhra 中间 CA 的 8 个证书私钥因生成机制缺陷泄露，攻击者可伪造受主流根信任的证书实施中间人攻击，多数非浏览器系统缺乏防护机制。
关键要点
- eMudhra 中间 CA 共 8 个证书私钥泄露，其中 6 个为 TLS 证书，被苹果、Chrome、微软和 Mozilla 的根证书程序信任；另 2 个为代码签名证书，仅被微软信任。
- 泄露的私钥并非由大随机数生成，而是全部为零，仅最后一个字节分别为 4、56、66、115、155、156、230 或 237，可通过穷举法轻松破解并推导公钥。
- 浏览器可通过后台撤销黑名单阻止受影响的中间 CA，但大多数依赖 Web 公钥基础设施（PKI）的软件缺乏过滤中间 CA 的机制，未打补丁的系统持续暴露于风险中。
- Arch、Debian、Gentoo、Fedora 和 Ubuntu 的 ca-certificates 软件包，以及 Electron、Go、pip、Python certifi、rustls-webpki、Rust webpki-roots 和 uv 等已同步移除 emSign ECC Root CA - G3，但更新传播需要时间。
- Dart 语言自 2026 年 8 月发布的 3.13 版本起不再包含嵌入式 cacerts 文件，开发者可选择系统信任根或自定义信任根，但仍有大量应用程序内部嵌有 cacerts 文件继续信任已泄露 CA。
背景与事实
eMudhra 是一家证书颁发机构（CA），其下挂的中间 CA emSign ECC Root CA - G3 的 8 个证书私钥已被证实存在严重安全缺陷。这些私钥并非由加密安全的随机数生成器产生，而是全部初始化为零，仅末位字节被设置为不同的固定值（4、56、66、115、155、156、230、237）。这种熵值不足的密钥结构使得攻击者可以轻易通过穷举法还原出完整的私钥，并据此推导出对应的公钥。当安全研究人员在活跃的 CA 目录中发现与这些公钥匹配的证书时，安全隐患即被确认。在根存储库事件报告中，名为“Wayne”的研究人员被认定为该漏洞的发现者，他提交了一个名为 proof.zip 的文件包，并附有“这里有问题”的声明。随后，安全研究员 Dennis Jackson 创建了专门网站 emudhra.we-have-a-problem.com（该网站使用 LetsEncrypt 证书）汇总相关技术细节。目前尚无证据表明 eMudhra 遭受了外部入侵，私钥泄露的根本原因是内部密钥生成机制的不安全实现。
受影响证书的信任范围相当广泛。其中 6 个 TLS 证书同时被苹果、Chrome、微软和 Mozilla 的根证书信任程序所接受，另外 2 个代码签名证书被微软信任。这意味着一旦攻击者利用这些泄露的私钥伪造证书，这些证书在主流操作系统和浏览器中将被视为合法。伪造的证书可被用于冒充任意网站或服务，实施中间人（MITM）攻击，而受害者设备上的信任链验证无法识别其非法性。典型的根 CA 证书包中包含数百个 CA 以及数千个继承信任关系的中间 CA，任何一家 CA 都可以为任何域名生成看似合法的证书，只有当信任锚点更新并标记该漏洞时，信任链才会被打破。因此，所有未积极打补丁的系统，包括生命周期已结束的系统，均处于易受攻击状态。
在响应机制方面，浏览器厂商采用了证书撤销黑名单作为快速精准的应对措施。许多依赖 Web PKI 的软件项目，尤其是那些使用 Mozilla cacerts 文件（由 curl 项目维护）的开源项目，选择直接将其信任根中的 emSign ECC Root CA - G3 移除。这一操作包括 Linux 发行版（Arch、Debian、Gentoo、Fedora、Ubuntu）的 ca-certificates 软件包，以及 Electron、Go、pip、Python certifi、rustls-webpki、Rust webpki-roots 和 uv 等工具链组件。然而，这些更新需要时间才能传播到所有需要覆盖的系统，未积极打补丁的系统仍然存在安全漏洞。
影响分析
对于中文开发者与从业者而言，此次事件的实际影响取决于其技术栈是否依赖 Web PKI 信任根，以及是否及时更新了相关组件。首先，所有使用系统信任根进行 TLS 验证的应用程序（包括 Linux 服务器、移动端应用、桌面端工具）都需立即检查是否已移除 emSign ECC Root CA - G3。对于使用捆绑 cacerts 文件的应用（如某些 Java、.NET、Python 旧版本实现），即使系统证书已更新，应用内部的证书包仍可能继续信任泄露的 CA，开发者需要手动更新应用内嵌的证书列表。其次，使用双向 TLS（mTLS）进行客户端身份验证的服务面临更严重的风险。如果 mTLS 端点信任 Web PKI 根证书，攻击者只需生成一个合法格式的证书即可向 mTLS 端点进行身份验证，而该端点很可能无法感知中间证书已被吊销。SSLMate 创始人 Andrew Ayer 指出，目前仍有 6 个服务实例将 mTLS 验证器修改为接受用 serverAuth EKU 替代 clientAuth，这意味着 Web PKI 体系下的 mTLS 应用仍然活跃，这种实现方式本身存在安全隐患。开发者应审计所有使用 Web PKI CA 进行客户端证书验证的场景，考虑改用私有 CA 或启用证书透明度验证。第三，对于仍在维护旧版本或生命周期已结束系统的团队，风险最为突出，因为无法获得安全更新，只能通过网络隔离等补偿性控制措施缓解。
适用边界
上述结论基于 Web PKI 信任模型和证书链验证机制。以下场景不适用或风险显著不同：使用私有内部 CA 且不信任公共 Web PKI 根证书的系统不受影响；采用证书透明度（Certificate Transparency）日志验证而非依赖传统证书链的系统可在一定程度上抵御伪造证书（因为伪造证书不会出现在 CT 日志中）；未使用 TLS/证书进行身份验证的纯对称密钥或预共享密钥认证场景与本漏洞无关；使用不依赖 CA 信任链的证书固定（Certificate Pinning）且 pin 值未包含受泄露 CA 签发的证书的应用程序也不会受到影响。
孤本观察
本次事件暴露了一个常被忽视的工程事实：即使根 CA 未被入侵，中间 CA 的密钥生成实现缺陷同样能导致信任体系崩溃。私钥全部为零且末位字节为固定小数值（4、56、66、115、155、156、230、237）这一细节表明，eMudhra 的密钥生成流程可能存在严重的代码库复用错误或随机数源配置缺陷，而非偶发的外部入侵。这与 David Pollak 在播客中描绘的“末日情景”形成呼应——即使没有国家级对手，工程疏忽本身就能制造出足以被滥用的安全后门，而证书有效期的缩短（如到 2029 年 SSL/TLS 证书有效期将缩短至 47 天）虽能降低单点泄露的影响窗口，但无法消除密钥生成层面的系统性风险。
常见问题
eMudhra 中间 CA 泄露的 8 个证书私钥具体有什么缺陷？
私钥并非由随机数生成，而是全部为零，仅最后一个字节分别为 4、56、66、115、155、156、230 或 237，可通过穷举法轻松破解并推导公钥。
受影响的 TLS 和代码签名证书分别被哪些主流平台信任？
其中 6 个 TLS 证书被苹果、Chrome、微软和 Mozilla 的根证书程序信任；另外 2 个代码签名证书仅被微软信任。
哪些开源项目和 Linux 发行版已同步移除受影响的 emSign ECC Root CA - G3？
Arch、Debian、Gentoo、Fedora 和 Ubuntu 的 ca-certificates 软件包，以及 Electron、Go、pip、Python certifi、rustls-webpki、Rust webpki-roots 和 uv 等已移除。
Dart 语言从哪个版本开始不再包含嵌入式 cacerts 文件？
Dart 语言自 2026 年 8 月发布的 3.13 版本起不再包含嵌入式 cacerts 文件，开发者可选择系统信任根或自定义信任根。
来源：InfoQ 中文 AI