弱密钥证书的修补追踪：从 2.2 万次握手尝试看吊销与更新的时间差

标题问的是“时间差”，材料能给出的不是单一秒数，而是两段速度的对比：弱密钥公开后，私钥可从公开证书恢复，伪造证书在数小时内出现；客户端要拒绝弱链，却要等信任存储、浏览器、嵌入式运行时和服务端证书链更新。Cloudflare 的追踪文章把这两段放在同一时间轴上，本文按开发者能核验的维度拆开。

弱密钥改变了什么：利用几乎即时#

材料称，2026 年 10 月 19 日 Cloudflare 得知 eMudhra 的 8 个极弱密钥，值分别为 4、56、66、115、155、156、230、237。与过去证书颁发机构（CA）密钥泄露不同，这次受影响的中间私钥可以“几乎即时”从公开证书中恢复；任何人只要能拿到这些证书，就能为任意域签发证书，而未强制 Certificate Transparency（CT）的未修补客户端会接受。

eMudhra 宣布退出公共 CA 业务，声称密钥生成脚本有误，但尚未公开脚本；材料称，它先用可能是正确生成的密钥签发了证书吊销列表（CRL），随后又更正为用弱密钥签名。审计方和交叉签名方的角色，材料称仍需澄清。这些事实说明，吊销动作本身也处在争议和复核之中，不能把“已发 CRL”直接等同于“客户端已经拒绝弱链”。

Cloudflare 的修补顺序：先切断高影响出站，再全量盘点#

材料给出的顺序是：10 月 19 日立即修补高影响系统，包括使用 Pingora 的客户源站代理，数小时内开始拒绝脆弱的 eMudhra 密钥；同时用 AI 辅助分析源码，4 小时内完成全量分析，按系统分票确认；高影响立即修补，低影响工单截止到该周结束前。日志在 10 月 21 日铺开。截至该文写作时，所有高优先级系统已修补，少量低影响工单仍在处理。

这段是 Cloudflare 自身范围，不是行业通用 SLA；其他组织不能直接套用“4 小时”。但顺序可借鉴：先找出站 TLS 路径，再找信任存储，再排优先级。

2.2 万次握手尝试：数字的边界#

日志铺开后约一周，Cloudflare 看到约 2.2 万次使用弱 eMudhra 密钥的握手尝试。约三分之二访问测试站点 emudhra.we-have-a-problem.com；剩余几乎三分之一指向“源站给自己设置了弱中间证书”的场景。所有配置了证书验证的握手都被拒绝。

约 160 次握手呈现的证书更值得注意：证书的 Subject Alternative Name（SAN）命名了其他组织的域，与握手请求的 Server Name Indication（SNI）无关；部分域名与消费级 IoT 相关；这些伪造证书在密钥泄露后制作，有的有效期超过两年，超过公共 CA 可签发期限。材料判断它们更像服务器自己的默认证书，而不是针对 Cloudflare 的拦截尝试：域名不匹配，主机名验证本来就会失败，而且多个地点看到同一证书，说明它来自服务器本身。

这不等于“没有风险”。Cloudflare 说，没有证据表明弱密钥被用于拦截其连接，但不能排除精心定向的拦截；目前只能依赖系统失陷的间接信号，尚未看到。更直接的事实是：一个伪造证书的日期为 10 月 20 日 18:19 UTC，在 Mozilla bug 报告公开后不到一小时。这意味着“公开到被利用”的窗口极短，而“公开到被客户端拒绝”的窗口长得多。

访客侧：5000 万次探测看到什么#

要判断访客是否仍信任弱密钥，不能直接测试而不破坏连接。Cloudflare 在挑战页面上对一部分流量发两个探测：ca1.cloudflarecaptcha.com 装 eMudhra 签名证书，ca2.cloudflarecaptcha.com 装正常签名证书作对照，记录探测是否成功。一周约 5000 万次探测。

材料明确给出限制：挑战页流量高度偏斜，包含大量未确认机器人；只有执行 JavaScript 的客户端才会发探测。因此比例不能外推为全网用户比例。

在这个范围内，观察是：现代浏览器大多已修补，机器人和旧浏览器没有；嵌入式浏览器如 Android WebView 有 30–40% 仍接受。首个周末有修补迹象，之后少有变化。10 月 29 日 18:00 UTC 左右，Cloudflare 发现大量伪装成 macOS 上 Chrome 150–154 的机器人流量，这会改变分类，看起来像修补；同一 UA 在“检测到机器人信号”的流量中接受率反而上升。Linux 上的 Chrome 150–154 是例外，接受率继续下降，与进一步修补一致，但材料称这是暗示性而非结论性证据。按 ASN 看，大型网络中超过一半探测仍接受受损链，无论是否检测到机器人信号；周末后趋势平缓。

这段的核心不是“某个浏览器版本已修复”，而是修补在客户端侧分布极不均匀。嵌入式运行时、旧客户端和自动化软件都可能把弱链留在信任路径里。

开发者可核验的检查顺序（建议）#

以下是建议，不是材料中的强制步骤。顺序按“先定位信任路径，再换链，再监控”组织：

1. 盘点信任存储：列出出站 TLS 会使用的信任存储：操作系统、语言运行时、容器基础镜像、嵌入式 WebView、IoT 固件。确认是否仍信任 eMudhra 相关弱中间证书。具体指纹和版本覆盖待核实，应以各运行时官方公告为准。
2. 检查验证逻辑：确认出站连接执行主机名验证和链验证；不要为了“兼容”关闭验证。材料中约 160 次异常证书因 SAN 与 SNI 不匹配，本应被主机名验证拒绝。
3. 更新客户端：浏览器、运行时和嵌入式 WebView 分别更新；不要假设桌面浏览器更新会带动 Android WebView 或固件。
4. 更换服务端证书链：如果源站仍发送包含弱中间证书的链，即使客户端已更新，也可能影响未更新客户端；优先切换到不依赖弱中间的链。
5. 监控与回归：记录握手失败、证书链变化和异常 SAN；对长有效期证书和 IoT 默认证书做额外盘点。

Cloudflare 文中还建议 macOS 开发者参考 Dennis Jackson 的众包说明，并让使用 WARP 或 Tunnel 的客户查看其前一周博客；材料未给出这些地址，本文不补链接。

下面是一个未执行的示例，只用于查看服务端返回的证书链，不能检查客户端信任存储，也不能证明客户端是否仍接受弱链。环境为常见 OpenSSL 命令行；占位域名为 example.com：

openssl s_client -showcerts -connect example.com:443 </dev/null

该示例未在本机执行。实际排查时，应把域名换成自己的服务端，并人工核对链中的颁发者；不要根据单次输出推断所有客户端的行为。

为什么吊销与更新慢：信任存储不是静态列表#

材料把出路指向“可快速更新的信任存储”。Cloudflare 文中提到 upki 这类项目，认为信任存储不能只是一份静态的根 CA 列表，还需要能快速更新吊销信息和 CT 密钥信息。这个判断是方向性的：弱密钥事件里，私钥恢复和伪造证书几乎即时，而客户端要等系统更新、运行时更新、服务端换链和缓存刷新。时间差就堆在这些环节上。

对开发者来说，可操作的指标不是“漏洞公开后几天”，而是两个时间：从密钥公开到你的系统开始拒绝弱链；从弱链仍被接受到客户端完成更新。前者靠出站 TLS 策略和监控，后者靠资产盘点和更新分发。

边界#

材料没有给出 eMudhra 密钥生成脚本，审计和交叉签名角色的结论也待澄清；Cloudflare 的探测不能直接换算为全网暴露量；不同客户端版本的具体修补状态待核实。能确定的是：弱密钥一旦公开，利用门槛极低；修补追踪必须同时看服务端链、客户端信任存储和实际握手结果，不能只看某一个浏览器是否发布了更新。