Chapter 4. Red Hat build of OpenJDK features
The latest Red Hat build of OpenJDK 21 release might include new features. Additionally, the latest release might enhance, deprecate, or remove features that originated from earlier Red Hat build of OpenJDK 21 releases.
For all the other changes and security fixes, see OpenJDK 21.0.7 Released.
Red Hat build of OpenJDK enhancements
Red Hat build of OpenJDK 21 provides enhancements to features originally created in earlier releases of Red Hat build of OpenJDK.
Warnings from jarsigner
tool about removed file entries
In earlier Red Hat build of 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 Red Hat build of OpenJDK 21.0.7, 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, Red Hat build of OpenJDK 21.0.7 distrusts TLS certificates that are issued after 15 April 2025 and anchored by Camerfirma root certificates.
Red Hat build of 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
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.
Continued use of the distrusted TLS server certificates is at your own risk.
These restrictions apply to the following Camerfirma root certificates that Red Hat build of 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.
Red Hat build of OpenJDK 21.0.7 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.