RELEASE NOTES: JDK openjdk8u452

Distrust TLS Server Certificates Anchored by Camerfirma Root Certificates and Issued After April 15, 2025

The JDK will stop trusting TLS server certificates issued after April 15, 2025 and anchored by Camerfirma root certificates, in line with similar plans announced by Google, Mozilla, Apple, and Microsoft.

TLS server certificates issued on or before April 15, 2025 will continue to be trusted until they expire. Certificates issued after that date, and anchored by any of the Certificate Authorities in the table below, will be rejected.

The restrictions are enforced in the JDK implementation (the SunJSSE Provider) of the Java Secure Socket Extension (JSSE) API. A TLS session will not be negotiated if the server's certificate chain is anchored by any of the Certificate Authorities in the table below and the certificate has been issued after April 15, 2025.

An application will receive an exception with a message indicating 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" `

The JDK can be configured to trust these certificates again by removing "CAMERFIRMA_TLS" from the jdk.security.caDistrustPolicies security property in the java.security configuration file.

The restrictions are imposed on the following Camerfirma Root certificates included in the JDK:

You can also use the keytool utility from the JDK to print out details of the certificate chain, as follows:

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

If any of the certificates in the chain are issued by one of the root CAs in the table above are listed in the output you will need to update the certificate or contact the organization that manages the server.

Jarsigner Should Print a Warning If an Entry Is Removed

If an entry is removed from a signed JAR file, there is no mechanism to detect that it has been removed using the JarFile API, since the getJarEntry method returns null as if the entry had never existed. With this change, the jarsigner -verify command analyzes the signature files and if some sections do not have matching file entries, it prints out the following warning: "This JAR contains signed entries for files that do not exist". Users can further find out the names of these entries by adding the -verbose option to the command.

Support for Time Zone Database 2024b

IANA Time Zone Database has been upgraded to 2024b. This version mainly includes changes to improve historical data for Mexico, Mongolia, and Portugal. It also changes one timestamp abbreviation, for the time zone 'MET'. Also Asia/Choibalsan is now an alias for Asia/Ulaanbaatar.

The new tzdata changes also impact some legacy zone IDs. Mapping of EST/MST/HST in java.time.ZoneId.SHORT_IDS have changed from fixed offset zones to links to other existing time zones with 2024b. "EST" now links to "America/Panama", "HST" links to "Pacific/Honolulu" and "MST" links to "America/Phoenix". Parsing of the short zone names "EST", "MST", and "HST" is not affected by this change. Further details are available at JDK-8340138

Support for Time Zone Database 2024b

IANA Time Zone Database has been upgraded to 2024b. This version mainly includes changes to improve historical data for Mexico, Mongolia, and Portugal. It also changes one timestamp abbreviation, for the time zone 'MET'. Also Asia/Choibalsan is now an alias for Asia/Ulaanbaatar.

The new tzdata changes also impact some legacy time zone IDs. As per 2024b changes "EST" links to "America/Panama", "HST" links to "Pacific/Honolulu" and "MST" links to "America/Phoenix". To maintain compatibility with the Java SE specification, the java.time.ZoneId.SHORT_IDS Map has not changed. Further details are available at JDK-8342331