# eMudhra 中间 CA 被攻破，各大浏览器紧急封禁

> 2026 年 10 月，谷歌、Mozilla 和苹果确认 eMudhra 多个子 CA 被攻破并予以封禁，同时处置 emSign ECC Root CA - G3 根证书。

Source: https://ssl.sh/zh/news/emudhra-compromised-intermediate-cas/
Last updated: 2026-11-10

2026 年 10 月，谷歌、Mozilla 和苹果先后确认，印度 CA 机构 eMudhra 的多张子 CA 证书已被攻破，三家都迅速采取了封禁措施。它们还对 emSign ECC Root CA - G3 根证书采取了行动；Chrome 也将在 2026 年 11 月 16 日之后不再信任 emSign Root CA - G1 下新签发的证书。谷歌于 10 月 20 日发文说明情况，并在 11 月 4 日更新。

## 发生了什么

Chrome、Firefox 和苹果平台在 2026 年 10 月 17 日至 19 日之间封禁了被攻破的[子 CA](https://ssl.sh/zh/glossary/subordinate-ca/)。各家的统计口径不同：谷歌的描述是 8 个；Mozilla 和苹果的描述是 6 个签发 TLS 证书的 CA，外加 2 个代码签名 CA。

| 日期 | 动作 |
|---|---|
| 2026-10-17 | Chrome 通过 CRLSet 封禁相关 CA；Mozilla 加入 OneCRL 条目 |
| 2026-10-19 | 苹果封禁相关证书 |
| 2026-10-20 | 谷歌发布说明，11 月 4 日更新 |
| 2026-10-23 | 苹果封禁 emSign ECC Root CA - G3 |
| 2026-10-27 | Chrome 移除 emSign ECC Root CA - G3 的变更推送到设备 |
| 2026-11-16 23:59:59 UTC（尚未到来） | 此后签发的 emSign Root CA - G1 证书不被 Chrome 153+ 信任 |

Mozilla 的处置还包括一次移除该根证书的 NSS 更新。Chrome 的 CRLSet 和 Firefox 的 OneCRL 都是浏览器自己的封禁机制，可以直接拉黑中间证书，不必等待 CA 自己的 [CRL](https://ssl.sh/zh/glossary/crl/) 生效。针对 emSign Root CA - G1 的这一步，用的是[证书透明度](https://ssl.sh/zh/glossary/certificate-transparency/)日志中 [SCT](https://ssl.sh/zh/glossary/sct/) 的时间戳来判断签发时间，这与 2024 年对 [Entrust 的不信任](https://ssl.sh/zh/news/entrust-distrust/)是同一种[不信任](https://ssl.sh/zh/glossary/distrust/)方式。

## 影响谁

证书链到 [eMudhra](https://ssl.sh/zh/cas/emudhra/) 根证书的网站、API 和 App 都受影响，分三种情况：

- **由被攻破的子 CA 签发的证书**：已被封禁，访客会看到 [NET::ERR_CERT_REVOKED](https://ssl.sh/zh/errors/net-err-cert-revoked/) 或 [NET::ERR_CERT_AUTHORITY_INVALID](https://ssl.sh/zh/errors/net-err-cert-authority-invalid/) 之类的错误。
- **emSign ECC Root CA - G3 下的证书**：在 Chrome 和苹果平台上已不再被信任。
- **emSign Root CA - G1 下的证书**：最早 SCT 早于截止时间的，目前在 Chrome 中仍可使用；截止时间之后签发的，在 Chrome 153 及以上版本中不被信任。

即使你自己没有使用 eMudhra 的证书，如果对接的海外合作方、支付或数据接口用了这家 CA 的证书，你的服务端调用同样可能失败。使用操作系统信任库的移动 App 和 API 客户端，会跟随所在平台的决定，需要和浏览器分开测试。

## 需要做什么

证书链里有 eMudhra 或 emSign 的，都要换成其他 CA 的证书。先检查证书链：

```bash
echo | openssl s_client -connect example.com:443 -servername example.com -showcerts 2>/dev/null \
  | grep -iE 'emsign|emudhra'
```

只要有输出，就应换成其他 CA 签发的证书并尽快部署。用[证书透明度查询](https://ssl.sh/zh/tools/ct-search/)列出为你的域名签发过的所有证书，避免某台被遗忘的主机还在用受影响的证书。再用 [CAA 生成器](https://ssl.sh/zh/tools/caa-generator/)写好 [CAA](https://ssl.sh/zh/glossary/caa/) 记录，只授权你实际在用的 CA，限制今后谁能为你的域名签发证书；国内用户可以直接在 DNSPod 或阿里云解析里添加 CAA 记录。本事件和更早的不信任事件都收录在[根证书计划时间线](https://ssl.sh/zh/timeline/root-program-changes/)中。