返回

2026/10/30

浏览器数小时内即获保护，企业 Java 呢？LOGIQ 如何应对 eMudhra 证书事件

浏览器在数小时内拦截了遭泄露的 eMudhra 中间证书，但每个 JDK 都自带信任库。本文介绍 Azul 和 BellSoft 发布的修复、LOGIQ 的应对措施以及您现在应检查的内容。

要点速览

  • 2026 年 10 月 17 日，Mozilla 收到报告称，eMudhra 的八张中间 CA 证书的私钥已遭泄露。各浏览器在数小时到数天内拦截了这些证书。eMudhra 表示，目前未发现任何证据表明这些密钥已被利用。
  • Java 不使用浏览器或操作系统的信任决策。每个 JDK，以及每个捆绑了 JDK 的容器镜像或应用程序，都带有自己的信任库，并且每一个都需要单独更新。
  • Azul 于 10 月 21 日和 10 月 24 日先后发布了两次计划外的 Zulu 更新。之所以有第二次更新，是因为第一次修复并不充分，因此仅靠 10 月 21 日的临时解决方案已不再足够。
  • BellSoft 列出了适用于 Java 8、11、17、21、25 和 27 的已修复 Liberica 版本。LOGIQ 已通过 BellSoft 支持渠道获取这些版本，并向客户提供。
  • 应对措施：找出您运行的每一个 Java 运行时，核实确切的供应商和版本号，升级到该供应商的已修复版本，测试 TLS 连接，并持续关注计划外发布。

事件经过

2026 年 10 月 17 日（星期六）UTC 20:06，Mozilla 收到报告称，eMudhra 的八张中间证书的私钥已遭泄露。Mozilla 通过其集中式吊销列表 OneCRL 在 Firefox 中拦截了这八张证书，到 UTC 22:59，即不到三小时后，该更新已推送到使用标准设置的用户。Mozilla 于 10 月 20 日公开披露了此事件。Mozilla 还为设置阻止了 OneCRL 更新的用户发布了 Firefox 小版本更新，并从 NSS 信任库中移除了签发这些中间证书的根证书。

风险在于证书伪造。持有其中任一密钥的人都可以为自己并不控制的网站签发 HTTPS 证书。如果攻击者还能介入客户端与该网站之间的通信，就可以冒充该网站，读取或篡改流量。

目前尚无证据表明发生过这种情况。eMudhra 在其事件声明中表示，这八张中间证书已于 10 月 18 日吊销，它们均未签发过任何终端实体证书，并且“未发现任何证据表明在问题披露之前，有人恢复或利用了这些弱密钥”。eMudhra 将原因描述为 2025 年一次密钥仪式中生成的弱密钥。该公司表示尚未确认确切的根本原因，调查仍在进行中。出于预防考虑，各浏览器根证书计划已不再信任这些中间证书上级的 eMudhra 根证书。

因此，本文关注的是如何关闭暴露窗口，而不是一次已确认的攻击。

为什么 Java 需要单独修复

浏览器和操作系统具备停止信任某个证书颁发机构的自动机制，而且这次都迅速启用了。根据 Azul 对此事件的描述，Chrome 在同一天拦截了这些证书，Apple 在 10 月 19 日、Microsoft 在 10 月 20 日相继跟进。

Java 不会继承上述任何措施。JDK 根据自身的文件来决定信任哪些证书：

  • 自带信任库。每个 JDK 都自带 cacerts 文件。更新操作系统的证书包或重启浏览器都不会改变它。
  • 默认不检查吊销状态。正如 Azul 的文档所述，Java 信任这些中间证书所链接到的根证书，并且“默认不检查吊销状态”。仅凭 eMudhra 吊销了这些中间证书，并不能保护 Java 客户端。
  • 副本众多。一台服务器上可能同时运行系统 JDK、应用程序内捆绑的 JDK、jlink 运行时以及多个容器镜像，每一个都有自己的信任库副本。在更新或重新构建之前，每个副本都持续处于暴露状态。

因此，即使公司里的每个浏览器都已受到保护，一个发起出站 TLS 调用的 Java 服务仍可能接受伪造的证书。这正是本文要讨论的缺口。

Azul 的两次紧急更新

Azul 在其 10 月季度发布之后，又为 Azul Zulu 发布了两次计划外更新：

  • 10 月 21 日：第一次计划外更新将这八张遭泄露的中间证书加入 JDK 的阻止列表（JDK 11 及更高版本中为 blocked.certs，旧版本中为 blacklisted.certs）。该更新涵盖 Zulu 27、25、21、17、11、8、7 和 6。Azul 的 CVE 列表将其记录为 CVE-2026-91403。对于无法立即更新的运行时，Azul 还发布了一个替换阻止列表文件的手动临时解决方案。
  • 10 月 24 日：Azul 发现阻止列表并未完全解决问题。第二次计划外更新通过从 cacerts 中彻底移除某些 CA 证书，修复了 CVE-2026-114820（JSSE，基础评分 9.1）。截至撰写本文时，这些版本已面向 Azul 仅含安全修复的 CPU 产品线提供，包括基于 2026 年 10 月 CPU 的版本（例如 Zulu 21.53.114、17.69.114、11.91.114 和 8.97.0.112）以及基于 2026 年 7 月 CPU 的版本。Azul 表示，PSU 版本“很可能”会在单独的更新中跟进。

10 月 24 日的更新改变了此前的建议。Azul 的临时解决方案页面现已警告该方案“已无法完全解决问题”，Azul 要求所有客户更新到最新版本。如果您已应用 10 月 21 日的更新或临时解决方案，仍然需要安装 10 月 24 日的版本。Azul 在其自己的文章中表示，从决定重新构建到将仅含安全修复的版本交付给客户，大约用了 12 小时。

BellSoft 为 Liberica JDK 发布了什么

BellSoft 于 10 月 21 日发布了常规的 2026 年 10 月 Liberica JDK 版本。该季度版本列出了 52 个已修复的 CVE，并包含 Java 6 和 7 的 CPU 版本（6u521 和 7u521）。其发布说明并未涉及 eMudhra 问题。

BellSoft 在另一篇指南《在 Java 中停止信任遭泄露的 eMudhra 中间证书》（最后更新于 10 月 27 日）中介绍了 eMudhra 问题。该指南列出的已修复版本为 Liberica JDK 8u513+9、11.0.33.0.3+7、17.0.21.0.3+5、21.0.13.0.3+5、25.0.5.0.3+5 和 27.0.1.0.3+5。对于暂时无法更新的系统，该指南给出了一项临时缓解措施：从信任库中移除受影响的根证书。指南警告称，这可能会破坏合法的证书链，应先进行测试。

比较不同供应商时，有两点值得注意：

  • CVE 列表并不相同。Azul 和 BellSoft 各自发布 10 月周期的 CVE 列表，数量和说明都有所不同。上文提到的两个 Azul CVE 编号来自 Azul 的记录，BellSoft 的指南并未引用它们。请查阅您所用供应商的发布说明，确认您的版本中包含的确切修复，不要假设某个供应商的列表适用于另一个供应商的 JDK。
  • Java 6 和 7 不在 BellSoft 的 eMudhra 列表中。BellSoft 已提供最新的 Java 6 和 7 版本，但其 eMudhra 指南中的已修复版本列表从 Java 8 开始。如果您运行的是 Liberica 6 或 7，请在依赖它之前先询问您的版本是否包含信任库变更，或者采用供应商提供的缓解措施。Azul 列出了适用于 Zulu 6 和 7 的 10 月 24 日版本。

LOGIQ 的应对措施

我们向客户分发来自 BellSoft 和 Azul 的 Java 版本，并帮助客户从旧版 Oracle JDK 迁移。以下是我们采取的措施，以及截至撰写本文时（10 月 29 日）各项的状态。

已完成

  • 10 月 21–22 日：审阅供应商通知。我们收到并审阅了 Azul 10 月 21 日的计划外更新通知以及 BellSoft 的 2026 年 10 月版本通知，并于当天为两家供应商分别创建了下载和存储库任务。我们将两次发布分开处理，没有假设 BellSoft 的季度版本包含与 Azul 相同的 eMudhra 修复。
  • 10 月 23 日：准备 Liberica 季度版本。我们从 BellSoft 支持门户下载了 2026 年 10 月的 Liberica JDK 版本，并将其添加到客户下载所用的存储库中。
  • 10 月 24–25 日：跟进 Azul 第二次更新。我们获取了 Azul 10 月 24 日的通知，其中包括即使已安装 10 月 21 日版本也应更新的建议。
  • 10 月 27–28 日：通过 BellSoft 获取已修复的 Liberica 版本。我们通过商业支持关系，请 BellSoft 在我们的支持门户上提供最新版本。BellSoft 于 10 月 28 日上传了这些版本，包括 Java 8、11、17、21、25 和 27 的已修复版本以及最新的 Java 6 和 7 版本。由于部分客户仍需要 32 位 Java 8，我们还请 BellSoft 将适用于 Windows 和 Linux 的 32 位 8u513+9 安装程序添加到我们的门户，BellSoft 当天即完成添加。
  • 10 月 28–29 日：更新存储库和迁移对应关系。我们将这些版本添加到客户下载存储库，并更新了 Oracle JDK 到 Liberica 的迁移指南，使其指向这些版本，该更新经过了第二名工程师的审核。

Azul Zulu 客户

Azul 订阅用户可以通过 Azul 获取其 10 月 21 日和 10 月 24 日的版本。合适的版本取决于您的 Java 版本、您使用的是 CPU 还是 PSU 产品线，以及所基于的基线（10 月或 7 月）。请查阅 Azul 的发布说明确认您的确切版本，或者联系我们，我们将帮助您确定。

旧版 Java 6 和 7

部分客户仍在运行 Java 6 或 7，通常用于难以快速迁移的应用程序。Oracle 已不再为这些版本提供公开更新，但这并不意味着别无选择。我们帮助客户从旧的 Oracle JDK 6 和 7 版本迁移到最新的 Liberica JDK 6 和 7 版本，而且我们可以通过 BellSoft 支持门户获取 BellSoft 针对这两个版本的 2026 年 10 月版本。当这些版本缺少我们所需的修复或软件包时，我们会通过商业支持渠道向 BellSoft 提出升级请求。关于此次事件，请参阅上文说明：在依赖您的 Java 6 或 7 版本之前，请确认其包含 eMudhra 信任库变更。

您现在应该做什么

1. 找出每一个 Java 运行时

列出所有运行 Java 的位置，而不仅仅是系统 JDK。这包括应用服务器、供应商产品中捆绑的运行时、jlink 镜像、CI 构建代理以及每一个容器镜像。在 Linux 上，以下命令可以查找主机上的 Java 可执行文件：

find / -xdev -type f -path "*/bin/java" 2>/dev/null

对于容器镜像，请在镜像内部运行检查，例如 docker run --rm --entrypoint java <image> -version。

2. 核实确切的供应商和版本号

仅知道主版本号是不够的。您需要供应商和完整的版本号，才能与供应商的已修复版本列表进行比对：

java -XshowSettings:properties -version 2>&1 | grep -E "java.vendor =|java.runtime.version|java.home"

作为快速判断，您还可以列出运行时信任库中的 eMudhra（emSign）根证书：

keytool -list -keystore "<java.home>/lib/security/cacerts" -storepass changeit | grep -i emsign

在我们使用 BellSoft 公开容器镜像进行的测试中，较旧的 Liberica 21.0.10 版本列出了五个 emSign 根证书，而已修复的 21.0.13.0.3+5 和 8u513 版本则一个也没有列出。结果为空是个好迹象，但不能作为证明。例如，Azul 10 月 21 日的修复拦截了中间证书，但并未移除根证书。版本号才是可靠的检查依据。我们此前关于检查 Java 信任库的文章介绍了更详细的检查方法。

3. 获取最新的适用补丁

  • Azul Zulu：升级到适用于您产品线（CPU 或 PSU，10 月或 7 月基线）的 10 月 24 日计划外版本，即使您已安装 10 月 21 日的版本或已应用临时解决方案。如果您使用的是 PSU 版本，请关注 Azul 后续的 PSU 发布。
  • Liberica JDK：升级到 BellSoft 列出的已修复版本（8u513+9、11.0.33.0.3+7、17.0.21.0.3+5、21.0.13.0.3+5、25.0.5.0.3+5、27.0.1.0.3+5）。
  • 其他供应商和捆绑的运行时：请查阅该供应商的安全公告。第三方产品中的 JDK 由该产品的供应商负责更新，而不是通过操作系统更新。
  • 容器：基于已修复的基础镜像重新构建镜像并重新部署。修补正在运行的容器并不会改变镜像。

4. 在部署前和部署过程中验证 TLS

从信任库中移除根证书可能会破坏合法连接，例如连接到仍在使用链接至已移除 eMudhra 根证书的证书的网站。eMudhra 表示，正在从另一个 CA 层级为受影响的客户重新签发证书。在大范围部署之前，请测试应用程序所依赖的出站 TLS 连接，尤其是连接到可能使用 eMudhra 证书的合作伙伴或服务的连接。请分阶段部署，重启 Java 进程以加载新的信任库，并在之后确认正在运行的版本。

5. 关注计划外发布

此次事件在四天内催生了两次 Java 紧急发布，后续可能还会有更多，例如 Azul 的 PSU 版本。请订阅供应商的安全通知，直接查看其发布页面而不是仅依赖电子邮件，并为季度计划之外的 Java 更新做好准备。

经验教训

Firefox 用户在数小时内就得到了保护，因为浏览器拥有自己的信任库和自动更新机制。而企业 Java 有众多信任库，默认不检查吊销状态，更新还要等人来安装。要弥补这一缺口，需要准确的资产清单、确切的版本号、快速获取供应商版本的渠道，以及不必等待下一次季度补丁的流程。如果您需要帮助查找或更新环境中的 Java 运行时，请联系 LOGIQ。

参考资料