eMudhra 中级 CA 泄露事件：如何在您的环境中排查受影响的证书

浏览器中的每一个挂锁图标都依托于一条信任链，而这条信任链的强度取决于其中最薄弱的私钥。本月，这样一条链中的八个环节被发现是可以被猜测破解的。

今天是 2026 年 10 月 26 日。10 月 17 日，一名研究人员报告称，证书颁发机构（CA）eMudhra 旗下的八个中级证书的私钥可以被恢复。各大主流浏览器和操作系统厂商已吊销并屏蔽了这些证书。该问题分别以 CVE-2026-111943 和 CVE-2026-111944 进行追踪。本周安全团队的当务之急说起来简单做起来繁琐：查明您的环境中是否出现了这些证书，以及您的软件中是否仍有任何程序信任它们。

证书链快速回顾

当您通过 HTTPS 访问网站时，服务器会出示一个 叶证书 以代表其自身域名。该证书由一个 中级 CA签名，而该中级证书又由一个 根 CA签名。您的浏览器或操作系统自带一份其信任的根列表，称为 信任库.

根密钥保存在离线状态并受到严密保护。中级证书则负责日常的签名工作。问题在于，任何持有中级证书私钥的人都可以为任意名称签发证书，而信任该链的客户端通常都会接受它。这就是为什么即使尚未发现恶意证书，中级密钥泄露也是极其严重的。

事件经过（据报道）

根据公开披露和厂商通报，事情经过如下：

• 在 2025 年 4 月 30 日的一次密钥生成仪式中，eMudhra 为 24 个从属 CA 创建了密钥。
• 在密钥封装/解封（wrap/unwrap）步骤中的一个缺陷导致生成了第二组弱 P-384 密钥。P-384 是一种本应提供极大密钥空间的椭圆曲线。
• 这些弱密钥被错误地用于八个中级证书。据报道，它们的有效随机性（熵）仅约 3 到 8 位，这意味着最多只有几百种可能的密钥。用计算机恢复它们轻而易举。
• 这八个证书中有六个是 TLS 中级证书，两个是代码签名中级证书。

各方响应（同样据报道）：

• Chrome、Mozilla 和 Apple 屏蔽了这六个 TLS 中级证书。Microsoft 屏蔽了这两个代码签名中级证书。
• Google 从 Chrome Root Store 中移除了 emSign ECC Root CA - G3，Mozilla 也取消了对签署这些中级证书的根证书的信任。
• eMudhra 吊销了这八个证书，并停止在其 G3 根下签发证书。该公司声明其根私钥和其他中级证书未受影响，该问题仅限于其全球网站安全业务，而不影响其印度的 DSC 和 eSign 服务，且受影响的中级证书中仅有一个曾用于生产环境，均未向网站或终端用户签发过证书。

请将厂商的声明视为其单方面表述。您的工作不是评判该事件，而是确认自身是否存在风险暴露。

谁应该优先排查

如果您符合以下情况，应将此项排查列入高优先级事项：

• 运行面向互联网的网站、API、VPN 或其他 TLS 服务。
• 通过 eMudhra 或 emSign 层级购买公开受信任的证书。
• 分发依赖公开代码签名证书的已签名软件。
• 构建或运行用 Go 编写的应用程序。
• 维护遗留系统、未托管终端、网络设备或无法自动接收取消信任更新的自定义信任库。

八个受影响的中级证书

SHA-256 指纹和序列号是匹配证书最可靠的方法。名称可以仿冒，但指纹无法伪造。

证书	类型	序列号	SHA-256 指纹
EM EV TLS CA - G3B (eMudhra BV)	TLS	c7c41efe92d825f05eae841a4a82c1	E7568FE6E12331F4FD7DE61DA4C7559D0F8EB192A218D4741A3BA75184333838
EM OV TLS CA - G3B (eMudhra BV)	TLS	6cada367fb1c100088120ea202d568	98B896625C0C230ADEEC3EB2CF6AAD5001ECF9156A68644E82374CE5833BC25B
EM DV TLS CA - G3B (eMudhra BV)	TLS	a4aee678f23362b4c0e460b772f214	42C4ACCD12C4F59597925E1A08A7A90102608543809308D50EC427E118BA1493
EM EV TLS CA - G3C (eMudhra Inc)	TLS	8009928a64107601af05fa2f19f109	432EC25F0D28DE9006D97BF752F17BBB2CD41F669933FCB072D9A1148D0261F3
EM OV TLS CA - G3C (eMudhra Inc)	TLS	296926c227a3a1526392b19482a504	CB6E15165AC802E9B3F993F16C25D41F4E81C21EBDE71AE1B012AC00BF9C7C3F
EM DV TLS CA - G3C (eMudhra Inc)	TLS	588b2e3c2bb8cda13e1a1209254321	0164D7CEAE5BB909C272AF151FF44B1177AE9B47D9424B94F1D9558C30934D19
EM OV CS CA - G3B (eMudhra BV)	代码签名	7818933f8f85b4619a2b35fba83d0a	9E39DE2881273ACC225A149C72BA3E0F51424963669AB633EE1DC7DF5DB067B4
EM OV CS CA - G3C (eMudhra Inc)	代码签名	544b7f922c31ae220a4a922916f6e6	4B2460A466F95FD40113BCDCCA2CEB29B3B093921DE45474DA7DF48874C630B1

如何排查它们：分步检查指南

风险暴露有两个方面。一是您的服务器所出示的证书，二是您的软件当前仍信任的证书。以下步骤涵盖了这两个方面，首先介绍通用开源工具的使用，然后为已有商业扫描器的团队介绍商业扫描器的用法。

步骤 1：列出所有使用 TLS 的资产

未列出的资产是无法检查的。请整理您的公网域名、内部服务名称、负载均衡器、VPN 网关以及使用您域名的任何第三方托管站点。包括扫描器无法触及的服务器，例如远程员工的笔记本电脑和隔离网络。在主机上运行代理通常是发现这些资产的唯一方式。

步骤 2：检查每台服务器出示的证书链

对于任意单台主机，OpenSSL 可以输出证书链中的每个证书及其使用者、颁发者、序列号和指纹。请将 app.example.com 替换为您自己的主机：

HOST=app.example.com
echo | openssl s_client -connect "$HOST:443" -servername "$HOST" -showcerts 2>/dev/null \
  | awk '/-----BEGIN CERTIFICATE-----/{n++; f=1} f{print > ("chain-" n ".pem")} /-----END CERTIFICATE-----/{f=0}'

for f in chain-*.pem; do
  openssl x509 -in "$f" -noout -subject -issuer -serial -fingerprint -sha256
  echo
done

OpenSSL 输出大写序列号和带冒号的指纹，因此对比时无需在意大小写或冒号。与这八个证书列表快速匹配的方法如下：

for f in chain-*.pem; do
  openssl x509 -in "$f" -noout -fingerprint -sha256 | cut -d= -f2 | tr -d ':'
done | grep -i -E 'E7568FE6|98B89662|42C4ACCD|432EC25F|CB6E1516|0164D7CE|9E39DE28|4B2460A4' \
  && echo "MATCH: affected intermediate found" || echo "No affected intermediate in this chain"

前缀仅用于快速筛选。如果出现匹配项，在采取行动之前，请对照表格核对完整指纹。在您的主机列表上循环运行此命令即可进行基础排查。

步骤 3：如果您运行漏洞扫描器，可进行大规模检索

如果您的组织已在使用带有 Certificate View 的 Qualys VMDR，Qualys 已发布了现成的查询语句。在 Certificate View 中，针对颁发者名称进行搜索即可覆盖全部八个证书：

certificate:(issuer.name:[`EM EV TLS CA – G3B`, `EM OV TLS CA – G3B`, `EM DV TLS CA – G3B`, `EM EV TLS CA – G3C`, `EM OV TLS CA – G3C`, `EM DV TLS CA – G3C`, `EM OV CS CA – G3B`, `EM OV CS CA – G3C`])

更全面的检查可以列出在受影响中级证书中命名的两个 eMudhra 组织机构下签发的每个证书：

certificate:(issuer.organization:`eMudhra BV` or issuer.organization:`eMudhra Inc`)

Qualys 还列出了针对受影响 Go 版本的 QID 5019897 以及 QID 48395（一项枚举包含这八个中级证书的链的信息收集检查）。在依赖这些检查之前，请确保您的代理具备最新的签名。查询标记区分大小写，因此如果查询报错，请查阅产品帮助。其他扫描器也会有相应的等效功能；表格中的指纹适用于任何工具。

步骤 4：找出仍信任不良证书链的 Go 程序

这是人们容易忽略的部分。您的服务器可能是干净的，但您自己的应用程序可能仍会接受伪造的证书。根据安全公告，Go 1.27.3 和 1.26.10 屏蔽了包含这八个密钥中任意一个的证书链（CVE-2026-111943）。Go 程序内置了自身的证书验证代码，因此使用旧版 Go 构建的程序在重新构建之前会一直保留旧的行为。

检查构建机上的工具链：

go version

检查构建已在运行的二进制文件的 Go 版本：

go version /usr/local/bin/your-service

使用较旧版本构建的任何内容都应使用已修复的 Go 版本重新构建并重新部署。同时请应用操作系统厂商的更新，因为若干发行版会提供它们自己打过补丁的 Go 软件包。

步骤 5：替换、更新并保持监控

• 首先进行替换。 如果任何叶证书的链中包含这八个证书之一，都应由另一个受信任的 CA 重新签发，并使用正确的链重新部署。
• 进行更新。 应用操作系统安全更新，并将 Go 运行时升级到已修复的版本。
• 确认吊销检查正常工作。 吊销仅对实际执行检查的客户端有效。自定义信任库、专用设备以及旧版 Java 或嵌入式系统可能需要手动移除这些中级证书或显式取消对其的信任。
• 保持监控。 将您的搜索保存为计划任务或仪表板，并在每次扫描后重新运行，直到结果持续保持无异常。

结论

eMudhra 事件提醒我们，互联网上的信任取决于两件事：您出示的证书以及您选择信任的机构。修复方法并不繁复：列出您的 TLS 端点，对照八个已知指纹检查它们的证书链，使用已修复的工具链重新构建 Go 程序，并确保您的旧系统切实接收到了取消信任的设置。请在本周完成这些工作，并持续执行检查。

优势

• 受影响的证书是一个带有精确指纹的固定简短列表，因此匹配非常精准。
• 各大主流浏览器和操作系统已经屏蔽了它们，这会自动保护大多数日常用户。
• 诸如 OpenSSL 和 go version 等免费工具足以进行基础检查。
• 现有的扫描器可以将排查工作转化为可重复运行的仪表板。
• 本次排查能完善您的证书资产清单，以便应对未来的突发事件。

劣势

• 使用自定义或冻结信任库的系统在没有人工干预的情况下无法享受厂商黑名单的保护。
• Go 二进制文件必须重新构建；仅更新工具链无法修复已部署的程序。
• 网络扫描会遗漏无法触及的主机，因此需要代理覆盖或人工检查。
• 对于不进行吊销检查的客户端，吊销机制是不可靠的。
• 更换网络设备和第三方托管站点上的证书可能需要时间以及厂商的协助。

注意事项

本文仅供学习和通用指导。主机名如 app.example.com 以及路径如 /usr/local/bin/your-service 均为占位符，您必须将其替换为您自己的实际值。事件细节是根据上述日期的公开报告和厂商声明总结的，后续可能会有变动；请查阅来自您的浏览器、操作系统、Go 及扫描器厂商的最新公告，并在针对匹配项采取行动之前，对照权威来源核实每个指纹。

常见问题

• 什么是 eMudhra 中级 CA 泄露事件？ — 八个 eMudhra 中级证书是用弱 P-384 密钥生成的，其私钥可以被恢复，因此各大主流厂商于 2026 年 10 月吊销并屏蔽了它们。
• 哪些 CVE 用于追踪此问题？ — 该问题由 CVE-2026-111943 和 CVE-2026-111944 追踪；屏蔽受影响证书链的 Go 修复程序记录在 CVE-2026-111943 下。
• 印度的 DSC 和 eSign 证书是否受影响？ — eMudhra 声明该问题仅限于其全球网站安全业务，不影响其印度的 DSC 和 eSign 服务。
• 我该如何检查我的网站是否使用了受影响的中级证书？ — 使用 openssl s_client -showcerts获取证书链，打印每个证书的 SHA-256 指纹，并与上方列出的八个指纹进行比对。
• 为什么 Go 应用程序需要特别注意？ — Go 程序内置了自身的证书检查，因此必须使用 Go 1.27.3 或 1.26.10（或更新的已修复版本）重新构建，以拒绝受影响的证书链。
• 仅靠证书吊销是否足以确保安全？ — 并不总是如此，因为某些客户端从不检查吊销状态；自定义信任库和较旧的系统可能需要手动移除中级证书或显式取消对其的信任。
• 如果我发现了受影响的证书，该怎么办？ — 从另一个受信任的 CA 重新签发叶证书，使用正确的链重新部署，并重新扫描以确认旧链已被清除。
• 我可以使用漏洞扫描器来进行这项排查吗？ — 可以；诸如 Qualys Certificate View 等工具提供了按颁发者和序列号搜索的功能，任何记录证书指纹的扫描器也都可以匹配此处列出的八个指纹。

标签

#eMudhra #CertificateAuthority #TLS #PKI #CVE2026111943 #CyberSecurity #GoLang #VulnerabilityManagement #CodeSigning #Qualys