Chapter 2. Eclipse Temurin features


Eclipse Temurin does not contain structural changes from the upstream distribution of OpenJDK.

For the list of changes and security fixes that the latest OpenJDK 17 release of Eclipse Temurin includes, see OpenJDK 17.0.15 Released.

New features and enhancements

Eclipse Temurin 17.0.15 includes the following new features and enhancements.

Warnings from jarsigner tool about removed file entries

In earlier OpenJDK releases, when a file was removed from a signed JAR file but the file signature was still present, the jarsigner tool did not detect this situation.

In OpenJDK 17.0.15, you can use the jarsigner ‑verify command to check that every signature has a matching file entry. If any mismatch exists, this command prints a warning. To display the names of any mismatched entries, add the ‑verbose option to the command.

See JDK-8309841 (JDK Bug System).

Distrust of TLS server certificates issued after 15 April 2025 and anchored by Camerfirma root CAs

In accordance with similar plans that Google, Mozilla, Apple, and Microsoft recently announced, OpenJDK 17.0.15 distrusts TLS certificates that are issued after 15 April 2025 and anchored by Camerfirma root certificates.

OpenJDK will continue to trust certificates that are issued on or before 15 April 2025 until these certificates expire.

If a server’s certificate chain is anchored by an affected certificate, any attempts to negotiate a TLS session now fail with an exception to indicate that the trust anchor is not trusted. For example:

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

You can check whether this change affects a certificate in a JDK keystore by using the following keytool command:

keytool -v -list -alias <your_server_alias> -keystore <your_keystore_filename>

If this change affects any certificate in the chain, update this certificate or contact the organisation that is responsible for managing the certificate.

If you want to continue using TLS server certificates that are anchored by Camerfirma root certificates, you can remove CAMERFIRMA_TLS from the jdk.security.caDistrustPolicies security property either by modifying the java.security configuration file or by using the java.security.properties system property.

Note

Continued use of the distrusted TLS server certificates is at your own risk.

These restrictions apply to the following Camerfirma root certificates that OpenJDK includes:

Certificate 1
  • Alias name: camerfirmachamberscommerceca [jdk]
  • Distinguished name: 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
Certificate 2
  • Alias name: camerfirmachambersca [jdk]
  • Distinguished name: 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
  • 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
Certificate 3
  • Alias name: camerfirmachambersignca [jdk]
  • Distinguished name: CN=Global Chambersign Root - 2008 O=AC Camerfirma S.A. SERIALNUMBER=A82743287 L=Madrid (see current address at 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

See JDK-8346587 (JDK Bug System).

Fix for problematic SunPKCS11 provider checks on PKCS11 mechanism

In OpenJDK 14, the SunPKCS11 provider introduced the concept of legacy mechanisms. If a mechanism is using a weak algorithm, the provider determines that this mechanism is legacy and subsequently disables it.

In earlier releases, this behavior was inflexible. For example, you could not override the legacy determination to enable a disabled mechanism. Also, even if encryption was not being used, a mechanism that was being used for signing could be considered legacy and therefore disabled if it had a weak encryption algorithm. Similarly, a weak signing algorithm prevented use of the mechanism as a cipher for encryption or decryption.

OpenJDK 17.0.15 resolves these issues by introducing the allowLegacy configuration property for the SunPKCS11 provider. You can override the legacy determination by setting the allowLegacy property to true. This property is set to false by default.

From this release onward, the provider also considers the service type when determining legacy status. The provider now checks encryption algorithms only for ciphers and checks signature algorithms only for signatures.

See JDK-8293345 (JDK Bug System).

Fix for JNI_GetCreatedJavaVMs method returing a partially initialized JVM

In earlier OpenJDK releases, the Java Native Interface (JNI) method jint JNI_GetCreatedJavaVMs(JavaVM **vm_buf, jsize bufLen, jsize *numVMs) might have returned a virtual machine (VM) in the vm_buf array that was still being initialized.

OpenJDK 17.0.15 resolves this issue by ensuring that the JNI_GetCreatedJavaVMs method returns only fully initialized VMs.

Note

Before using the vm_buf array, ensure that the number of VMs returned in numVMs is greater than zero.

See JDK-8308341 (JDK Bug System).

Enhanced timeouts for OCSP, CRL, and certificate fetch

OpenJDK 17.0.15 introduces three new configuration properties that provide greater control over the timeouts for Online Certificate Status Protocol (OCSP) connections and certificate retrieval:

  • The com.sun.security.ocsp.readtimeout property specifies the timeout for reading OCSP data. This property is paired with the existing com.sun.security.ocsp.timeout property, which means that you can now set timeouts for reading OCSP data and for the transport layer independently of each other. If you do not specify a value for com.sun.security.ocsp.readtimeout, the JDK uses the value of com.sun.security.ocsp.timeout, as in earlier releases. The default value is 15 seconds.
  • The com.sun.security.cert.timeout property specifies the connection timeout for the download of certificates for certificate authorities. The default value is 15 seconds.
  • The com.sun.security.crl.readtimeout property specifies the timeout for reading certificate revocation list (CRL) data for the download of certificates for certificate authorities. The default value is 15 seconds.
Note

To enable certificate downloads, ensure that the com.sun.security.enableAIAcaIssuers property is set to true.

OpenJDK 17.0.15 also includes syntax improvements for all four timeout properties. The JDK still requires the value to be a positive decimal integer, but you can now append an optional suffix to indicate the unit: s for seconds, or ms for milliseconds. If you do not specify a suffix, the JDK interprets the value as seconds, as in earlier releases. If you specify anything other than a decimal digit before the suffix, the JDK rejects this value and uses the default value instead. The following are examples of invalid values: -5, 0xA, and 6.2.

See JDK-8179502 (JDK Bug System).

Revised on 2025-04-29 11:39:39 UTC

Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.