JEP 288: Disable SHA-1 Certificates

OwnerSean Mullan
Created2016/02/10 15:18
Updated2016/10/19 21:43
Componentsecurity-libs /
Discussionsecurity dash dev at openjdk dot java dot net
Reviewed byAndrew Gross, Brian Goetz
Endorsed byBrian Goetz


Improve the default security configuration of the JDK by disabling X.509 certificate chains with SHA-1 based signatures.


It is not a goal to disable all SHA-1 certificates. Some SHA-1 certificates may be permitted if they satisfy additional criteria; see the Description section for more details.

Also, it is not a goal to disable all usages of SHA-1 certificates. Only X.509 certificate chains that are validated by the PKIX implementation of the CertPathValidator and CertPathBuilder APIs and the SunX509 and PKIX implementations of the TrustManagerFactory API are subject to the restrictions. Other usages (parsing, etc.) of X.509 certificates in the JDK are not affected. Third-party implementations of CertPathValidator, CertPathBuilder, and TrustManagerFactory are directly responsible for enforcing their own restrictions.


The use of SHA-1 based digital signature algorithms is increasingly a security concern due to the risk of collision attacks. NIST recommends in SP 800-57, Part 1 that SHA-1 should no longer be used to apply digital signatures to data. The CA/Browser Forum's Baseline Requirements for Publicly-Trusted SSL Certificates state that as of 1 January 2016, Certificate Authorities must not issue any subordinate CA or subscriber certificates using SHA-1. Other software vendors (Google, Microsoft, Mozilla) have published plans to deprecate SHA-1 in certificates. In the JDK, X.509 certificate chains are used for authentication of servers and clients in TLS and for verifying the integrity and authors of signed code. Thus, it is important that we provide a default configuration that includes protection against the security risks of SHA-1 certificates.


The prevalence of SHA-1 certificates continues to decrease, but is still high enough that disabling all SHA-1 certificates could break many applications (as of October 3, 2016, 3.4% of popular SSL websites still use SHA-1). Furthermore, many enterprises use private Certificate Authorities that need more time to adjust to the restrictions. Additionally, code that has been previously signed and timestamped with SHA-1 certificates should continue to work for some time into the future. Therefore, to reduce the compatibility risk, SHA-1 certificates will be disabled as follows:

  1. For each of the certificate types described below, the certificate chain that includes the SHA-1 certificate(s) must be anchored by a trust anchor that is pre-installed in the JDK cacerts keystore. This condition does not apply to certificate chains that are anchored by other certificates, including those that are subsequently added to the cacerts keystore. Also, note that the restriction does not apply to SHA-1 trust anchor certificates, since they are directly trusted.

  2. As of January 1, 2017, any TLS client or server certificate chain containing a SHA-1 certificate (end-entity or intermediate CA) will be blocked.

  3. For signed code that is not timestamped, as of January 1, 2017, the code signer's certificate chain will be blocked if it contains a SHA-1 certificate (end-entity or intermediate CA).

  4. For signed code that is timestamped before January 1, 2017, the code signer or Time Stamping Authority (TSA) certificate chain will not be blocked if it contains a SHA-1 certificate. However, this condition does not necessarily mean the timestamped code will be acceptable indefinitely, as it may be restricted at a future date to protect against new attacks on SHA-1. For signed code that is timestamped on or after January 1, 2017, any SHA-1 certificate (end-entity or intermediate CA) in the code signer or TSA certificate chain will cause it to be blocked.

  5. As of January 1, 2017, certificate chains containing SHA-1 certificates (end-entity or intermediate CA) for the following certificate types will also be blocked: OCSP Signing and CRL Signing.

The SHA-1 restrictions will be enforced in the PKIX implementation of the and APIs, and the SunX509 and PKIX implementations of the API.

The constraints can be removed or adjusted by editing the jdk.certpath.disabledAlgorithms security property in the file. A constraint named "jdkCA" will be defined to limit the restrictions to certificates that are anchored by a trust anchor that is pre-installed in the JDK cacerts file (see condition #1 above). A constraint named "denyAfter" will be defined to specify the date that the restrictions will take affect.

When SHA-1 certificates are disabled, the entry for the jdk.certpath.disabledAlgorithms security property will be adjusted as follows:

jdk.certpath.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, \
        DSA keySize < 1024, SHA1 jdkCA & denyAfter 2017-01-01

Here, SHA-1 has been disabled by adding the constraint "SHA1 jdkCA & denyAfter 2017-01-01".


Many security library regression tests currently use SHA-1 certificates. These will be modified to re-enable SHA-1 or alternatively, the certificates will be replaced with SHA-2 certificates.

Risks and Assumptions

The Description section outlined additional constraints that will help mitigate the compatibility risk for certain use cases. We will also be working to communicate the changes via other forums and programs to help make sure that users are aware of and prepare for the forthcoming changes. However, these restrictions may need to be further relaxed or adjusted accordingly if certain unexpected issues arise that significantly affect compatibility. Alternatively, if new attacks on SHA-1 are discovered which further weaken it, the constraints may need adjustments to be more strict.


This JEP depends upon two enhancements to the existing algorithm-constraints mechanism (8140422, 8154005).