Cloudflare在10月19日约17点（UTC）察觉，8张eMudhra中间证书的私钥已经泄露。这些证书被浏览器和操作系统广泛信任。密钥强度不足，拿到它就能为任意域名签出被信任的证书，中途读取或改写加密流量。
证书链是这样搭的：根证书预装在系统和浏览器里，根证书签发中间证书，中间证书再去签发具体站点的证书。分层是为了让根证书的私钥能离线保管，中间证书的私钥落到别人手里，等于拿到了替任意域名签证书的权限，不必去碰根证书。8张一起出问题，说明问题出在签发这一侧，不在某一个站点。受影响的不只是某一批域名，是所有走这条信任链的站点。这类证书外流，靠换自家的证书解决不了，要等信任库把这条链剔掉。
浏览器这一侧处理得快。主流浏览器自带快速吊销机制，Chrome用的是CRLSets，撤回一条记录就够，用户不必逐个升级。没有这套机制的服务器、容器和后台服务，只能靠人把补丁一个个装上去，风险主要落在后者，两边的处置时间差着几天到几周。
Cloudflare已经把CDN、开发者平台和Zero Trust产品侧的缓解措施部署完，Cloudflare One客户端和cloudflared也发了新版本。它明确说有一部分客户需要自己动手，尤其是自建源站的：用Full（strict）或Strict模式回源的，要检查源站证书和服务器配置；配了双向TLS的，要更新校验客户端证书的信任库。跑容器的，镜像里的证书信任库也要一并查，容器镜像往往自带一份独立的信任库。
客户端版本号是Android端2.5.6、iOS端1.12.16、桌面端2026.8.2115.0，命令行工具cloudflared要到2026.10.2。不升级等于继续信任一张私钥已经外流的证书。
开发者的坑不在SDK本身。证书校验可能由HTTP库、语言运行时、操作系统或者一份自定义信任配置来完成，只把SDK升到最新，底下的判断策略可能一点没变。升级后控制台冒出证书报错是正常的，正确的处理是继续找漏掉的那一层，把校验关掉等于把这次补丁想恢复的验证一起去掉了。
补完之后要按应用真实的TLS路径验证一遍，浏览器里打得开，不代表后台任务也安全。后台进程可能加载的是另一套信任库，只有按它自己的请求路径测一次才算数。信任库在浏览器里可以快速更新，在服务器上不行，后者只能靠版本号和依赖清单去核对。手里有自建服务、CI流水线和容器镜像的，这一轮要按清单扫一遍，扫完把结果记下来，下次同类事件能省一半时间。
申请创业报道，分享创业好点子。点击此处，共同探讨创业新机遇！
