红帽全球峰会第 2 章 Eclipse Temurin 功能
Eclipse Temurin 不包含来自 OpenJDK 上游发行版的结构性更改。
有关 Eclipse Temurin 最新 OpenJDK 17 发行版本的更改和安全修复程序，请参阅 OpenJDK 17.0.15 发行版本。
新功能及功能增强
Eclipse Temurin 17.0.15 包括以下新功能和增强：
jarsigner 工具中关于删除的文件条目的警告
在之前的 OpenJDK 版本中，当从签名的 JAR 文件中删除文件时，但文件签名仍然存在，jarsigner 工具不会检测到这种情况。
在 OpenJDK 17.0.15 中，您可以使用 jarsigner -verify 命令检查每个签名是否有匹配的文件条目。如果存在不匹配，这个命令会打印警告信息。要显示任何不匹配条目的名称，请在命令中添加 -verbose 选项。
请参阅 JDK-8309841 (JDK Bug System)。
在 2025 年 4 月 15 日后发布的 TLS 服务器证书的不信任，由 Camerfirma 根 CA 发布
根据 Google、Mozilla、Apple 和 Microsoft 最近宣布的类似计划，OpenJDK 17.0.15 于 2025 年 4 月 15 日后发布的不信任 TLS 证书，并由 Camerfirma 根证书发起。
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 17.0.15 通过引入 SunPKCS11 供应商的 allowLegacy 配置属性来解决这个问题。您可以通过将 allowLegacy 属性设置为 true 来覆盖旧的确定。此属性默认设置为 false。
从这个版本以后，供应商还会在决定旧状态时考虑服务类型。现在，供应商只检查加密算法，并只检查签名。
请参阅 JDK-8293345 (JDK Bug System)。
修复 JNI_GetCreatedJavaVM 方法恢复部分初始化的 JVM
在之前的 OpenJDK 版本中，Java 原生接口(JNI)方法 jint JNI_GetCreatedJavaVM (JavaVM **vm_buf, jsize bufLen, jsize *numVM) 可能已在 vm_buf 数组中返回一个虚拟机(VM)。
OpenJDK 17.0.15 通过确保 JNI_GetCreatedJavaVM 方法仅返回完全初始化的虚拟机来解决这个问题。
在使用 vm_buf 数组前，请确保 numVM 返回的虚拟机数量大于零。
请参阅 JDK-8308341 (JDK Bug System)。
增强了 OCSP、CRL 和证书提取的超时
OpenJDK 17.0.15 引入了三个新的配置属性，它们对在线证书状态协议(OCSP)连接和证书检索的超时提供更大的控制：
-
com.sun.security.ocsp.readtimeout属性指定读取 OCSP 数据的超时时间。此属性与现有com.sun.security.ocsp.timeout属性配对，这意味着您现在可以为读取 OCSP 数据以及相互独立的传输层设置超时。如果您没有为com.sun.security.ocsp.readtimeout指定一个值，JDK 将使用com.sun.security.ocsp.timeout的值，如早期版本中所示。默认值为 15 秒。 -
com.sun.security.cert.timeout属性指定证书颁发机构下载证书的连接超时。默认值为 15 秒。 -
com.sun.security.crl.readtimeout属性指定读取证书颁发机构下载证书撤销列表(CRL)数据的超时时间。默认值为 15 秒。
要启用证书下载，请确保将 com.sun.security.enableAIAcaIssuers 属性设置为 true。
OpenJDK 17.0.15 还包括所有四个超时属性的语法改进。JDK 仍然需要值是一个正十进制整数，但您现在可以附加一个可选后缀来指示单位： s 代表秒，或 ms 代表毫秒。如果您没有指定后缀，JDK 会将值解析为秒，如早期版本中所示。如果您在后缀前指定了除十进制数字以外的任何内容，则 JDK 拒绝这个值并使用默认值。以下是无效值的示例：-5 ,0xA, 和 6.2。
请参阅 JDK-8179502 (JDK Bug System)。
更新于 2025-04-30
