Restrict JARs signed with algorithms using SHA-1 by default. This includes the JAR digest and signature algorithm, the timestamp digest algorithm, and the certificate chains of the code signer and Timestamp Authority. See below for exceptions.

Restricting signed JARs is more complicated than TLS, due to the higher risk of breaking code that has been previously timestamped and may be still in use. The jdk.certpath.disabledAlgorithms and jdk.jar.disabledAlgorithms security properties support a denyAfter constraint which can help mitigate this risk by only restricting SHA-1 JARs timestamped after a specific date, ex:

jdk.jar.disabledAlgorithms=SHA1 denyAfter 2020-04-02

The Root CAs included in the JDK that support code signing should all be issuing SHA-2 code signing certificates by default, although some may still allow SHA-1 to be requested, mainly for compatibility with older Windows systems that do not support SHA-2.

The compatibility risk of disabling SHA-1 JARs is much lower in JDK 11 and up, since signed applets and WebStart applications are not supported.

The current proposal is to disable SHA-1 JARs with the following exceptions:

  1. Any JAR signed and timestamped prior to January 01, 2019 is not restricted. This will allow SHA-1 JARs timestamped prior to this date and still in use to continue to work, but we encourage them to be replaced, as this exception will likely be removed in a future update.

  2. Any JAR signed with SHA-1 certificates that were not issued by (or chain back to) one of the Root CAs that are included in the JDK cacerts keystore is not restricted. Thus, if you are using a CA that is not included in the JDK you will not be affected. This is consistent with the TLS SHA-1 certificate restriction. But also like 1, this exception will likely be removed in a future update.