Additional information on Oracle's JDK and JRE Cryptographic Algorithms

Changing default TLS protocol version for client end points : TLS 1.0 to TLS 1.2

TLS 1.2 has been the default-enabled TLS protocol for JDK 8 since its release.  Due to concerns around TLS version intolerance, TLS 1.0 was left as the default enabled protocol for client end points on JDK 6 and JDK 7 when TLS 1.2 was added to those releases.

What is TLS version intolerance?

Since there are various versions of TLS (1.0, 1.1, 1.2, and possible future versions) and SSL, TLS protocols provide a built-in mechanism to negotiate the specific protocol version to use. When a client connects to a server, it announces the highest version it can support, and the server then responds with the protocol version that will actually be used for the connection. If the version chosen by the server is not supported or not acceptable by the client, the client terminates the negotiation and closes the connection. For example, if the client supports TLS 1.2 but the server only supports TLS 1.0, they will communicate using TLS 1.0; However, if the client does not support TLS 1.0, it will close the connection immediately.

In practice, some servers were not implemented properly and do not support protocol version negotiation. For example a server that supports TLS 1.0 only might simply reject a client request for TLS 1.2. Even if the client would have been able to supports TLS 1.0 a connection is not established.  This is a server bug, often called "version intolerance".

How to change the protocol version on client side

Several options exist for changing the default client-side TLS protocol version in the JDK.

Option 1. Use the "jdk.tls.client.protocols" system property

This property was introduced to JDK 7 in 7u95 and to JDK 6 in 6u121.

To enable specific TLS protocols on the client, specify them in a comma-separated list within quotation marks; all other supported protocols are then disabled on the client. For example, if the value of this property is "TLSv1.1,TLSv1.2", then the default protocol settings on the client for TLSv1.1 and TLSv1.2 are enabled on the client, while SSLv3, TLSv1, and SSLv2Hello are disabled on the client.

Note that the standard TLS protocol version names used in the JDK are SSLv3, TLSv1, TLSv1.1 and TLSv1.2.

Option 2. Use SSLContext to set TLS version

SSLContext of "TLSv1.2" protocol supports TLS 1.2. For example:

An SSLContext with "TLSv1" protocol supports TLS versions up to TLS 1.0 (no TLS 1.1 and 1.2).
An SSLContext created with "TLSv1.1" supports versions up to TLS 1.1 (no TLS 1.2).

Option 3 Use the SSLSocket/SSLEngine.setEnabledProtocols() API

Applications can set the enabled protocols explicitly in an SSLSocket/SSLEngine object. For example:

Option 4. Use the SSLParameters.setProtocols() API

Applications can set the protocols in an SSLParameters object, and then apply it to a connection via the SSLSocket.setSSLParameters() and SSLEngine.setSSLParameters() methods. For example:

For client applications, administrators may have to remove TLS 1.1 or TLS 1.2 from the default enabled protocol list to work around a TLS version intolerance issue on the server side.

Enabling TLSv1.3 by default on the client

TLS 1.3 will be enabled by default on the client for JDK 8. JDK 8 has included an implementation of the TLS 1.3 specification (RFC 8446) since (8u261). However, TLS 1.3 has not yet been enabled by default on the client.

To test this change, the TLS 1.3 protocol can be enabled on the client using the jdk.tls.client.protocols system property, for example:

java -Djdk.tls.client.protocols="TLSv1.3,TLSv1.2" ... 

or by using the https.protocols system property if the application is using the HttpsURLConnection or URL.openStream() APIs, for example:

java -Dhttps.protocols="TLSv1.3,TLSv1.2" ... 

Alternatively, you can enable TLS 1.3 with the SSLSocket, SSLEngine, or SSLServerSocket APIs, for example:

				

				
sslSocket.setEnabledProtocols(new String[] {"TLSv1.3", "TLSv1.2"});
				
SSLContext ctx = SSLContext.getInstance("TLSv1.3");
				
sslParameters.setProtocols(new String[] {"TLSv1.3", "TLSv1.2"}); 
				
				

For more details, refer to the Java Secure Socket Extension (JSSE) Reference Guide and JEP 332.

Enabling XML Signature secure validation mode by default

This change has already been made in JDK 17 and later releases.

This change will enable the XML Signature secure validation mode by default.

When enabled, validation of XML signatures are subject to stricter checking of algorithms and other constraints as specified by the jdk.xml.dsig.secureValidationPolicy security property. When enabled, the following restrictions are enforced by default:

• – XSLT transforms are forbidden
• – The maximum number of SignedInfo or Manifest Reference elements is 30
• – The maximum number of Reference transforms is 5
• – MD5 signature, digest or mac algorithms are forbidden
• – Reference IDs must be unique
• – Reference URIs of type http, https, or file are forbidden
• – RetrievalMethod elements cannot reference another RetrievalMethod element
• – RSA or DSA keys less than 1024 bits are forbidden
• – EC keys less than 224 bits are forbidden

To test the changes before they take effect, use one of the following procedures:

• For releases 8u401+ and 11.0.22+, the system property org.jcp.xml.dsig.secureValidation can be used to enable or disable the XML Signature secure validation mode. Set this property to true to test the changes, for example:

  
  			java -Dorg.jcp.xml.dsig.secureValidation=true ... <rest of command line>
  			

• It is also possible to enable the validation mode in your application code by setting the property org.jcp.xml.dsig.secureValidation to Boolean.TRUE with the javax.xml.crypto.dsig.dom.DOMValidateContext.setProperty method as explained in the XML Digital Signature API Overview and Tutorial.
• If your application runs with a Security Manager, it will have secure validation on. We don't recommend adopting Security Manager as a way of enabling secure validation for applications that don't already use it as the Security Manager is deprecated and will be removed in a future version.

Setting the TLS server's cipher suite order by default

This change has already been made in JDK 13 and later releases.

During TLS handshaking, the client requests to negotiate a cipher suite from a list of cryptographic options that it supports, starting with its first preference. Then, the server selects a single cipher suite from the list of cipher suites requested by the client. Prior to this change, the selection, by default, honors the client's preference. After this change, the selection, by default, honors the server's preference.

To test this change, the server's cipher suite order preference must be set on the server using the SSLParameters.setUseCipherSuitesOrder() API, for example:

sslParameters.setUseCipherSuitesOrder(true);

This change is low risk as the selected cipher suite must be one that is supported by both client and server.

Increasing the default TLS Diffie-Hellman group size from 1024-bit to 2048-bit

Note: This change will be released in JDK 21 (expected GA date is 2023-09-19).

This change will increase the default TLS Diffie-Hellman group size from 1024-bit to 2048-bit. This change affects TLSv1.2 connections when a TLS_DHE cipher suite is negotiated, and either the client or server does not support FFDHE.

To test the changes before they take affect, you can set the jdk.tls.ephemeralDHKeySize system property to 2048 and the jsse.enableFFDHE system property to "false" to disable FFDHE.

For example:

$ java -Djdk.tls.ephemeralDHKeySize=2048 -Djsse.enableFFDHE=false <rest of command line> 

Changing minimum key length for Diffie-Hellman

For JDK 8 and earlier, edit lib/security/java.security and add the desired length to the jdk.tls.disabledAlgorithms property by appending DH KeySize < min keylength

In JDK 9, java.security has been moved to conf/security/java.security

For example,

if the current value is:

jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 768

				

jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize <  1024

				

If no value is set for DSA keySize, just append it at the end of the property after a comma.

Changing minimum key length for DSA certificates

For JDK 8 and earlier, edit lib/security/java.security and add the desired length to the jdk.certpath.disabledAlgorithms property by appending DSA KeySize < min keylength

In JDK 9, java.security, has been moved to conf/security/java.security

For example,

if the current value is:

jdk.certpath.disabledAlgorithms=MD2, MD5, DSA keySize < 768

				
				
				
				
				

jdk.certpath.disabledAlgorithms=MD2, MD5, DSA keySize <  1024

				
				
				
				
				

If no value is set for DSA keySize, just append it at the end of the property after a comma.

Changing minimum key length for EC

For JDK 8 and earlier, edit lib/security/java.security and add the desired length to the jdk.certpath.disabledAlgorithms property by appending EC KeySize < min keylength

In JDK 9, java.security, has been moved to conf/security/java.security

For example,

if the current value is:

jdk.certpath.disabledAlgorithms=MD2, MD5, EC keySize < 160

				
				
				
				
				

jdk.certpath.disabledAlgorithms=MD2, MD5, EC keySize < 224

				
				
				
				
				

If no value is set for EC keySize, just append it at the end of the property after a comma.

Changing minimum key length for RSA signed jars

For JDK 8 and earlier, edit lib/security/java.security and add the desired length to the jdk.jar.disabledAlgorithms property by appending RSA keySize < min keylength

In JDK 9, java.security, has been moved to conf/security/java.security

For example,

if the current value is:

jdk.jar.disabledAlgorithms=MD2, RSA keySize < 1024

				
				
				
				
				

jdk.jar.disabledAlgorithms=MD2, RSA keySize < 2048

				
				
				
				
				

If no value is set for RSA keySize, just append it at the end of the property after a comma.

To check if a weak algorithm or key was used to sign a JAR file you must use JDK 8u111, 7u121, 6u131, or later. After configuring the java.security file, you can use the jarsigner binary that ships with the JDK. Running jarsigner ‑verify ‑J-Djava.security.debug=jar on a JAR file signed with a weak algorithm or key will print more information about the disabled algorithm or key.

Configuring Unlimited Cryptographic Policy

Due to import control restrictions of some countries, the version of the JCE policy files bundled in the Java Runtime Environment 8, 7, and 6 allow strong but limited cryptography.  In order to remove restrictions on cryptography one must download and apply the JCE Unlimited Strength Jurisdiction Policy Files for the corresponding release.

YOU ARE ADVISED TO CONSULT YOUR EXPORT/IMPORT CONTROL COUNSEL OR ATTORNEY TO DETERMINE YOUR COUNTRY'S EXACT REQUIREMENTS. If your country has restrictions that don't fit either "limited" or "unlimited", an appropriate set of policy files should be created and configured before using this distribution.  The jurisdiction policy file configuration must reflect the cryptographic restrictions appropriate for your country.

Use the following links to find the Unlimited Strength Policy Files for JDK 8, 7, and 6.

• Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files for JDK 8
  
• Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files for JDK 7
  
• Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files for JDK 6

After downloading the Unlimited Strength Policy Files unzip the file and look for the README.txt file in the main directory for instructions.

Disabling Kerberos DES encryption by default

On JDK 7, add allow_weak_crypto=false to the [libdefaults] section of the krb5.conf configuration file on your system,

For example,

				[libdefaults]

				allow_weak_crypto = false				
				

You can also set the java.security.krb5.conf system property to the location of an alternate krb5.conf file to be used by your Java application instead of the default.

Disabling MD5 signed jars

For JDK 8 and earlier, edit lib/security/java.security and add the algorithm to be disabled to the jdk.jar.disabledAlgorithms property by appending the algorithm name.

In JDK 9, java.security, has been moved to conf/security/java.security

For example,

if the current value is:

jdk.jar.disabledAlgorithms=MD2, RSA keySize < 1024

				
				
				
				
				

jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024

				
				
				
				
				

To check if a weak algorithm or key was used to sign a JAR file you must use JDK 8u121, 7u131, 6u141, or later. After configuring the java.security file, you can use the jarsigner binary that ships with the JDK. Running jarsigner ‑verbose ‑verify on a JAR file signed with a weak algorithm or key will print more information about the disabled algorithm or key.

Disable SHA-1 in certificate chains anchored by roots included by default in Oracle's JDK

Any TLS server certificate chain containing a SHA-1 certificate (end-entity or intermediate CA) anchored by root CA certificates included by default in Oracle's JDK will be blocked. Enterprise/private CAs are not affected. See JEP-288 for more information.

You can prepare for this change by testing with Early Access builds of JDK 8 or JDK 9 as follows:

With JDK 8 EA:
1 - Download a JDK 8u152 EA or later from https://jdk8.java.net/download.html
2  - Edit the lib/security/java.security file of your JDK installation.

If not already set, add the following constraint to the jdk.certpath.disabledAlgorithms property:    SHA1 jdkCA & usage TLSServer

For example, if the current value of the property is:

jdk.certpath.disabledAlgorithms=MD2, MD5, RSA keySize <

1024, DSA keySize < 1024, EC keySize < 224
				

jdk.certpath.disabledAlgorithms=MD2, MD5, RSA keySize <

1024, DSA keySize < 1024, EC keySize < 224, SHA1 jdkCA
& usage TLSServer 

				

Disabling SHA-1 signed jars

Change Log:
2021-10-19 Removed the exception for JARs that are signed with certificates that do not chain back to a Root CA included by default in the JDK cacerts keystore.

Note that this change has already been made in JDK 18 and later releases.

When this change is released, JARs signed with SHA-1 algorithms will be disabled by default and treated as if they were unsigned (however, see exceptions to this policy below). This applies to the algorithms used to digest, sign, and optionally timestamp the JAR. It also applies to the signature and digest algorithms of the certificates in the certificate chain of the code signer and the Timestamp Authority, and any CRLs or OCSP responses that are used to verify if those certificates have been revoked.

Exceptions to this policy:

• Any JAR signed and timestamped with SHA-1 algorithms prior to January 01, 2019 will not be restricted.

This policy is subject to change and may be made more restrictive.

Use one of the following two methods to find out if your signed JARs may be affected by this change:

1. For JDK 7u301, 8u291, 11.0.11, 17 or later releases, edit the java.security file and make the following changes:

   • add "SHA1 usage SignedJAR & denyAfter 2019-01-01" to the jdk.certpath.disabledAlgorithms security property
   • add "SHA1 denyAfter 2019-01-01" to the jdk.jar.disabledAlgorithms security property
   
   

   For example, if the current value of these properties is:

   
   			jdk.certpath.disabledAlgorithms=MD2, MD5, SHA1 jdkCA & usage TLSServer, \
   
   			    RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224
   
   			
   			jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, \
   
   			    DSA keySize < 1024
   
   			

   then the new values would be:

   
   			jdk.certpath.disabledAlgorithms=MD2, MD5, SHA1 jdkCA & usage TLSServer, \
   
   			    RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224, \
   
   			    SHA1 usage SignedJAR & denyAfter 2019-01-01
   
   			jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, \
   
   			    DSA keySize < 1024, SHA1 denyAfter 2019-01-01
   
   			

   Signed JARs that violate these constraints will be treated as if they were not signed.

2. For all other JDK releases, or as an additional testing mechanism for the releases previously listed, run jarsigner -verify -verbose -certs on the signed JAR, and look for instances of "SHA1" or "SHA-1" in the output.

   For example:

   
   			Signed by "CN="ee""
   
   			 Digest algorithm: SHA-1 (weak)
   
   			 Signature algorithm: SHA1withRSA (weak), 2048-bit key
   
   			

   If your JAR is timestamped, check the output for the date it was timestamped on and check if it is on or after January 01, 2019. For example:

   Timestamped by "CN="tsa"" on Tue Jun 16 03:20:48 UTC 2020
   
   			

Disabling 3DES cipher suites for TLS

For JDK 8 and earlier, edit lib/security/java.security and add the 3DES cipher suites to the jdk.tls.disabledAlgorithms property by appending

3DES_EDE_CBC

				

In JDK 9 and later java.security has been moved to conf/security/java.security

For example, if the current value is:

jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize  < 1024, \


				   EC keySize  < 224
				

jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 1024, \


			       EC keySize < 224,3DES_EDE_CBC 

				

Disabling anon and NULL cipher suites for TLS

For JDK 8 and earlier, edit lib/security/java.security and add the anon and NULL cipher suites to the jdk.tls.disabledAlgorithms property by appending

anon, NULL

				

In JDK 9 and later, java.security has been moved to conf/security/java.security

For example, if the current value is:

jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 1024, \


				  EC keySize < 224, DES, 3DES_EDE_CBC

jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 1024, \


				  EC keySize < 224, DES, 3DES_EDE_CBC, anon, NULL

Disabling DES cipher suites for TLS

For JDK 8 and earlier, edit lib/security/java.security and add the DES cipher suites to the jdk.tls.disabledAlgorithms property by appending

DES

				

(or replacing DES40_CBC with DES)

In JDK 9 and later java.security has been moved to conf/security/java.security

For example, if the current value is:

jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 1024, \


   				   EC keySize < 224, DES40_CBC, RC4_40, 3DES_EDE_CBC
				

jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 1024, \


   				   EC keySize < 224, DES40_CBC, RC4_40, 3DES_EDE_CBC, DES
				

Disabling TLS 1.0 and TLS 1.1

Edit conf/security/java.security (lib/security/java.security in JDK 8 and earlier) and add TLS 1.0 and TLS 1.1 to the jdk.tls.disabledAlgorithms property by appending

TLSv1, TLSv1.1

For example, if the current value is:

jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, DH keySize < 1024, \


				   EC keySize < 224, 3DES_EDE_CBC, anon, NULL
				

jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, DH keySize < 1024, \


				   EC keySize < 224, 3DES_EDE_CBC, anon, NULL, TLSv1, TLSv1.1

				

Disabling TLS_ECDH Cipher Suites

Note: This change has already been made in JDK 20 and later releases.

TLS_ECDH cipher suites do not preserve forward-secrecy and are rarely used in practice. Note that some TLS_ECDH cipher suites were already disabled because they use algorithms that are disabled, such as 3DES and RC4. This action will disable the rest. Any attempts to use cipher suites starting with "TLS_ECDH_" will fail with an SSLHandshakeException.

To test the changes before they take affect, edit conf/security/java.security (lib/security/java.security in JDK 8) and add ECDH to the jdk.tls.disabledAlgorithms property by appending "ECDH".

For example, if the current value is:

jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA, \


			   DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL

			

then the new value would be:

jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA, \


			   DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, ECDH

			

This change has no effect on the TLS_ECDHE cipher suites, which are still enabled by default.

Disabling TLS_RSA Cipher Suites

This change will be implemented in a feature release prior to being backported to earlier LTS releases.

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 algorithms such as 3DES and RC4, that were already disabled. This action will disable the rest. Any attempts to use cipher suites starting with "TLS_RSA_" will fail with an SSLHandshakeException.

To test the changes before they take affect, edit conf/security/java.security (lib/security/java.security in JDK 8) and add 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, and TLS_RSA_WITH_AES_128_CBC_SHA to the jdk.tls.disabledAlgorithms property.

For example, if the current value is:

jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA, \


			   DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, ECDH

			

then the new value would be:

jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA, \ 


			   DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, ECDH, \ 

			   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 

			

Distrusting TLS server certificates anchored by Entrust root certificates and issued after Nov 11, 2024

The JDK will stop trusting TLS server certificates issued after Nov 11, 2024 and anchored by Entrust root certificates, in line with similar plans recently announced by Google and Mozilla. The list of affected certificates includes certificates branded as Entrust and AffirmTrust.

TLS server certificates issued on or before Nov 11, 2024 will continue to be trusted until they expire. Certificates issued after that date will be rejected. Entrust has announced that they will be offering TLS certificates issued by a CA partner (SSL.com).

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 November 11 of 2024.

An application will receive an Exception with a message indicating the trust anchor is not trusted, ex:

TLS server certificate issued after 2024-11-11 and anchored by a distrusted legacy Entrust root CA:


			CN=Entrust.net Certification Authority (2048), OU=(c) 1999 Entrust.net Limited, OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.), O=Entrust.net

The restrictions can be disabled by removing "ENTRUST_TLS" from the jdk.security.caDistrustPolicies security property in the java.security configuration file.

The restrictions are imposed on the following Entrust Root certificates included in the JDK:

1. CN=Entrust Root Certification Authority, OU="(c) 2006 Entrust, Inc.", OU=www.entrust.net/CPS is incorporated by reference, O="Entrust, Inc.", C=US
2. CN=Entrust Root Certification Authority - EC1, OU="(c) 2012 Entrust, Inc. - for authorized use only", OU=See www.entrust.net/legal-terms, O="Entrust, Inc.", C=US
3. CN=Entrust Root Certification Authority - G2, OU="(c) 2009 Entrust, Inc. - for authorized use only", OU=See www.entrust.net/legal-terms, O="Entrust, Inc.", C=US
4. CN=Entrust Root Certification Authority - G4, OU="(c) 2015 Entrust, Inc. - for authorized use only", OU=See www.entrust.net/legal-terms, O="Entrust, Inc.", C=US
5. CN=Entrust.net Certification Authority (2048), OU=(c) 1999 Entrust.net Limited, OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.), O=Entrust.net
6. CN=AffirmTrust Commercial, O=AffirmTrust, C=US
7. CN=AffirmTrust Networking, O=AffirmTrust, C=US
8. CN=AffirmTrust Premium, O=AffirmTrust, C=US
9. CN=AffirmTrust Premium ECC, O=AffirmTrust, C=US

A prior version of this change had the distrust date set to after Oct 31, 2024. It was updated to after Nov 11, 2024 to align with other root stores thus providing more consistency for security administrators.

Distrusting TLS server certificates anchored by Camerfirma root certificates and issued after April 15, 2025

The JDK will stop trusting TLS Server certificates issued by Camerfirma, in line with similar actions by Apple, Google, Microsoft, and Mozilla.

TLS Server certificates issued on or before April 15, 2025 will continue to be trusted until they expire. Certificates issued after that date 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 following Certificate Authorities:

1. CN=Chambers of Commerce Root, OU=http://www.chambersign.org, O=AC Camerfirma SA CIF A82743287, C=EU
2. 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
3. CN=Global Chambersign Root - 2008, O=AC Camerfirma S.A., SERIALNUMBER=A82743287, L=Madrid (see current address at www.camerfirma.com/address), C=EU

An application will receive an exception with a message indicating the trust anchor is not trusted, ex:

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.

Improving the TLS cipher suite order

The priority order of the cipher suites for TLS 1.0 to TLS 1.2 will be adjusted in JDK 7, 8 and 11, and the order of the TLS 1.3 suites will be adjusted for JDK 8 and 11.

For TLS 1.3, TLS_AES_256_GCM_SHA384 will now be preferred over TLS_AES_128_GCM_SHA256.

For TLS 1.2, some of the intermediate suites will be lowered in priority:

1. Cipher suites that do not preserve forward secrecy will be moved lower in priority than those that do support forward secrecy
2. Cipher suites that use SHA-1 will be moved lower in priority

This change is already in JDK 13 and up. The order in JDK 8 and 11 will be adjusted to match that of JDK 13 and up:

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, 


					TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,

					TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, 

					TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,

					TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, 

					TLS_DHE_DSS_WITH_AES_256_GCM_SHA384, 

					TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,

					TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, 

					TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,

					TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,

					TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,

					TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, 

					TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,

					TLS_DHE_DSS_WITH_AES_256_CBC_SHA256, 

					TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,

					TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, 

					TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,

					TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384, 

					TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,

					TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, 

					TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,

					TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384, 

					TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,

					TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, 

					TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,

					TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, 

					TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,

					TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, 

					TLS_DHE_RSA_WITH_AES_256_CBC_SHA,

					TLS_DHE_DSS_WITH_AES_256_CBC_SHA, 

					TLS_DHE_RSA_WITH_AES_128_CBC_SHA,

					TLS_DHE_DSS_WITH_AES_128_CBC_SHA, 

					TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,

					TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, 

					TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,

					TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, 

					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, 

					TLS_EMPTY_RENEGOTIATION_INFO_SCSV

				

To test the changes, you can set the jdk.tls.client.cipherSuites, jdk.tls.server.cipherSuites, or https.cipherSuites system properties to the list of cipher suites above.

On JDK 7, for TLS 1.2, the cipher suite order will also be updated but the CBC suites will continue to be preferred over the GCM suites. On JDK 7, 8, and 11, similar changes will be made to the TLS 1.0 and 1.1 cipher suite order; however these versions of the TLS protocol are not recommended and are disabled by default.

Disabling weak named curves by default in TLS, CertPath, and Signed JARs

The following named elliptic curves will be disabled by default in TLS, CertPath, and Signed JARs:

			secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, secp160r2, secp192k1,

			secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2,

			sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1,

			sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, 

			X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, X9.62 c2tnb239v2, X9.62 c2tnb239v3, 

			X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 prime239v1, 

			X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1, brainpoolP320r1, brainpoolP384r1, brainpoolP512r1 
			

These are rarely used curves that are deprecated or have not been implemented using modern cryptographic techniques. Any elliptic curve algorithm or certificate used in CertPath, TLS or signed JARs that uses one of these curves will be restricted by default.

Note that for TLS, this action goes a step further than the previously released restriction for TLS on the cryptographic roadmap: "Disabled non-NIST Suite B EC curves (sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, secp256k1) when negotiating TLS sessions". In particular, this will restrict more curves and also restrict them even if they are explicitly included in the jdk.tls.namedGroups system property.

Curves that will remain enabled are: secp256r1, secp384r1, secp521r1, X25519, and X448.

To re-enable one or more curves that have been disabled, remove the named curve(s) from the jdk.disabled.namedCurves security property in the java.security file.

Making it harder to re-enable SSLv3 (previously disabled) and SSLv2Hello

This change was already in place in JDK 14 and later releases.

SSLv2Hello and SSLv3 will be removed from the default enabled TLS protocols. Note that the SSLv3 protocol is already disabled since it is included in the jdk.tls.disabledAlgorithms security property and by default will not be considered for a TLS connection handshake. SSLv2Hello is a pseudo protocol that can be used to negotiate older protocols with legacy servers, but has little value now that SSLv3, TLSv1 (1.0) and TLSv1.1 are disabled by default. It is currently only enabled on the server side. See this section in the Java Secure Socket Extension (JSSE) Reference Guide for more details on SSLv2Hello and its usage.

This change makes it much harder to enable SSLv3 either accidentally or maliciously.

After this update, if SSLv3 is removed from the jdk.tls.disabledAlgorithms security property, the SSLSocket.getEnabledProtocols(), SSLServerSocket.getEnabledProtocols(), SSLEngine.getEnabledProtocols() and SSLParameters.getProtocols() APIs will return "TLSv1.3, TLSv1.2". "SSLv3" will not be returned in this list. Also, "SSLv2Hello" will not be returned for server side sockets.

If a client or server still needs to use the SSLv3 or SSLv2Hello protocol versions they can do so by removing SSLv3 from the jdk.tls.disabledAlgorithms security property and explicitly enabling the protocols with the jdk.tls.client.protocols or jdk.tls.server.protocols system properties or with the SSLSocket.setEnabledProtocols(), SSLServerSocket.setEnabledProtocols() and SSLEngine.setEnabledProtocols() APIs. However, this action is not recommended and should be done at your own risk.

Removing or restoring root certificates with 1024-bit keys

If you need to restore any of these root certificates, see the Restoring root certificates with 1024-bit keys below for further instructions.

The following root certificates with weak 1024-bit RSA public keys will be removed from the cacerts keystore:

alias name "thawtepremiumserverca [jdk]"
Distinguished Name: EMAILADDRESS=premium-server@thawte.com, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA

alias name "verisignclass2g2ca [jdk]"
Distinguished Name: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 2 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US

alias name "verisignclass3ca [jdk]"
Distinguished Name: OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US

alias name "verisignclass3g2ca [jdk]"
Distinguished Name: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 3 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US

alias name "verisigntsaca [jdk]"
Distinguished Name: CN=Thawte Timestamping CA, OU=Thawte Certification, O=Thawte, L=Durbanville, ST=Western Cape, C=ZA

alias name "gtecybertrustglobalca [jdk]" (only applicable to JDK 8 and 7)
Distinguished Name:CN=GTE CyberTrust Global Root, OU="GTE CyberTrust Solutions, Inc.", O=GTE Corporation, C=US

These roots are inactive and should no longer be issuing certificates. However, you may be impacted if you rely on JAR files that were signed with a certificate that chains back to one of these roots and timestamped. To determine if you will be impacted by the removal, run keytool -printcert -jarfile <jarfile> on your signed JAR(s) and search for the distinguished names listed above in the output. For example, using the grep search tool:

$ keytool -printcert -jarfile HelloWorld.jar | grep "EMAILADDRESS=premium-server@thawte.com, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA"




$ keytool -printcert -jarfile HelloWorld.jar | grep "OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 2 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US"



$ keytool -printcert -jarfile HelloWorld.jar | grep "OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US"



$ keytool -printcert -jarfile HelloWorld.jar | grep "OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 3 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US"



$ keytool -printcert -jarfile HelloWorld.jar | grep "CN=Thawte Timestamping CA, OU=Thawte Certification, O=Thawte, L=Durbanville, ST=Western Cape, C=ZA"



$ keytool -printcert -jarfile HelloWorld.jar | grep "CN=GTE CyberTrust Global Root, OU="GTE CyberTrust Solutions, Inc.", O=GTE Corporation, C=US"

If the JAR is affected, we strongly recommend that the JAR be re-signed with a new certificate issued by a Root CA in cacerts that is not in the list above. Once the root CAs are removed, any affected JARs will not work unless you re-import the applicable root certificate into the cacerts keystore.

Restoring root certificates with 1024-bit keys

Root certificates that have been removed may be restored to the cacerts keystore if necessary, and at your own risk. The keytool utility that is included in the $JDK/bin/ directory has the ability to import certificates from one keystore to another.

Steps highlighted in the example below assume the default storepass of changeit is valid for the keystores being accessed.

1. Identify the alias name of the certificate that needs to be imported into the new JDK cacerts keystore. The aliases of the certificates that have been removed are:

   • thawtepremiumserverca [jdk]
   • verisignclass2g2ca [jdk]
   • verisignclass3ca [jdk]
   • verisignclass3g2ca [jdk]
   • verisigntsaca [jdk]
   • gtecybertrustglobalca [jdk] (only applicable to JDK 8 and 7)
   
   

   One can inspect the certificate corresponding to each alias by using the keytool list option. Locate an older copy of a JDK installation which contains these root certificates in the cacerts keystore. List alias entries in that keystore. E.g.:

   
   $JDK/bin/keytool -list -v -keystore /OLD_JDK/lib/security/cacerts -storepass changeit -alias 
   

   For a complete listing of all certificates in the keystore, simply omit the -alias option:

   
   $JDK/bin/keytool -list -v -keystore /OLD_JDK/lib/security/cacerts -storepass changeit 
   

2. Use the -importkeystore option in keytool to import the certificate of interest from the cacerts file in the older JDK installation. The certificate with the thawtepremiumserverca [jdk] alias is used in this example.

   
   $JDK/bin/keytool -importkeystore -srckeystore /OLD_JDK/lib/security/cacerts -destkeystore /NEW_JDK/lib/security/cacerts -srcstorepass changeit -deststorepass changeit -srcalias "thawtepremiumserverca [jdk]"
   

   output like following will be seen:

   Importing keystore /OLD_JDK/lib/security/cacerts to /NEW_JDK/lib/security/cacerts...

   One can verify that the certificate was correctly imported using the -list command in keytool:

   
   $JDK/bin/keytool -list -keystore /NEW_JDK/lib/security/cacerts -storepass changeit -alias "thawtepremiumserverca [jdk]"
   
   thawtepremiumserverca [jdk], Mar 31, 2021, trustedCertEntry,
   
   Certificate fingerprint (SHA-256): 3F:9F:27:D5:83:20:4B:9E:09:C8:A3:D2:06:6C:4B:57:D3:A2:47:9C:36:93:65:08:80:50:56:98:10:5D:BC:E9
   
   
   
   
   Warning:
   
   The certificate uses a 1024-bit RSA key which is considered a security risk. This key size will be disabled in a future update.
   

   Repeat the above steps for each legacy certificate that needs to be imported into the new JDK install.

Adding support for the x25519 and x448 named elliptic curve groups to TLS

The named elliptic curve groups x25519 and x448 will be available for JSSE key agreement in TLS versions 1.0 to 1.3, with x25519 being the most preferred of the default enabled named groups. After this change, the default ordered list will be:

 x25519, secp256r1, secp384r1, secp521r1, x448, ffdhe2048, ffdhe3072, ffdhe4096,
 ffdhe6144, ffdhe8192

The default list can be overridden using the system property jdk.tls.namedGroups.

Tools should warn if weak algorithms are used before restricting them

The keytool and jarsigner tools currently emit warnings if disabled algorithms are used in certificates, keys, and signed JARs.

With this change, keytool and jarsigner will also emit warnings if weak algorithms are used before they are disabled, so that users have advance notice before the restrictions take effect. A new security property named jdk.security.legacyAlgorithms will be introduced which will include algorithms that are to be disabled in the near future. The initial value of the property will contain SHA-1 and RSA and DSA keys less than 2048-bits.

Upgrading the default PKCS12 encryption algorithms

The default algorithms used to encrypt certificates and keys in a PKCS12 keystore will be upgraded to stronger algorithms.

You must be using JDK 12 or above to test this change. To test the changes before they take affect, edit the java.security file and uncomment (remove the leading "#") and modify the values of the following security properties:

keystore.pkcs12.certProtectionAlgorithm = PBEWithHmacSHA256AndAES_256


keystore.pkcs12.keyProtectionAlgorithm = PBEWithHmacSHA256AndAES_256

Since the algorithms are stronger, the iteration count security properties can also be adjusted according to the recommended iteration count as described in NIST Special Publication 800-63B “5.1.1.2 Memorized Secret Verifiers”:

keystore.pkcs12.certPbeIterationCount = 10000

keystore.pkcs12.keyPbeIterationCount = 10000

Upgrading the default PKCS12 MAC algorithm

Note that this change has already been made in JDK 16 and later releases.

The default algorithms used to protect the integrity of a PKCS12 keystore will be upgraded to a stronger algorithm.

This change is targeted to the JDK 7, 8, and 11 update releases. To test the change on those releases, you must be using the July 2021 CPU JDK releases (7u311, 8u301, 11.0.12) or later. There is no need to test on other JDK supported releases since the change is in 16 and later. To test the changes before they take affect, edit the java.security file and uncomment (remove the leading "#") and modify the values of the following security properties:

keystore.pkcs12.macAlgorithm = HmacPBESHA256

Since the algorithms are stronger, the iteration count security properties can also be adjusted according to the recommended iteration count as described in NIST Special Publication 800-63B “5.1.1.2 Memorized Secret Verifiers”:

keystore.pkcs12.macIterationCount = 10000

These properties will be used by the PKCS12 KeyStore implementation during the creation of a new keystore.

Adding support for SHA-2 HmacPBE algorithms

This change adds support for the following SHA-2 HmacPBE algorithms to the SunJCE provider:

HmacPBESHA224, HmacPBESHA256, HmacPBESHA384, HmacPBESHA512, HmacPBESHA512/224, HmacPBESHA512/256

These algorithms can be specified when creating an instance of javax.crypto.Mac.

Note that these algorithms are already supported in JDK 12 and later releases.

Adding support for ChaCha20 and Poly1305 TLS Cipher Suites

Support for TLS cipher suites using the ChaCha20-Poly1305 algorithm will be added to JDK 11. These cipher suites will be enabled by default.

The TLS_CHACHA20_POLY1305_SHA256 cipher suite will be available for TLS 1.3.

The following cipher suites will be available for TLS 1.2:

• TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
• TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
• TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256

TLS 1.2 Cipher Suite Priorities in JDK 8

The update to the priority order for cipher suites used for negotiating TLS 1.2 connections on JDK 8 will give priority to GCM cipher suites. GCM cipher suites are considered more secure than other cipher suites available for TLS 1.2.

Later versions of the JDK already prefer GCM cipher suites before other cipher suites for TLS 1.2 negotiations.

After the update the order for cipher suites used by JDK 8 for TLS 1.2 will be:

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,


 			TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_256_GCM_SHA384,

			TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,

			TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_DSS_WITH_AES_256_GCM_SHA384,

			TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256,

			TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,

			TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_DSS_WITH_AES_128_GCM_SHA256,

			TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,

			TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,

			TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384, TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,

			TLS_DHE_DSS_WITH_AES_256_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,

			TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA,

			TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,

			TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA,

			TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,

			TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,

			TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,

			TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,

			TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA,

			TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,

			TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA 
			

Before the update CBC cipher suites have a higher priority. Here is the order before the update:

			TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,

			TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,
			
			TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384, TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,

			TLS_DHE_DSS_WITH_AES_256_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,

			TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA,

			TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,

			TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA,

			TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,

			TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,

			TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,

			TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,

			TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA,

			TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,

			TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA,

			TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,

			TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_256_GCM_SHA384,

			TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,

			TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_DSS_WITH_AES_256_GCM_SHA384,

			TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256,

			TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,

			TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_DSS_WITH_AES_128_GCM_SHA256

			

Disabling DTLS 1.0

NOTE: This change has already been made in JDK 20 and later releases; DTLS is not available in releases prior to JDK 9.

To test the changes before they take affect, edit conf/security/java.security and add DTLS 1.0 to the jdk.tls.disabledAlgorithms property by appending "DTLSv1.0".

For example, if the current value is:

jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA, \


				DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL

then the new value would be:

jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA, \


				DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, DTLSv1.0

This is considered a low-risk change, given that the affected releases already implement and should be able to negotiate up to DTLS 1.2 if the other party in the exchange also supports the newer DTLS version.

Disabling non-NIST Suite B EC curves when negotiating TLS sessions

The following named elliptic curves will be removed from the default list of enabled named groups for TLS:
sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, secp256k1.

These are older, rarely used curves that have been deprecated and are no longer recommended for use with TLS. For more information, see section 5.1.1 of RFC 8422 [https://tools.ietf.org/html/rfc8422] and Appendix B.3.1.4 of RFC 8446 [https://tools.ietf.org/html/rfc8446].

To test this change, use the jdk.tls.namedGroups system property to set the list of groups that are enabled by default and remove the deprecated curves from that list. The jdk.tls.namedGroups property contains a comma-separated list within quotation marks of enabled named groups in preference order. The list of default named groups varies depending on what JDK release you are using. Set it on your Java command-line, as follows:

For JDK 13:

$ java -Djdk.tls.namedGroups="secp256r1, secp384r1, secp521r1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, secp256k1, ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192" <rest of the command line>

For JDK 7 and 8:

$ java -Djdk.tls.namedGroups="secp256r1, secp384r1, secp521r1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, secp256k1" <rest of the command line>

				

Disabling the TLS EXPORT cipher suites

For JDK 8 and earlier, edit lib/security/java.security and add the EXPORT cipher suites to the jdk.tls.disabledAlgorithms property by appending

DES40_CBC, RC4_40

				

In JDK 9, java.security has been moved to conf/security/java.security

For example, if the current value is:

jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize  < 1024, \


				   EC keySize  < 224
				

jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 1024, \


			       EC keySize < 224,DES40_CBC, RC4_40 

				

Disabling RC4 cipher suites for TLS

On JDK 7, edit lib/security/java.security and add the RC4 cipher suites to the jdk.tls.disabledAlgorithms property by appending

RC4

				

(or replacing RC4_40 with RC4).

For example, if the current value is:

jdk.tls.disabledAlgorithms=SSLv3, DES, MD5withRSA, DH keySize < 1024, \


				   EC keySize < 224, RC4_40, 3DES_EDE_CBC
				

jdk.tls.disabledAlgorithms=SSLv3, DES, MD5withRSA, DH keySize < 1024, \


				   EC keySize < 224, RC4, 3DES_EDE_CBC
				

Disabling 3DES and RC4 in Kerberos

Note that this change has already been made in JDK 17 and later releases.

The des3-hmac-sha1 and rc4-hmac Kerberos encryption types (etypes) will be disabled by default. These two encryption types are considered weak and were deprecated (RFC 8429) in 2018.

To test, make the following changes to the krb5.conf configuration file on your system. You can also set the java.security.krb5.conf system property to the location of an alternate krb5.conf file to be used by your Java application instead of the default.

• Remove des3-hmac-sha1 and rc4-hmac from the default_tkt_enctypes, default_tgs_enctypes, and permitted_enctypes settings of the [libdefaults] section of the krb5.conf configuration file on your system.
• If any of the above settings are not defined, set each of their values to aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 aes256-cts-hmac-sha384-192 aes128-cts-hmac-sha256-128.
• If the allow_weak_crypto setting is defined, make sure it is set to false. If it is not defined, it does not need to be set, as the default value is false.

Changing the minimum EC Key Length for XML Signatures

Changing minimum key length for XML signatures

Set minimum key length requirement for JARs signed with DSA/RSA

For JDK 8 and earlier, edit lib/security/java.security and add the desired length to the jdk.jar.disabledAlgorithms property by appending "RSA keySize < min keylength" or "DSA keySize < min keyLength"

In JDK 9, java.security has been moved to conf/security/java.security

For example, if the current value is:

jdk.jar.disabledAlgorithms=MD2, RSA keySize < 1024

				
				

jdk.jar.disabledAlgorithms=MD2, RSA keySize < 2048

				
				

If no value is set for RSA keySize, just append it at the end of the property after a comma.

To check if a weak algorithm or key was used to sign a JAR file you must use JDK 8u111, 7u121, 6u131, or later. After configuring the java.security file, you can use the jarsigner binary that ships with the JDK. Running jarsigner ‑verify ‑J‑Djava.security.debug=jar on a JAR file signed with a weak algorithm or key will print more information about the disabled algorithm or key.

Location of java.security configuration file

java.security file is located in:

<java-home>/conf/security/ in JDK 9 and later

<java-home>/lib/security/ in JDK 8 and earlier