eMudhra 弱密钥补丁追踪：8 个可复原私钥暴露的证书生命周期盲区

Cloudflare 在 2026 年 10 月 30 日发布的复盘里，最值得开发者注意的是一组对比：在服务端，从得知消息到主要外连系统拒绝 eMudhra 弱密钥只用了数小时；在客户端，一周 5000 万次探测之后，仍有大量客户端接受这些密钥。补丁追踪真正难的部分不只在写补丁，还在于补完之后如何确认其他人也打了补丁。

需要先说清事件性质。这次不是"CA 的密钥被少数攻击者拿到"，而是密钥本身弱到可以从公开证书里近乎即时复原。两者的处置逻辑完全不同：前者靠吊销和追查，后者要求所有信任方在泄露公开的同一时刻完成升级。

弱到什么程度：8 个私钥，其中一个就是数字 4#

按 Cloudflare 的记述，2026 年 10 月 19 日他们得知 eMudhra 有 8 个中间证书私钥异常弱，取值分别是 4、56、66、115、155、156、230 和 237。原文标题里的 "Four, just four" 说的是其中一个密钥就是数字 4——不是四位数字，就是 4 本身。这个量级的私钥没有保密性可言。

来源文章把这个事件与 DigiNotar、TÜRKTRUST、TrustWave 等历史 CA 事故做了区分：过去那些事件里，密钥的获取范围在一定程度上是受限的，能签发欺诈证书的是有限的一组攻击者或组织；而这次的中间私钥可以从公开证书中复原，任何人都能独立重算出同样的签名密钥，为任意域名签发证书，只要目标客户端没有打补丁、并且不强制证书透明度（Certificate Transparency，CT）。

eMudhra 宣布退出公共 CA 业务，并把原因归于密钥生成脚本的一处错误，但截至该文发布尚未公开这个脚本。文章还提到一个细节：他们先用一个可能是正确生成的密钥签发了证书吊销列表（CRL），随后又把它改成用弱密钥签名。审计方与交叉签名方在其中扮演什么角色，原文明确说仍需澄清。这些都是来源方的陈述，第三方复现情况待核实。

服务端补丁：数小时能做完的部分#

Cloudflare 公布的处置时间线可以作为"服务端一侧能力上限"的参照，但不宜当成通用模板——它依赖自家代理栈和源码可分析性。

• 10 月 19 日当天开始修复高影响系统，其中包括用 Pingora 构建的、面向客户源站的外连代理，这部分承载了 Cloudflare 大部分出站连接，在数小时内改为拒绝这些弱密钥。
• 同时用 AI 辅助分析源码，找出其他信任这些密钥的系统。原文称四小时内拿到完整分析结果，随后为每个系统建单，要求团队在当天结束前确认或修正判断；确认高影响的立即修复，低影响项要求在"上周末"前完成。
• 10 月 21 日完成日志铺开，用于记录任何由 eMudhra 弱密钥签发的证书出现。

一周后，他们观测到约 22,000 次使用弱 eMudhra 密钥的尝试握手。其中三分之二是对测试站点的抓取，例如他们自己在上一篇开发者指引里提到的 emudhra.we-have-a-problem.com；剩下三分之一几乎都指向那些用弱中间证书给自己配了证书的源站。所有配置了证书验证的握手都被拒绝，因为这些系统已经打过补丁。

更值得看的是约 160 次异常握手：这些证书的 Subject Alternative Name（SAN）写的是其他组织的域名，与握手请求的 SNI 无关，其中一些域名与消费级 IoT 设备相关；这些伪造证书是在密钥泄露之后签发的，有的有效期超过两年，长于公共 CA 允许的最长有效期。不过原文判断，它们更像是服务器自己的默认证书，而不是针对 Cloudflare 连接的拦截尝试——域名和实际连接目标对不上，主机名校验本来就会失败；而且同一张证书出现在多个地点的连接里，说明它来自服务器本身，而不是某条网络路径上的中间人。

时间上，他们看到的一张伪造证书日期是 10 月 20 日 18:19 UTC，距 Mozilla 的 bug 报告公开不到一小时。原文同时说明：这不排除存在精心定向的拦截，判断只能依赖系统被入侵的常规间接信号，而目前没有看到这类信号。

客户端侧：5000 万次探测能看到什么#

服务端可以主动打补丁，访问者的浏览器和运行时则无法直接测试——强行测试会中断连接。Cloudflare 选择了一个间接方法：在部分验证页面上发出两个探测连接，ca1.cloudflarecaptcha.com 装 eMudhra 签发的证书，ca2.cloudflarecaptcha.com 装正常签发的证书作为对照，然后记录探测是否成功，以此判断访问者是否仍然信任这些弱密钥。

这个方法有两处必须一起读的限定。第一，验证页面的流量本身高度偏斜，其中包含大量未确认的机器人；第二，只有执行 JavaScript 的客户端才会发出探测。所以下面的数字描述的是"这批流量"，不是全网浏览器份额。

一周约 5000 万次探测，期间还夹杂了几次会影响数据连续性的变更：10 月 23 日 15:30 把对照端点也改为提供 eMudhra 证书但去掉签名证书时间戳（SCT）；10 月 23 日 16:30 验证平台因无关问题回滚，探测直到 10 月 27 日 10:00 才恢复；10 月 27 日 16:37 补上当时并非所有客户端都认识的 G3 交叉签名，并从两个端点移除 SCT；16:49 把 ca2 切换到 AAA Certificate Services 根；18:18 把探测覆盖从非付费客户验证页面的 1% 提高到 10%。

在这样的口径下，结论是：较新的现代浏览器基本已打补丁，机器人和旧浏览器没有；嵌入式浏览器（例如 Android WebView）明显滞后，仍有 30%–40% 接受。第一个周末能看到清晰的打补丁迹象，之后曲线基本走平。按网络（ASN）拆开看，在大型网络里超过一半的探测仍然接受受损链，无论是否带有机器人信号。

还有一个容易误读的点：10 月 29 日 18:00 UTC 左右上线的检测发现，大量伪装成 macOS 上 Chrome 150–154 的机器人流量涌入，这在总量图上看起来像补丁率上升，实际是流量分类变化——同一批 User-Agent 在"检出机器人信号"的图里对应的是接受率上升。Linux 上的 Chrome 150–154 是例外，接受率持续下降，与这批客户端继续打补丁一致，但原文也说明这只是提示性证据，不是定论。

四个盲区#

把上面三段事实放在一起，能看出证书生命周期里四个彼此独立的失效点。这是对材料的归纳，不是原文的章节结构。

1. 私钥生成缺少可验证性。一个生成脚本的错误能产出 8 个这种量级的密钥，说明生成环节没有被独立复现或交叉检查。脚本至今未公开，外部无法验证错误的具体形态。
2. 吊销机制本身可能被污染。CRL 先由一个可能正确的密钥签名，随后又被改成弱密钥签名。当吊销凭证的签名密钥本身可疑时，"已吊销"这个信号的可信度需要重新评估。
3. 审计与交叉签名的责任边界不清。原文把审计方和交叉签名方的作用列为待澄清事项。对一个被广泛信任的中间 CA 来说，这两道关卡本该是发现异常的位置。
4. 客户端信任库的更新速度。这是整条链上最慢、也最难直接测量的一环。探测数据显示，服务端几小时能完成的事，在客户端要以周计，而且不同客户端类型差异很大。

开发者现在能做的检查#

以下步骤基于原文给出的处置逻辑整理，不构成对具体产品的操作指南；执行前请以各厂商公告为准。

• 盘查出站信任点。不只是浏览器。反向代理、Webhook 回调、包管理器、容器基础镜像、CI runner、服务网格 sidecar，凡是会验证 TLS 证书的地方都要列出来。Cloudflare 用源码分析做这件事，规模较小的团队可以用依赖清单和配置扫描替代。
• 确认自己是否在用 eMudhra 签发的证书。如果是源站证书，应尽快替换；原文提到 Cloudflare 客户在使用 WARP、Tunnel 等产品时有对应的处理事项，具体以其上一篇博文为准。
• 更新客户端。浏览器、运行时、嵌入式 WebView 和操作系统信任库都要覆盖。原文特别提到 macOS 上的开发者应参考 Dennis Jackson 维护的众包说明页，但材料没有给出该站点的具体地址，需要另行查找核实。
• 把 CT 强制当作纵深防御。原文的表述是：未打补丁且不强制 CT 的客户端会接受伪造证书。反过来说，强制 CT 能在密钥已经泄露的情况下多挡一层。
• 关注信任库的动态更新能力。原文提到 upki 这类项目的思路：信任库不应是一份静态的根证书列表，而要能快速接收吊销和 CT 相关信息。这是方向性建议，落地情况待核实。

边界与待核实#

本文所有事实来自 Cloudflare 的这篇复盘文章（blog.cloudflare.com/emudhra-patching/），属于单一来源的当事人叙述。以下几点在材料中没有答案，不应据此推断：弱密钥的指纹或序列号清单、受影响证书的确切数量、各客户端厂商的具体修复版本号、eMudhra 生成脚本错误的具体内容。

22,000 次握手和 5000 万次探测都是特定观测口径下的数字，不能外推成全网比例；探测流量偏斜于验证页面，且只覆盖执行 JavaScript 的客户端。是否发生过定向拦截，原文的说法是尚未观察到相关信号，但没有排除。补丁追踪到这里能给出的确定结论只有一条：服务端可以很快，客户端不会同样快，两者之间的时间差就是暴露窗口。