JDK 25 Early-Access Release Notes

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.

Some very old JMX System Properties have been removed. These were compatibility aids that were intended as transitional, for later removal. New behaviour will be the same as current behaviour with the property unset. The removals are:

jmx.extend.open.types which was provided to aid compatibility, since overriding javax.management.openmbean.OpenType.getClassName() was made illegal in JDK 6.

jmx.invoke.getters introduced in JDK 6 for compatibility with code which depended on previous incorrect behaviour, calling invoke on getters and setters.

jdk.jmx.mbeans.allowNonPublic which was introduced in JDK 8 for compatibility with previous incorrect behaviour where it was not enforced that MBean and MXBean interfaces must be public.

jmx.mxbean.multiname which was introduced in JDK 7 for compatibility with code which may have depended on previous incorrect behaviour relating to multiple registrations of an MXBean object.

jmx.tabular.data.hash.map which was for compatibility with JDK 1.3 clients due to use of LinkedHashMap.

jmx.remote.x.buffer.size as a System Property and a JMX environment property. The correct name was always jmx.remote.x.notification.buffer.size and was correct from JDK 6, but the alternate name was recognised to aid compatibility.

java.util.zip.Inflater and java.util.zip.Deflater now implement AutoCloseable and can be used with the try-with-resources statement. Applications could previously invoke the end() method to release the resources held by the Inflater/Deflater instance. Now, either the end() or the close() method can be invoked to do the same.

Starting with JDK 25, jpackage will no longer include service bindings for a run-time image that it creates. Prior to JDK 25, jpackage would include service bindings for run-time images. As a result, the generated run-time images produced by jpackage might not include the same set of modules as it did in prior versions.

The previous behavior can be achieved with jpackage of JDK 25 by adding the --bind-services jlink option to the default jlink options jpackage uses:

jpackage [...] --jlink-options 
   "--strip-native-commands --strip-debug --no-man-pages --no-header-files --bind-services"

TLSv1.3 and CNSA 1.0 algorithms have been added to the list of cryptographic requirements all Java SE implementations must support. All cryptographic algorithms that are needed to implement the TLSv1.3 cipher suites and signature mechanisms and that are defined by RFC 8446 as MUST or SHOULD requirements have been added. All algorithms that are required by CNSA 1.0 have also been added. No required algorithms or protocols are being removed at this time.

The following requirements have been added to the Security Algorithm Implementation Requirements section of the Java Security Standard Algorithm Names specification and to the class summary of each of the APIs below.

• AlgorithmParameters

  • ChaCha20-Poly1305
  • EC with secp256r1 or secp384r1 curves
  • RSASSA-PSS with MGF1 mask generation function and SHA-256 or SHA-384 hash algorithm

• Cipher

  • AES/GCM/NoPadding with 256 bit key size
  • ChaCha20-Poly1305

• KeyAgreement

  • ECDH with secp256r1 or secp384r1 curves
  • X25519

• KeyFactory

  • EC
  • RSASSA-PSS
  • X25519

• KeyGenerator

  • AES with 256 bit key size
  • ChaCha20

• KeyPairGenerator

  • DH with 3072 bit key size
  • EC with secp256r1 or secp384r1 curves
  • RSA with 3072 bit key size
  • RSASSA-PSS with 2048, 3072, 4096 bit key sizes
  • X25519

• MessageDigest

  • SHA-384

• Signature

  • RSASSA-PSS with MGF1 mask generation function and SHA-256 or SHA-384 hash algorithm
  • SHA256WithECDSA with secp256r1 curve
  • SHA384WithECDSA with secp384r1 curve
  • SHA384WithRSA

• SSLContext

  • TLSv1.3

The XML Signature implementation has been updated to Santuario 3.0.5. Support for four new SHA-3 based ECDSA SignatureMethod algorithms have been added: SignatureMethod.ECDSA_SHA3_224, SignatureMethod.ECDSA_SHA3_256, SignatureMethod.ECDSA_SHA3_384, and SignatureMethod.ECDSA_SHA3_512.