十月的某个周末，一位安全研究员在家扫证书库，扫出八把 P-384 私钥。
其中一把的值是数字 4，另一把 56，还有一把 115。从公开证书里还原它们，用不到一秒——不是被攻破，是密钥短到可以当场数出来。知乎
这八张属于印度 CA 机构 eMudhra 的中间证书。中间证书像公证处的分所，拿到私钥，就能给任意域名签一张"真的"证书，github.com 也算。
浏览器反应很快：Chrome、Firefox 当天拉黑。苹果随后在 Safari、邮件这些系统框架里拦掉。微博
麻烦在于，Mac 有两套可信名单。
Safari 走苹果的网络框架，已经安全。可 /usr/bin/git、/usr/bin/curl、/usr/bin/python3 读的是另一个文件，/etc/ssl/cert.pem。
这份静态名单只认里面有没有对应的根证书，不查吊销。
到 10 月 28 日，系统自带工具仍然信任这批证书。名单里还留着 emSign ECC Root CA - G3 和 AAA Certificate Services 两张涉事根证书。知乎知乎专栏
用事件方公开的测试站点实测，macOS 15 上这三个工具全部中招。10 月 26 日推送的 macOS 27.2 没修，还把手动改过的 cert.pem 覆盖了回去。知乎专栏
要命的是场景。在公共 Wi-Fi、被劫持的 DNS 或恶意代理下，有人能冒充 github.com。你 clone 下来的可能是一段改过的代码，git push 时敲的 token 也会被截走。知乎
CI 里跑 macOS 构建机，一样中招。
目前没有发现被利用的迹象，但证书从去年四月签发到现在，已经过了一年半。
自查几十秒就够。先看文件里有没有那两张根证书：
```bash
grep -E “emSign ECC Root CA - G3|AAA Certificate Services” /etc/ssl/cert.pem
```
再用终端访问事件方的测试站点：
```bash
curl -sS -o /dev/null -w “%{http_code}n” https://dv-g3b-noct-emudhra.we-have-a-problem.com/
```
返回 200，说明 curl 认了伪造证书；报证书错误才算安全。断网或代理拦截也会显示连不上，别当成通过。
不想碰系统文件，可以做一份去掉这两张根证书的 CA 文件，让 git 用 http.sslCAInfo、curl 用 ~/.curlrc 指向它。
系统自带的 python3 不认 SSL_CERT_FILE，得在代码里显式传 cafile。
更省事的办法是换成 Homebrew 的 Python，再 brew upgrade ca-certificates——curl 官方 10 月 20 日的证书包已经删掉了这两张根。知乎
两个代价提前知道。删掉 AAA Certificate Services 可能让少数老站点报错。
公司内网 GitLab 若是自签证书，改完 sslCAInfo 可能连不上，需要先把公司根证书追进这份文件。
苹果的支持文档说，修复更新还没定日期。等它推送后跑一遍自查，全绿了就把自己加的配置撤掉，不然以后新增的根证书你这边会一直不认。微博
浏览器先安全，是因为它一直被盯着。那些默默读一份静态名单读了好些年的命令行工具，得你自己动手。
