RMI will use TLS connections if the javax.rmi.ssl.SslRMIClientSocketFactory class is used. These connections now have TLS endpoint identification enabled by default. This may cause some previously-working TLS connections to fail. If this occurs, ensure that the certificate presented by the server has a Subject Alternative Name that matches the server's hostname. Alternatively, endpoint identification for RMI TLS connections can be disabled on the client side by setting the jdk.rmi.ssl.client.enableEndpointIdentification system property to false.

The SHA-1 algorithm has been disabled by default in TLS 1.2 and DTLS 1.2 handshake signatures, by adding "rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature" to the jdk.tls.disabledAlgorithms security property in the java.security config file. RFC 9155 deprecates the use of SHA-1 in TLS 1.2 and DTLS 1.2 digital signatures. Users can, at their own risk, re-enable the SHA-1 algorithm in TLS 1.2 and DTLS 1.2 handshake signatures by removing "rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature" from the jdk.tls.disabledAlgorithms security property.

For the JDK11+ LTS families, the JDK will install into a version-specific installation directory by default. The installation directory of 11+ will have a - before the version-specific string to keep consistency with the past 11+ conventions per family. A junction, also known as a symlink for Windows, will also be created in a "latest" directory. It will point to the latest version of that family. Here is a breakdown example of installation and junction locations 11+ families:

Each junction will always point to the latest JDK of the matching LTS family. The junction for each family will be removed when the last JDK of the matching LTS family is uninstalled.

jcmd command will be available in the headless JDK RPM instead of the headful JDK RPM.

It will be added to the java alternatives group instead of the javac alternatives group.

The TLS_RSA cipher suites have been disabled by default, by adding "TLS_RSA_" to the jdk.tls.disabledAlgorithms security property in the java.security configuration file. The TLS_RSA cipher suites do not preserve forward-secrecy and are not commonly used. Some TLS_RSA cipher suites are already disabled because they use DES, 3DES, RC4, or NULL, which are disabled. This action disables all remaining TLS_RSA cipher suites. Any attempts to use cipher suites starting with "TLS_RSA_" will fail with an SSLHandshakeException. Users can, at their own risk, re-enable these cipher suites by removing "TLS_RSA_" from the jdk.tls.disabledAlgorithms security property. The following previously enabled cipher suites are now disabled:

TLS_RSA_WITH_AES_256_GCM_SHA384

TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA

On Debian-based Linux distributions such as Ubuntu, the /etc/timezone file was previously used to determine the JDK's default time zone (TimeZone.getDefault()). According to Debian's Wiki, /etc/localtime is now the primary source for the system's default time zone, making /etc/timezone redundant. As a result, the JDK's default time zone detection logic has been updated to use /etc/localtime instead of /etc/timezone. If /etc/localtime and /etc/timezone are inconsistent for any reason, the JDK's default time zone is now determined solely based on /etc/localtime file.

A new system and security property, com.sun.security.allowedAIALocations, has been introduced. This property allows users the ability to define one or more filtering rules to be applied to URIs obtained from the authority info access extension on X.509 certificates. These filter rules are applied specifically to the CA issuers access method. Any CA issuers URIs in X.509 certificates are only followed when the com.sun.security.enableAIAcaIssuers system property is enabled and the filter allows the URI.

In order to set the rules, the user must set either the com.sun.security.allowedAIALocations security property or the system property by the same name. If the system property has a value, it will override the security property. By default the property is blank, which enacts a deny-all ruleset.

For either property, the value consists of a set of space-separated rules that take the form of a URI, with the following constraints:

• The URI must be absolute and hierarchical.
• The URI must only use one of the following schemes: http, https, ldap, or ftp (case-insensitive).
• A hostname or address must be specified and must match (case-insensitive). No name resolution is performed on hostnames to match URIs with IP addresses.
• The port number must match. Where a port number is omitted, the well-known port will be used in the comparison.
• For hierarchical schemes (http[s], ftp):
  • A rule's normalized path portion of the URI is matched in a case-sensitive manner. If the final component does not end in a slash (/), it is considered to be a file path and must match the CA issuer URI path component. If the rule's path component ends in a slash, then it must match or be a prefix of the CA issuer URI path component. (for example, a filter path of /ab/cd/ will match a CA issuer path of /ab/cd/, /ab/cd/ef and /ab/cd/ef/ghi.).
  • Query strings and fragments will be ignored when matching CA issuer URIs.
• For ldap URIs:
  • The base DN must be an exact match (case-insensitive).
  • Any query string in the rule, if specified, will be ignored.

For the properties, a single value of "any" (case-insensitive) will create an allow-all rule.