JDK-8177285 : Release Note: Disable SHA-1 TLS Server Certificates
  • Type: Sub-task
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 6u161,7u151,8u141
  • Priority: P4
  • Status: Closed
  • Resolution: Delivered
  • Submitted: 2017-03-20
  • Updated: 2017-10-05
  • Resolved: 2017-07-18
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7 JDK 8
6u161Resolved 7u151Resolved 8u141Resolved
Description
Any TLS server certificate chain containing a SHA-1 certificate (end-entity or intermediate CA) and anchored by a root CA certificate included by default in Oracle's JDK is now blocked by default. TLS Server certificate chains that are anchored by enterprise or private CAs are not affected. 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. Third-party implementations of these APIs are directly responsible for enforcing their own restrictions. 

To implement this restriction and provide more flexibility for configuring your own restrictions, additional features have been added to the `jdk.certpath.disabledAlgorithms` and `jdk.jar.disabledAlgorithms` Security Properties in the java.security file, as follows:

- `jdk.certpath.disabledAlgorithms`:

   Three new constraints have been added to this Security Property:

   A new constraint named `jdkCA`, that when set, restricts the algorithm if it is used in a certificate chain that is 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 trust anchor certificates, since they are directly trusted.

   A new constraint named `denyAfter`, that when set, restricts the algorithm if it is used in a certificate chain after the specified date. The restriction does not apply to trust anchor certificates, since they are directly trusted. Also, code signing certificate chains as used in signed JARs are treated specially as follows:

   - if the certificate chain is used with a signed JAR that is not timestamped, it will be restricted after the specified date

   - if the certificate chain is used with a signed JAR that is timestamped, it will not be restricted if it is timestamped before the specified date. If the JAR is timestamped after the specified date, it will be restricted.

   A new constraint named `usage`, that when set, restricts the algorithm if it is used in a certificate chain for the specified use(s). Three usages are initially supported: `TLSServer` for TLS/SSL server certificate chains, `TLSClient` for TLS/SSL client certificate chains, and `SignedJAR` for certificate chains used with signed JARs.

Multiple constraints can be combined to constrain an algorithm when delimited by '&'.  For example, to disable SHA-1 TLS Server certificate chains that are anchored by pre-installed root CAs, the constraint is "SHA1 jdkCA & usage TLSServer".
  
- `jdk.jar.disabledAlgorithms`:

   A new constraint has been added named `denyAfter`, that when set, restricts the algorithm if it is used in a signed JAR after the specified date, as follows:

   - if the JAR is not timestamped, it will be restricted (treated as unsigned) after the specified date

   - if the JAR is timestamped, it will not be restricted if it is timestamped before the specified date. If the JAR is timestamped after the specified date, it will be restricted.

   For example, to restrict SHA1 in JAR files signed after January 1st 2018, add the following to the property:  "SHA1 denyAfter 2018-01-01".  The syntax is the same as the certpath property, however certificate checking will not be performed by this property.

Comments
In the third para, the following sentence is missing some text: "SHA1's usage is checked through the certificate chain, but the chain must terminate at a marked trust anchor is the cacerts keystore to be rejected." Is it supposed to be: "...at a marked trust anchor if the cacerts keystore is to be rejected."
19-06-2017

Issue is listed on the bug fixes list for 6u161, 7u151, and 8u141 as well as on the backports list in JDK-8176536. Added labels for 6u161 and 7u151 but need to verify 8u141 before adding that label.
19-05-2017