The following root certificate from SECOM Trust System has been removed from the cacerts keystore:

+ alias name "secomscrootca1 [jdk]"

  Distinguished Name: OU=Security Communication RootCA1, O=SECOM Trust.net, C=JP

The following root certificate has been added to the cacerts truststore:

+ Certigna (Dhimyotis)

  + certignarootca
    DN: CN=Certigna Root CA, OU=0002 48146308100036, O=Dhimyotis, C=FR

In JDK 12, two new token options for the java.security.manager system property, "allow" and "disallow", were introduced.

Many applications and frameworks are designed to run on multiple JDKs. For those that enable the SecurityManager at runtime via System.setSecurityManager, they have to specify the "allow" option as of JDK 18 (see JDK-8203316). However, these applications would also prefer to use the same command line across multiple versions of the JDK, especially if it is not known what JDK version a user will use.

Currently, if these options are specified in JDK 12 or earlier, the runtime attempts to load a SecurityManager implementation with the classname "allow" or "disallow", which results in a Could not create SecurityManager Error and the application will not start up.

From this release onward, the "allow" and "disallow" options for the java.security.manager system property will be ignored.

The JDK implementation of TLS 1.2 now uses a default Diffie Hellman keysize of 2048 bits when a TLS_DHE cipher suite is negotiated and either the client or server does not support FFDHE, which can negotiate a stronger keysize. The JDK TLS implementation supports FFDHE and it is enabled by default.

As a workaround, users can revert to the previous size by setting the jdk.tls.ephemeralDHKeySize system property to 1024 (at their own risk).

This change does not affect TLS 1.3 as the minimum DH group size is already 2048 bits.