印度 CA eMudhra 中间证书私钥可被还原：Sectigo 交叉证书已吊销，AAA 根并未整体失信

10 月中旬，独立安全研究员向 Chrome、Mozilla、Apple、Microsoft 等根存储项目报告：印度证书颁发机构 eMudhra（对外品牌 emSign）旗下 8 张中间 CA 的私钥存在密码学弱点，可从公开证书中还原。攻击者若掌握这些私钥，理论上可伪造任意网站的 HTTPS 证书，或签发代码签名证书。

eMudhra 已于 10 月 18 日以「CA 泄露」为由吊销相关中间证书；为这些中间 CA 提供交叉签名的 Sectigo，也于 10 月 19 日吊销了挂在 AAA Certificate Services 根下的 8 张交叉证书。主流浏览器已在数小时到数日内完成阻断。

需要先澄清一则流传较广的说法：并不是「Sectigo 的 AAA Certificate Services 根证书被整体取消信任」，而是「由该根签发、对应上述 8 个 eMudhra 中间 CA 的交叉证书」被吊销。其他正常挂在 AAA 根或其他 Sectigo 链路上的证书，并不因此自动失效；若你不确定自己的证书是否走了那几条交叉链路，应向签发方确认。

发生了什么

据 Mozilla 安全博客 与 oss-security 通告，Mozilla 于 2026 年 10 月 17 日 20:06 UTC 收到报告。不到 3 小时内，Firefox 通过 OneCRL 完成了对标准配置用户的阻断；Chrome 则以 CRLSet 阻断相同公钥指纹。Apple、Microsoft 随后也采取了阻断措施。Go 语言运行时亦在 1.27.3 / 1.26.10 中硬编码不信任这些中间 CA。

eMudhra 官方声明（持续更新至 10 月 21 日）称：问题出在 2025 年 4 月一次密钥生成仪式（KGC）中的 wrap/unwrap 步骤——在 FIPS 140-2 Level 3 HSM 上生成时，流程缺陷产生了一组较弱的密钥，且这组弱密钥被误用于创建 CSR 并提交给浏览器根计划；同一批请求也发给了 Sectigo 做交叉证书。8 张中间 CA 中 6 张用于 TLS（DV/OV/EV），2 张用于代码签名。eMudhra 表示，这些中间 CA 几乎未投入生产，且经内部与 Certificate Transparency 日志核对，均未向终端实体签发过任何证书。

关键事实对照

• 受影响主体：eMudhra / emSign 的 8 张中间 CA（G3B / G3C）
• 弱点性质：密钥生成仪式缺陷导致私钥可从公开证书还原（并非传统意义上的「服务器被入侵偷走私钥」）
• eMudhra 吊销：2026-10-18，原因 caCompromise
• Sectigo 交叉证书吊销：2026-10-19，仍由 AAA Certificate Services 签发的那 8 张交叉中间证
• AAA 根本身：未被各根计划整体移出信任库；「根被取消认证」的传言不准确
• 是否已有伪造终端证书：公开 CT 日志暂未见由这些中间 CA 签发的终端证书
• 浏览器端：Firefox OneCRL、Chrome CRLSet、Apple / Microsoft 阻断已落地
• 其他影响：部分根计划对 eMudhra 相关 ECC 根采取不信任或移除等额外措施；eMudhra 称主要影响其美国一侧某一客户生态，并在更换证书

交叉认证到底是什么意思

交叉认证是指：一张中间 CA 除了由自家根签发外，再由另一家已获广泛信任的根（这里是 Sectigo 的 AAA Certificate Services）签发一份「同名、同公钥」的中间证书。客户端只要信任其中任意一条链路，就会接受该中间 CA 签发的终端证书。

因此，当中间 CA 私钥本身不可信时，必须同时处理：eMudhra 自家根下的那 8 张中间证书，以及 Sectigo AAA 根下对应的 8 张交叉中间证书。

Mozilla 在写给各信任库维护者的通告中，列出了三条可能仍在使用的根链路（含 AAA Certificate Services、emSign Root TLS CA - G3、emSign ECC Root CA - G3），并说明：若客户端不能可靠做吊销检查，可考虑直接不信任这些根——但那是运维侧的防护选项，不等于「AAA 根已被全球取消认证」。贸然移除整棵根，还可能误伤该根下其他正常中间 CA 签发的站点。

谁需要立刻行动

• 使用 emSign / eMudhra 签发证书、或确认证书链里出现 EM * TLS/CS CA - G3B/G3C 名称的站点与软件发布方：联系 CA 换证，并核对链路上是否含 Sectigo 交叉证书。
• 自行维护信任库、嵌入式设备、旧容器镜像、不检查吊销且 fail-open 的客户端：对照 Mozilla / Chrome 阻断名单更新信任策略；Go 服务建议升到含硬编码阻断的小版本。
• 仅使用其他主流 CA、证书链不经过上述 8 个中间 CA 的用户：一般无需因「AAA 根传言」恐慌换证；若证书由代理商代管，仍可向签发方确认链路。

证书与 HTTPS 是域名上线后的标配。若你在泡米网管理域名，可用站内的 SSL 证书 选购，以及 域名工具 里的证书查看功能核对当前部署。

结论

这次事件的核心是「中间 CA 密钥生成仪式出错 → 私钥可被还原 → 中间证与交叉证必须一并吊销」，而不是「Sectigo AAA 根被整体踢出信任库」。对域名站长而言，正确动作是：查清自己的证书签发方与完整证书链，涉及 emSign 交叉链路的联系 CA 确认；浏览器用户多数已被自动保护。WebPKI 靠吊销、OneCRL/CRLSet 与根计划协作兜底——但自家站点的证书链路，仍要自己核对一遍。