RELEASE NOTES: JDK 17.0.15

Distrust TLS Server Certificates Anchored by Camerfirma Root Certificates and Issued After April 15, 2025

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.

Legacy Mechanism Check in SunPKCS11 Provider Is Enhanced with Service Type

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 JNI_GetCreatedJavaVMs Method Will Now Only Return a Fully Initialized VM

In prior releases, JNI_GetCreatedJavaVMs: ` jint JNI_GetCreatedJavaVMs(JavaVM **vmBuf, jsize bufLen, jsize *nVMs); could return aJavaVM, via thevmBufarray, 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, innVMs, is greater than zero, before trying to use anyvmBuf` entries.

Enhanced OCSP, Certificate, and CRL Fetch Timeouts

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.

Enhanced OCSP, Certificate, and CRL Fetch Timeouts

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 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.