This feature delivers an enhanced syntax for properties related to certificate, CRL, and OCSP connect and read timeouts. The new syntax allows the timeout values to be specified either in seconds or milliseconds. This feature also delivers three new System properties related to connect and read timeouts.

New properties: The existing com.sun.security.ocsp.timeout property will now be paired with the new com.sun.security.ocsp.readtimeout property. The former property will be used to set timeouts for the transport-layer connection while the latter will be used to manage timeouts for reading the data. The default value for the com.sun.security.ocsp.readtimeout System property will be the same as whatever value is set for the com.sun.security.ocsp.timeout property, even if the latter property is not set (in which case both properties will be set to the default value of com.sun.security.ocsp.timeout). The new com.sun.security.cert.timeout and com.sun.security.cert.readtimeout properties will be used to control connect and read timeouts, respectively, when following an X.509 certificate's AuthorityInfoAccess extension. For the certificate fetching properties, the com.sun.security.enableAIAcaIssuers property must be set to true in order for fetching to occur and these property timeouts to be enabled.

Enhanced timeout syntax: The new syntax applies to the aforementioned properties, and also to the com.sun.security.crl.timeout and com.sun.security.crl.readtimeout properties as well. The allowed syntax is as follows:

• A decimal integer will be interpreted in seconds and ensures backward compatibility.
• A decimal integer ending in "s" (case-insensitive, no space) appended to it. This will also be interpreted in seconds.
• A decimal integer value with "ms" (case-insensitive, no space) appended to it. This will be interpreted as milliseconds. For example, a value of "2500ms" will be a 2.5 second timeout.
• Negative, non-numeric, or non-decimal (for example, hexadecimal values prepended by "0x") values will be interpreted as illegal and will default to the 15 second timeout.
• Whether the value is interpreted in seconds or milliseconds, a value of zero will disable the timeout.

Native PKCS11 mechanisms which support decryption but not encryption, or signature verification but not signing, are considered legacy and are disabled by default. The legacy mechanism check in SunPKCS11 provider is enhanced with the service type. For example, prior to this fix, a mechanism supporting encryption, decryption, and verification but not signing, is considered legacy and can't be used at all. After this fix, the corresponding Cipher service using this mechanism is available since both encryption and decryption are supported. However, the corresponding Signature service is not since only verification is supported. To bypass the legacy mechanism check, set the PKCS11 provider configuration attribute "allowLegacy" to true. The default value is false. Note that it is the caller's responsibility to make sure the legacy mechanism is not used for the unsupported functionality.

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.

The JarInputStream class now treats a signed JAR as unsigned if it detects a second manifest within the first two entries in the JAR file. A warning message "WARNING: Multiple MANIFEST.MF found. Treat JAR file as unsigned." is logged if the system property, -Djava.security.debug=jar, is set.

In prior releases, JNI_GetCreatedJavaVMs:

jint JNI_GetCreatedJavaVMs(JavaVM **vmBuf, jsize bufLen, jsize *nVMs);

could return a JavaVM, via the vmBuf array, that was still in the process of being initialized and may not be ready for use. This has now changed so that it will only return fully initialized VMs. It is important that the programmer checks that the returned number of VMs, in nVMs, is greater than zero, before trying to use any vmBuf entries.

JDK 17 introduced a performance improvement that made OCSP clients unconditionally use GET requests for small requests, while doing POST requests for everything else. This is explicitly allowed and recommended by RFC 5019 and RFC 6960. However, we have seen OCSP responders that, despite RFC requirements, are not working well with GET requests.

This release introduces a new JDK system property to allow clients to fallback to POST-only behavior. This unblocks interactions with those OCSP responders through the use of -Dcom.sun.security.ocsp.useget={false,true}. This amends the original change that introduced GET OCSP requests (JDK-8179503). The default behavior is not changed; the option defaults to true. Set the option to false to disable GET OCSP requests. Any value other than false (case-insensitive) defaults to true.

This option is non-standard, and might go away once problematic OCSP responders get upgraded.