Chrome 移除 eMudhra 根证书后网站证书报错怎么办

发表于 分类于
Chrome 已于 10 月 27 日上午（太平洋时间）移除 emSign ECC Root CA - G3，链到该根的网站证书在 Chrome 里失效。本文说明哪些发行方受影响、怎么用 openssl 自查、以及换证时该换到哪个信任体系。

本文依据以下来源整理，未实测换证全流程：Chrome 根证书移除的预期时间与受影响发行方来自 Convika 对 Google 公告的整理；Windows 带外更新的 KB 编号与适用范围来自 BleepingComputer 与 Pureinfotech 的报道。Xray 内核一侧的紧急更新本站已有另文，不在这里重复。

11 月 8 日核查更新：移除已完成——Chrome 于 10 月 27 日上午（太平洋时间）移除了该根，11 月 2 日 Chromium 源码里的根证书列表中已无 emSign ECC Root CA - G3；Google 未另发完成公告，结论以根证书列表本身为准。

先说结论：不是所有网站都会中招

这次 Chrome 移除的是一个根证书：emSign ECC Root CA - G3。只有证书链最终链到这个根的网站才会在 Chrome 里失效。Google 的原话是，链到该根的网站运营者必须立即从 Chrome 根证书库里的另一个 PKI 体系重新申请并安装证书。

Chrome 从证书透明日志里统计的数字是：该根上约有 30,800 张未过期预证书，其中 99.9% 来自两个 Internet2 / InCommon 中间证书。也就是说，受影响的面其实很集中，不是全网证书都出问题。

哪些发行方受影响，哪些不用动

按 Chrome 的统计对照自己证书上的发行方（Issuer）：

  • 受影响：InCommon Intermediate CA - OVG3C（23,806 张）、InCommon Intermediate CA - DVG3C（6,985 张）——这两家要换证。
  • 受影响：EM EV TLS CA - G3A-1、EM OV TLS CA - G3A-1、emSign ECC SSL CA - G3、emSign ECC EV SSL CA - G3、emSign TLS CA - G3（合计 18 张）——同样要换证。
  • 不受影响：发行方是 Let’s Encrypt 的证书，Let’s Encrypt 从自家 ISRG 根签发，不走这条链。
  • 不受影响：Cloudflare 自动证书，Cloudflare 证书机构页列出的发行方是 Let’s Encrypt、Google Trust Services 和 SSL.com，Sectigo 只作备用证书（该页最后更新于 2026 年 4 月 16 日）。

eMudhra 方面的说法是，影响局限于美国一个客户生态，并已从另一个独立运营的公开信任 CA 体系为该客户签发替换证书。换句话说，受影响的站长换证时要换体系，而不是在同一条链上重新签一张。

自查：两条命令看发行方和整条链

把下面命令里的域名换成自己的域名：

1
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -issuer

看输出里的 O= 和 CN=，对照上面那张表。再查整条链里有没有相关名字：

1
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | grep -i -E "emsign|emudhra|incommon"

没有输出，说明链里没有这些名字。但要注意：连接本身失败时也会什么都不输出，所以先跑第一条命令确认能正常拿到证书，再信第二条的空结果。浏览器里点地址栏左侧的锁形图标，也能看到同样的“颁发者”信息。

如果确认在受影响名单里，处理就是换证：从 Chrome 根证书库里的另一个 PKI 体系（例如 Let’s Encrypt）申请新证书、部署到服务器、重启 Web 服务使新证书生效。换完之后再用上面两条命令复查一遍，确认发行方已经变了。

访客端的变化：Windows 带外更新只针对断网机器

同一事件在 Windows 一侧的后续也发生在 48 小时内，站长向访客解释时用得上：

微软在 2026 年 10 月 26 日发布了带外更新，从 Windows 信任列表里移除 7 张与 eMudhra 相关的证书（6 张 eMudhra G3 根与 1 张 AAA Certificate Services 交叉签名）。对应关系是：Windows 11 24H2、25H2、26H2 用 KB5134133，26H1 用 KB5134134，23H2 用 KB5134130，Windows 10 21H2、22H2 用 KB5134125。

关键是适用范围：这些带外包是给收不到自动证书信任列表更新的机器准备的，也就是断网环境、连不上微软证书更新服务、或关掉了自动 CTL 更新的系统，包只在 Microsoft Update Catalog 提供。正常联网、自动更新开着的 Windows 设备会通过自动 CTL 更新拿到信任变化，不需要手动去装这些 KB。向访客解释时先说这一句，能省掉很多不必要的折腾。

两个容易误判的点

第一，时间口径。Google 给出的时间是“10 月 27 日星期二上午（太平洋时间）”，按北京时间换算就是 10 月 27 日深夜到 28 日凌晨；移除已经完成，11 月 2 日 Chromium 源码里的根证书列表中已无该根（Google 未另发完成公告）。各设备实际收到移除的时间以各自 Chrome 为准，遇到报错先按发行方自查，不要先假设是全网问题或自己的服务器配置坏了。

第二，macOS 命令行工具的口径和浏览器不一样。苹果的支持页说，部分随 macOS 或 Xcode 命令行工具自带的 curl、git、python3 等工具对照 /etc/ssl/cert.pem 校验，在未来 macOS 更新之前仍可能接受这些证书。10 月 28 日的跟进还显示，macOS 27.2（10 月 26 日发布）会撤销用户手动删掉的 /etc/ssl/cert.pem 条目，命令行工具仍信任这些证书。用 Mac 上的 curl 自查时如果结果和 Chrome 不一致，先以浏览器和上面 openssl 查到的发行方为准，不要只凭 curl 的一次成功就断定证书没问题。

依据来源