Red Hat build of OpenJDK 21.0.7 发行注记
摘要
前言
Open Java Development Kit (OpenJDK)是 Java Platform, Standard Edition (Java SE)的一个免费的开源实现。红帽构建的 OpenJDK 有四个版本:8u、11u、17u 和 21u。
红帽构建的 OpenJDK 软件包在 Red Hat Enterprise Linux 和 Microsoft Windows 上提供,并作为红帽生态系统目录中的 JDK 和 JRE 提供。
提供有关红帽构建的 OpenJDK 文档的反馈
要报告错误或改进文档,请登录您的红帽 JIRA 帐户并提交问题。如果您没有红帽 JIRA 帐户,系统会提示您创建一个帐户。
流程
- 单击以下链接 来创建 ticket。
- 在 Summary 中输入有关此问题的简单描述。
- 在描述中提供问题或增强功能的详细描述。请包括有问题的文档 URL。
- 点 Create 创建并将问题路由到适当的文档团队。
使开源包含更多
红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。我们从这四个术语开始:master、slave、黑名单和白名单。由于此项工作十分艰巨,这些更改将在即将推出的几个发行版本中逐步实施。详情请查看 CTO Chris Wright 的信息。
第 1 章 红帽构建的 OpenJDK 支持政策
红帽在其产品中支持所选的 Red Hat build of OpenJDK 主版本。为了实现一致性,这些版本与指定为长期支持 (LTS) 的 Oracle JDK 版本类似。
自首次推出该版本时,红帽构建的 OpenJDK 的主版本将最少提供六年。如需更多信息,请参阅 OpenJDK 生命周期和支持政策
RHEL 6 于 2020 年 11 月结束其生命周期。因此,红帽构建的 OpenJDK 不支持 RHEL 6 作为支持的配置。
第 2 章 与上游 OpenJDK 21 的不同
Red Hat build of OpenJDK 在 Red Hat Enterprise Linux 中包含了来自 OpenJDK 上游发行版的许多结构更改。红帽构建的 OpenJDK 版本尝试尽快遵循 Red Hat Enterprise Linux 更新。
以下列表详细介绍了红帽构建的 OpenJDK 21 更改:
- FIPS 支持。红帽构建的 OpenJDK 21 会自动检测 RHEL 是否处于 FIPS 模式,并自动配置红帽构建的 OpenJDK 21 以在该模式下运行。此更改不适用于针对 Microsoft Windows 的红帽构建的 OpenJDK 构建。
- 加密策略支持。Red Hat build of OpenJDK 21 从 RHEL 系统配置获取启用的加密算法和密钥大小限制列表。这些配置组件由传输层安全(TLS)加密协议、证书路径验证和任何签名的 JAR 使用。您可以设置不同的安全配置集来平衡安全性和兼容性。此更改不适用于针对 Microsoft Windows 的红帽构建的 OpenJDK 构建。
-
src.zip
文件包含由红帽构建的 OpenJDK 附带的所有 JAR 库的源。 - Red Hat build of OpenJDK on RHEL 使用系统范围的时区数据文件作为时区信息的源。
- RHEL 上的红帽构建的 OpenJDK 使用系统范围的 CA 证书。
- Red Hat build of OpenJDK on Microsoft Windows 包括 RHEL 的最新可用时区数据。
- Red Hat build of OpenJDK on Microsoft Windows 使用 RHEL 的最新可用 CA 证书。
其他资源
第 3 章 Red Hat build of OpenJDK 功能
最新的 Red Hat build of OpenJDK 21 发行版本可能包括新功能。另外,最新版本可能会增强、弃用或删除来自以前红帽构建的 OpenJDK 21 版本的功能。
有关所有其他更改和安全修复,请参阅 OpenJDK 21.0.7 发行版本。
Red Hat build of OpenJDK 的改进
红帽构建的 OpenJDK 21 为最初在以前版本的 OpenJDK 中创建的功能提供了改进。
jarsigner
工具中关于删除的文件条目的警告
在以前的红帽构建的 OpenJDK 版本中,当从签名的 JAR 文件中删除文件时,但文件签名仍然存在,jarsigner
工具不会检测到这种情况。
在 OpenJDK 21.0.7 中,您可以使用 jarsigner -verify
命令检查每个签名是否有匹配的文件条目。如果存在不匹配,这个命令会打印警告信息。要显示任何不匹配条目的名称,请在命令中添加 -verbose
选项。
请参阅 JDK-8309841 (JDK Bug System)。
在 2025 年 4 月 15 日后发布的 TLS 服务器证书的不信任,由 Camerfirma 根 CA 发布
根据 Google、Mozilla、Apple 和 Microsoft 最近宣布的类似计划,红帽构建 OpenJDK 21.0.7 不信任于 2025 年 4 月 15 日之后发布的 TLS 证书,并由 Camerfirma root 证书发布。
Red Hat build of OpenJDK 将继续信任在 2025 年 4 月 15 日发布的证书,直到这些证书过期。
如果服务器的证书链由受影响的证书决定,则任何尝试协商 TLS 会话现在都会失败,但表明信任锚不被信任。例如:
TLS server certificate issued after 2025-04-15 and anchored by a distrusted legacy Camerfirma root CA: CN=Chambers of Commerce Root - 2008, O=AC Camerfirma S.A., SERIALNUMBER=A82743287, L=Madrid (see current address at www.camerfirma.com/address), C=EU
您可以使用以下 keytool
命令检查此更改是否影响 JDK 密钥存储中的证书:
keytool -v -list -alias <your_server_alias> -keystore <your_keystore_filename>
如果此更改会影响链中的任何证书,请更新此证书或联系负责管理证书的机构。
如果要继续使用 Camerfirma root 证书实现的 TLS 服务器证书,您可以通过修改 java.security
. properties
系统属性或从 jdk.security.caDistrustPolicies
安全属性中删除 CAMERFIRMA_TLS
。
继续使用不信任的 TLS 服务器证书的风险自有风险。
这些限制适用于红帽构建的 OpenJDK 构建的以下 Camerfirma 根证书,其中包括:
- 证书 1
- 别名名称: camerfirmachambers Businessca [jdk]
- 区分名称: CN=Chambers of Commerce Root OU=http://www.chambersign.org O=AC Camerfirma SA CIF A82743287 C=EU
- SHA256: 0C:25:8A:12:A5:67:4A:EF:25:F2:8B:A7:DC:FA:EC:EE:A3:48:E5:41:E6:F5:CC:4E:E6:3B:71:B3:61:60:6A:C3
- 证书 2
- 别名名称: camerfirmachambersca [jdk]
- 区分名称:CCN=Chambers of Commerce Root - 2008 O=AC Camerfirma S.A.SERIALNUMBER=A82743287 L=Madrid (请参阅 www.camerfirma.com/address 的当前地址)C=EU
- SHA256: 06:3E:4A:FA:C4:91:DF:D3:32:F3:08:9B:85:42:E9:46:17:D8:93:D7:FE:94:4E:10:A7:93:7E:E2:9D:96:93:C0
- 证书 3
- 别名名称: camerfirmachambersignca [jdk]
- 可分辨名称:CN=Global Chambersign Root - 2008 O=AC Camerfirma S.A.SERIALNUMBER=A82743287 L=Madrid (请参阅 www.camerfirma.com/address 的当前地址)C=EU
- SHA256: 13:63:35:43:93:34:A7:69:80:16:A0:D3:24:DE:72:28:4E:07:9D:7B:52:20:BB:8F:BD:74:78:16:EE:BE:BA:CA
请参阅 JDK-8346587 (JDK Bug System)。
修复了 PKCS11 机制中有问题的 SunPKCS11 供应商检查的问题
在 OpenJDK 14 中,SunPKCS11 供应商引入了 传统机制 的概念。如果机制使用弱算法,供应商会决定这种机制是旧的,然后禁用它。
在早期版本中,此行为不灵活。例如,您无法覆盖旧的确定来启用禁用的机制。另外,即使未使用加密,使用签名的机制也会被视为旧的,因此如果有弱加密算法,则禁用它。同样,弱签名算法阻止使用机制作为加密或解密的密码。
红帽构建的 OpenJDK 21.0.7 通过引入 SunPKCS11 供应商的 allowLegacy
配置属性来解决这些问题。您可以通过将 allowLegacy
属性设置为 true
来覆盖旧的确定。此属性默认设置为 false
。
从这个版本以后,供应商还会在决定旧状态时考虑服务类型。现在,供应商只检查加密算法,并只检查签名。
第 4 章 与本发行版本相关的公告
以下公告包括了记录程序错误修复和 CVE 修复:
更新于 2025-04-30