Release notes for Red Hat build of OpenJDK 17.0.17

Red Hat build of OpenJDK 17 provides enhancements to features originally created in earlier releases of Red Hat build of OpenJDK.

Improved HTTP/2 flow control checks

Red Hat build of OpenJDK 17.0.17 enhances the HTTP/2 client implementation in java.net.http.HttpClient objects to report flow control errors to the server. This behavior is typically transparent in most situations. However, it might mean that streams are reset or connections are closed when connecting to an HTTP/2 server that does not correctly handle these errors.

You can use the following existing properties to adjust flow control limits:

If you specify an invalid value, the default value is used. This enhancement guarantees that the actual value for the connection window size is not smaller than the stream window size.

See JDK-8342075 (JDK Bug System).

XML Security for Java updated to Apache Santuario 3.0.5

From Red Hat build of OpenJDK 17.0.17 onward, the XML signature implementation is based on Apache Santuario 3.0.5. This supersedes the behavior in earlier releases where the XML signature implementation was based on Apache Santuario 3.0.3.

This enhancement introduces the following four SHA-3-based ECDSA SignatureMethod algorithms:

Because the SignatureMethod constants for these algorithms are available in Java 25 only, use the following equivalent string literal values to obtain instances of these algorithms:

See JDK-8344137 (JDK Bug System).

LDAP and RMI protocol-specific object factory filters for JNDI

The OpenJDK security updates in April 2021 introduced jdk.jndi.object.factoriesFilter as both a system property and a security property. This property is used to control whether a specific object factory is permitted to instantiate objects from the remote object references that are obtained by using the protocols in the Java Naming and Directory Interface (JNDI) API. By default, this property was set to an asterisk (*) wildcard value to allow all object factory classes.

Red Hat build of OpenJDK 17.0.17 introduces the following two additional properties to provide more granular control of the Lightweight Directory Access Protocol (LDAP) and Remote Method Invocation (RMI) protocols that JNDI uses:

Each of these new properties is also available as both a system property and a security property. When using the default values, the system property takes precedence over the security property.

Each filter can return a result of ALLOWED, REJECTED, or UNDECIDED by using the Status enumeration from the java.io.ObjectInputFilter interface.

For an object factory class to be accepted, it must meet both of the following conditions:

If an application depends on custom object factories to instantiate objects from remote RMI or LDAP object references, ensure that you update the appropriate filter property to allow these factories to function. Otherwise, the filter will block the factory and a plain javax.naming.Reference instance is returned instead.

See JDK-8290368 (JDK Bug System).

Mechanism for disabling different parts of the TLS cipher suite based on pattern matching

In earlier releases, the mechanisms for disabling TLS algorithms were either too general or too specific. For example, if you disabled an algorithm such as RSA, the JDK disabled all cipher suites that used this algorithm. In this situation, the only alternative was to disable each cipher suite specifically.

From Red Hat build of OpenJDK 17.0.17 onward, the jdk.tls.disabledAlgorithms security property in the java.security configuration file supports asterisk (*) wildcard characters for patterns that start with "TLS_". For example, TLS_RSA_* disables all cipher suites that start with TLS_RSA_.

See JDK-8341964 (JDK Bug System).

Mechanism for disabling signature schemes based on their TLS scope

From Red Hat build of OpenJDK 17.0.17 onward, the jdk.tls.disabledAlgorithms security property also accepts suffix values that specify and limit the use of specific algorithms. In this situation, you can specify that a particular algorithm may be used in TLS handshake exchanges only or for signing TLS certificates only.

Each suffix value must consist of the word usage and either HandshakeSignature for TLS handshake exchanges or CertificateSignature for TLS certificates. For example, rsa_pkcs1_sha1 usage HandshakeSignature indicates that the rsa_pkcs1_sha1 algorithm may be used in TLS handshake exchanges only and it cannot be used for signing TLS certificates.

See JDK-8349583 (JDK Bug System).

"Best-fit" mapping disabled in Windows command prompt

In earlier releases, on Windows platforms, the Java launcher used the American National Standards Institute (ANSI) version of the GetCommandLine() Win32 API call to obtain command-line arguments. In this situation, if the command-line arguments contained Unicode characters that did not exist in the ANSI code page, these arguments were converted to other characters based on the Windows "best fit" mapping. However, this mapping could have introduced unexpected characters and differed between code pages.

From Red Hat build of OpenJDK 17.0.17 onward, the JDK reads command-line arguments as Unicode characters and then converts them to the ANSI code page, using the default replacement for any unmappable character. If applications need to use unmappable characters as is, without replacement, ensure that you select UTF-8 in the Windows regional settings.

See JDK-8337506 (JDK Bug System).

Information improvements for container memory usage

From Red Hat build of OpenJDK 17.0.17 onward, the JDK provides additional information for containers by also including memory usage details for both the Resident Set Size (RSS) and the cache. These memory usage details are specified in bytes.

This additional information is visible in both of the following locations:

See JDK-8313083 (JDK Bug System).

Fix for SunMSCAPI provider to allow processes without elevated permissions to read local computer keystore certificates

In earlier releases, the SunMSCAPI provider required processes to have administrator privileges to access the local computer keystore.

From Red Hat build of OpenJDK 17.0.17 onward, the SunMSCAPI provider allows processes without elevated permissions to access the keystore in read-only mode by using the CERT_STORE_MAXIMUM_ALLOWED_FLAG.

See JDK-8313367 (JDK Bug System).

The following pre-existing features have been either deprecated or removed in Red Hat build of OpenJDK 17.0.17:

AffirmTrust root CA certificates removed

From Red Hat build of OpenJDK 17.0.17 onward, the cacerts truststore no longer includes the following AffirmTrust root certificates, which were deactivated in the Red Hat build of OpenJDK 17.0.13 release in October 2024:

See JDK-8361212 (JDK Bug System).