The JDK now encodes ML-KEM and ML-DSA private keys in PKCS #8 format using the DER-encoded ASN.1 CHOICE formats defined in Section 6, "Private Key Format" of RFC 9935 and Section 6, "Private Key Format" of RFC 9881. Two new security properties, jdk.mlkem.pkcs8.encoding and jdk.mldsa.pkcs8.encoding, control the encoding used when generating new keys with a KeyPairGenerator or when translating keys with a KeyFactory. Valid values are seed, expandedKey, and both (case-insensitive). If a system property of the same name is also specified, it supersedes the security property value. All three formats are supported when decoding previously encoded private keys with a KeyFactory.

When these algorithms were introduced in JDK 24, the encoding format was equivalent to the expandedKey value. This release changes the default value to seed. As a result, ML-KEM and ML-DSA private keys generated by this JDK release will not be accepted by older releases by default, although keys generated by older releases are still readable by this release. To enable older JDK releases to accept ML-KEM and ML-DSA private keys generated by this JDK release, set the jdk.mlkem.pkcs8.encoding or jdk.mldsa.pkcs8.encoding property (whichever property is relevant to your use case) to expandedKey, and use KeyFactory.translateKey to convert the key to the older format.

The following root certificates have been added to the cacerts truststore:

+ WISeKey

  + wisekeyglobalrootgbca
    DN: CN=OISTE WISeKey Global Root GB CA, OU=OISTE Foundation Endorsed, O=WISeKey, C=CH

+ WISeKey
  + wisekeyglobalrootgcca
    DN: CN=OISTE WISeKey Global Root GC CA, OU=OISTE Foundation Endorsed, O=WISeKey, C=CH

The DTLS implementation in the SunJSSE security provider has been enhanced to generate HelloVerifyRequest cookies as recommended by RFC 6347. To use this feature, applications must create the SSLEngine with the SSLContext.createSSLEngine(String peerHost, int peerPort) API.

The JFR event jdk.OldObjectSample is disabled when using generational ZGC.

The combination results in unacceptable performance overhead because the implementation relies on weak handles that, in generational ZGC, are processed only in the old generation.

A new system and security property, com.sun.security.crl.maxSize, has been added to limit the maximum length of a CRL that is downloaded through URIs in the CRL Distribution Points certificate extension during path validation. The value of these properties is the size in bytes of the DER-encoded CRL. For protocols that can return multivalue responses, such as LDAP, the size threshold is the sum of all CRLs downloaded from a single search query. CRLs that exceed this length will not be processed during certificate path validation. This size limit does not apply to CRLs that are imported through non-network-based means. A negative value disables this size limitation. A non-numeric value will be ignored, and the default size will be used instead. The default size limit is 20 MiB. For cases where both the security and system properties are set, the system property takes precedence. Enabling certificate path logging by setting java.security.debug=certpath will output the current size limit and note any discarded CRLs.