私钥就是数字 4：扒一扒这场把一家 CA 直接送走的事故

2026 年 10 月 17 日，周六。晚上 8 点，Mozilla 的安全团队收到一封报告邮件。不到 3 小时后，全球所有标准配置的 Firefox 已经把出事的 8 张中间证书全部拉黑。

而这次事故的起点，魔幻到不像真的：一家持牌 CA 的 8 把"公章"私钥，弱到其中一把的私钥就是数字 4。

作为一个前端，你可能觉得"CA、证书链、PKI"这些词都是运维大哥的领地。但这场事故最扎心的地方恰恰是：浏览器用户毫发无损，而 curl、pip、node、CI 流水线这一整套我们每天在用的工具链，理论上可以被随便伪造的证书骗得团团转。

这篇文章我会把这件事从头到尾讲清楚：发生了什么、为什么会发生、为什么浏览器没事、以及前端 er 到底该做什么。全文不烧脑，放心食用。

一、30 秒版本：到底发生了什么

印度 CA 厂商 eMudhra 有 8 张中间 CA 证书（DV / OV / EV / 代码签名各若干），这些"中间公章"能用来给任意网站签发 HTTPS 证书。
这 8 张证书的私钥在数学上是残废的 ：应该是 384 bit 的随机数，实际上前面 47 个字节全是 0，有效熵只有 8 bit ------一共 256 种可能，笔记本上一毫秒穷举完。换句话说，这些私钥等于公开。
从 2025 年 4 月这些证书诞生，到 2026 年 10 月事发，这个状态持续了 17 个月，波及约 6000 张已签发的证书。
幸运的是没人大规模利用（至少目前调查是这么说的）。各大浏览器、操作系统、运行时在几天内完成了封杀，eMudhra 直接官宣退出全球 SSL/TLS 证书业务。
名场面：一家 CA 公司，因为自家中间证书的私钥弱到"是一个个位数"，被整个行业物理送走。2026 年最大的 PKI 连续剧，完结撒花。

下面咱们把细节掰开。

二、3 分钟热身：浏览器凭什么相信一个网站

先补一点前置知识，懂 PKI 的同学可以直接跳到第三节。

你访问 https://juejin.cn，浏览器怎么知道对面真的是掘金，而不是隔壁宿舍哥们用 Charles 挂的假站？靠的是一套信任链：

把证书体系想象成办证：

根 CA 相当于"公安部制章厂"------离线锁进金库，几十年不联网，只干一件事：给中间 CA 发证。浏览器和操作系统出厂时，会内置一份可信根 CA 名单（Trust Store），名单里有谁，谁说的话就算数。
中间 CA 相当于"各地办证大厅"，日常给网站批量发证书。eMudhra 就是一家全球知名的"办证大厅连锁"。
你的网站证书相当于网站的"身份证"。浏览器验证时沿着链条逐级核对签名，最终锚定到名单里的某个根。

所以整条链的安全，系在每个环节的私钥（公章） 上。谁的公章丢了，谁就能以"官方认证"的名义给任意网站办出真身份证------这就是中间人攻击的完美前置条件。

eMudhra 这次的问题不是公章"被偷"，而是更离谱的情况：公章本身是随便谁都能刻出来的。

三、事故还原：8 bit 的"公章"

先看一组对比，这是整场事故的核心：

eMudhra 的这 8 张中间证书都声称自己是 P-384 椭圆曲线密钥。正常的 P-384 私钥是一个 384 bit 的随机大数，取值空间约 10^115，比可观测宇宙的原子总数还多。而 eMudhra 的私钥长什么样呢？前面 47 个字节全是 0x00，最后一个字节是随便一个小数字------有效熵 8 bit，一共 256 种可能。

安全研究员 Scott Helme 在事件披露后独立验证了一把：把 8 把私钥全部穷举出来，每把都在一毫秒以内 破解。他后来还发现，让 AI 智能体来干这活，一个 prompt 就把全部私钥算回来了。

最阴险的地方在于：私钥为 4 所对应的公钥，在椭圆曲线上是一个完全合法的点 。所有标准校验------格式检查、曲线验证、签名验算------全部通过。想发现问题只有一个笨办法：真的去把 256 种可能试一遍。所以这些证书在 17 个月里安安稳稳地通过了所有审计。

事后 eMudhra 在 Mozilla 的事故工单里给出的解释是：密钥生成仪式（key ceremony）的脚本有 bug ，在 HSM（硬件加密机）里额外生成了一套弱密钥对，又因为两套密钥命名相似，人工操作时拿错了，把弱私钥对应的 CSR 交了上去。

安全圈常说"体系防不住人的失误"，这次是字面意义上的：硬件金库、加密机、多人在场见证的仪式，全套流程防住了所有外部攻击，最后败给了脚本 bug + 名字像。

顺便说个细节：这 8 张中间证书除了挂在 eMudhra 自家的 emSign 根下，还被 Sectigo 的 AAA Certificate Services 根交叉签名------那是一个 2004 年的老根，在各种老系统、老设备里信任度极高。等于事故半径直接翻倍。

四、72 小时闪电战，和一家公司的退场

事故的处置节奏，快得像提前彩排过（其实这就是浏览器的日常演练）：

划几个重点：

Firefox 的 OneCRL ：周六 20:06 收到报告，22:59 黑名单就推送到了全网用户的浏览器------从知悉到全球生效不到 3 小时，用户不需要升级、不需要重启。
Chrome 的 CRLSet 同一晚更新，随后确认将在 Root Store v43 中移除 eMudhra 根。
Apple 周一通过自动配置更新拉黑全部 12 张受影响中间证书（连系统都不用升级），周五追加拉黑 emSign 根证书本身。
Mozilla / NSS 周二直接从信任库里移除了 eMudhra 根。

然后是本剧大结局：10 月 22 日，eMudhra 官宣退出全球 SSL/TLS 证书业务，董事长表示这块业务"约占公司总收入的 1%"------好家伙，1% 的收入买走了整个行业的信任，这买卖亏麻了。

中间还穿插了不少名场面：

eMudhra 无视了 Mozilla 根证书项目的调查期限，对外甩锅"社交媒体炒作"。社交媒体：谢谢，是你家私钥是数字 4。
OpenJDK 在一个周六"随机（？）"移除了全部 eMudhra 根证书，动作快过大部分商业产品。
mitmproxy 发布 12.3 "eMudhra Edition"，新增 --emudhra 参数：直接用泄露的私钥签发假证书，没打补丁的客户端开箱即骗------开源社区用最扎心的方式给所有没更新的人上了一课。
有安全研究者顺手测了测 eMudhra 自家的登录系统，发现它的 1FA OTP 验证也能绕过。一边危机公关，一边自家门锁，全线失守。

五、最扎心的部分：为什么浏览器稳如老狗，命令行全体裸奔

如果你只看时间线，会觉得这事的观感是"浏览器厂商反应神速，虚惊一场"。但真相是：浏览器恰恰是这场事故里最不需要担心的人群。

浏览器有两大护体神功：

快速吊销机制------Firefox OneCRL、Chrome CRLSet、Apple 自动配置更新。黑名单像手机推送一样热更新，几小时内全球生效。
证书透明度（CT）强制------每张公开信任的证书都必须记录进公共的 CT 日志。伪造的证书没进日志，浏览器直接不认。攻击者就算造出假证书，也是"查无此人"。

而我们日常离不开的那些非浏览器客户端------curl、python、node、go、java、git、各种包管理器------用的是另一套逻辑：一份打包时刻的静态 CA bundle，默认不查吊销，不查 CT。bundle 打包那一刻信任谁，就一直信任谁，直到有人手动更新。

Scott Helme 用泄露的私钥伪造了一张 api.stripe.com 的证书做实测：

bash 复制代码

$ curl https://api.stripe.com
→ SSL certificate verify ok    # curl：完全信任

$ node -e "fetch('https://api.stripe.com')"
→ authorized: true             # Node：完全信任

在他测试的每台 Linux 和 macOS 机器上，curl 和 Node 都照单全收。Windows 上 CryptoAPI 同样放行，除非手动开启吊销检查------开了也只有两条验证路径中的一条报警。

想想这些场景意味着什么：

curl xxx | sudo bash 一键安装脚本（rustup、nvm、Homebrew 全是这套）：伪造证书 + MITM = 攻击者的代码以 root 身份进你电脑。
CI/CD 流水线：GitHub Actions runner 满身云密钥和部署凭证，而它信任的 CA bundle 藏在基础镜像里，几个月不更新。
pip / certifi、Java cacerts、Git for Windows：每个运行时都自带一套独立的信任库，更新系统 ≠ 更新它们。
IoT 设备 ：固件里的 CA bundle 冻结在出厂时刻，这些设备要一直信任被攻破的证书到 2039 年。
Windows 代码签名 ：这次连代码签名中间证书都泄露了。在不查吊销的 Windows 机器上，恶意软件可以带上"已验证发布者"的金标。

这次没出大事，纯粹是因为弱私钥没落到坏人手里过。运气不是安全体系的一部分。

六、前端 er 自救清单：六步完成排查

好了，看完热闹，轮到正事了。下面的清单按优先级排列，前面几步今晚就能做完：

第 1 步：先测自己

打开 Dennis Jackson 搭的自测站 emudhra.we-have-a-problem.com，它会尝试用被攻破的中间证书建立连接：连接失败（证书报错）= 你的客户端已经安全；能正常打开 = 还在信任坏证书。

注意一个坑：Electron 应用（Slack、Discord、各种 VS Code 插件宿主）要单独更新------它们用自带的 Chromium 和证书库，操作系统更新救不了它们。

第 2 步：查自家域名和公司服务的证书是谁签的

javascript 复制代码

# 查看目标站点证书的签发方
openssl s_client -connect yoursite.com:443 -servername yoursite.com </dev/null 2>/dev/null \
  | openssl x509 -noout -issuer

看到 eMudhra 或 emSign 字样，立刻进入战备状态。再去 crt.sh 搜一遍公司主域，确认没有历史遗留的证书。

第 3 步：中招就换 CA 重签，顺手把证书自动化

受影响的直接换 Let's Encrypt（免费）或可信 CA 重签，别犹豫。更重要的是把证书生命周期交给 ACME 自动化：

perl 复制代码

# acme.sh：签发 + 自动续期一步到位
curl https://get.acme.sh | sh -s email=my@example.com
acme.sh --issue -d yoursite.com --webroot /var/www/html && acme.sh --install-cert -d yoursite.com --reloadcmd "nginx -s reload"

第 4 步：更新本地 & CI 的 CA bundle，重建镜像

逐个过一遍：系统 ca-certificates、Python 的 certifi、Node 内置根证书、Git for Windows 自带的 bundle、Java 的 cacerts、Homebrew、rustup。Docker 基础镜像更新后要 rebuild 重发，不然容器里的世界还停留在事故前。这一步建议直接转给后端 / 运维同事，附上这张清单图。

第 5 步：严禁裸奔

NODE_TLS_REJECT_UNAUTHORIZED=0、curl -k、Python 的 verify=False、各种 skipVerify......这次伪造证书能骗过一堆工具，靠的就是"没人校验"。调试时用完就删，永远别让它进主干。同理，公司自建 MITM 代理（各家上网行为管理、抓包工具）装进系统信任库的 CA，也值得重新审视一遍。

第 6 步：面向未来------47 天证书时代已经在倒计时

CA/Browser Forum 的新规已经生效在途：2027 年 3 月起证书有效期上限 100 天，2029 年 3 月起 47 天。手动续期在这个节奏下必死无疑，ACME 自动化不是加分项，是入场券。再配一个 CT 日志监控盯紧自家域名的异常签发，双保险。

七、写在最后：信任是链式的，失效也是

有意思的是，就在这次事故一个多月前的 9 月，安全圈还在刷另一个瓜：有研究员把 Netscape 4.51 时代（1999 年）内置的两把 512-bit RSA 根 CA 私钥，用一台桌面电脑跑了 32 小时分解了出来------而 512-bit 在 1999 年当年就已经被公开分解过一次。

把两件事放在一起看，你会得到一个残酷的结论：信任链上的每一环，都会以自己的方式过期。1999 年的弱密钥活到了 2003 年，2025 年的弱密钥活到了 2026 年------技术的马甲在变，"以为没人会去试"的心态从来没变。

于我个人而言，这次事件带来的三个心智升级：

信任不是布尔值，是一条会腐烂的链。浏览器花了十几年建快速吊销 + CT，才换来 3 小时灭火的能力；而静态信任的东西，每一次"应该没问题"都在积累风险。
前端的工作不止于页面 。我们的 npm install、curl 脚本、CI 流水线，全站在信任链上------前端工程化做得越深，越要意识到自己也是供应链的一环。
自动化是唯一能跑赢熵增的手段。47 天证书、频繁的信任库更新、依赖镜像重建------全是"必须持续做"的事，人肉是扛不住的，能自动化的全自动化。

希望下次再看到"某 CA 出事"的热搜时，你已经知道该点开哪个网站自测、该敲哪条命令排查了。