The most recent updates to Java 8 (OpenJDK 8u362 or Oracle Java 8u351) no longer recognizes SHA-1 at various levels involved in signing and verifying JAR files. This will prevent "old" LOCKSS plugins from validating and loading in the LOCKSS system (1.x or 2.x), which in turn will prevent archival units (AUs) using the affected plugins from becoming active. By "old" LOCKSS plugins, what is meant is either plugins built and signed somewhat long ago (with SHA-1 checksums), or plugins built and signed using plugin signing keys created somewhat long ago (with SHA-1 components).

The first clue that a plugin in your network is affected is that the plugin and its archival units (AUs) are no longer active in the system without any particular cause, other than a recent Java 8 upgrade on the host system. This can be accompanied by another clue in the LOCKSS system log, in the form of error messages similar to this:

00:11:24.205: Error: 1-PluginMgr: Plugin jar did not validate: http://props.example.com/network/plugins/Plugin.jar: org.lockss.util.JarValidator$JarValidationException: Jar entry com/example/plugin/PluginHtmlFilter.class is not signed. Unsigned entries are not allowed.

The most general way to find which plugin JAR files are affected is to use jarsigner, a tool included in the Java Development Kit (JDK), to inspect the signed JAR files in a plugin registry:

jarsigner -verify -verbose -certs -keystore /path/to/signing.keystore /path/to/Plugin.jar

Replace /path/to/Plugin.jar with the path to a plugin JAR file you wish to inspect. Replace /path/to/signing.keystore with a path to the plugin signing keystore used in your network; if your network uses plugins signed by the LOCKSS team, download the plugin signing keystore that ships with the LOCKSS software from https://github.com/lockss/lockss-daemon/raw/master/src/org/lockss/plugin/lockss.keystore and use a path to this downloaded file.

The end of the jarsigner output will look similar to this (optionally followed by one or more warning messages):

  s = signature was verified 
  m = entry is listed in manifest
  k = at least one certificate was found in keystore
  i = at least one certificate was found in identity scope

- Signed by "CN=First Last, O=Organization, OU=Organizational Unit, L=Location, ST=California, C=US"
    Digest algorithm: SHA-256
    Signature algorithm: SHA256withDSA, 2048-bit key

jar verified.

• The Signature algorithm line gives clues about the signing key used to sign the JAR file. If the algorithm used involves SHA-1, for instance SHA1withDSA, the plugin is affected and will not validate in the most recent versions of Java 8.

• The Digest algorithm line gives clues about the checksums used to sign the JAR file. If the algorithm used is SHA-1, the plugin is affected and will not validate in the most recent versions of Java 8.

• If there is more than Digest algorithm or Signature algorithm line (either because there is more than one signer or because a signer has multiple Digest algorithm or Signature algorithm entries), we believe the plugin is affected and will not validate in the most recent versions of Java 8 if any Digest algorithm or Signature algorithm line involves SHA-1, even if all the others are recognized. This means that re-signing a plugin JAR to add additional Digest algorithm or Signature algorithm lines to its existing set is not sufficient to resolve this issue.

• Warnings about 1024-bit DSA signing keys, for instance Signature algorithm: SHA256withDSA, 1024-bit key (weak) or Warning: The DSA signing key has a keysize of 1024 which is considered a security risk. This key size will be disabled in a future update. are worth thinking about but are not related to this issue; what matters in this case is that the Digest algorithm and Signature algorithm do not involve SHA-1.

• The warning This jar contains entries whose certificate chain is invalid. Reason: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target (or similar) indicates that the JAR file being inspected is not signed by a key found in the signing keystore supplied with the -keystore option. Please check that you are providing the keystore used in your network to sign the plugin JAR.

The following shell loop can be used to quickly try a group of plugin JAR files and output those that are likely affected, replacing /path/to/signing.keystore as above, and replacing /path/to/plugins/*.jar with one or more shell patterns corresponding to your plugin JARs:

for j in /path/to/plugins/*.jar ; do
  jarsigner -verify -verbose -certs -keystore /path/to/signing.keystore "$j" |
      grep -qiP 'Digest algorithm: SHA-?1|Signature algorithm: SHA-?1with' &&
      echo "$j"
done

The solution is to rebuild, re-sign and re-release affected plugins, using a reasonably recent version of Java 8 and a plugin signing key that is not affected. Ideally you should increment the value plugin_version key in the plugin XML source. If a plugin does not currently have a plugin_version block, it is as if it had a plugin_version block for version 1, so you should add a plugin_version block for version 2:

  <entry>
    <string>plugin_version</string>
    <string>2</string>
  </entry>

The LOCKSS Team has taken care of this repackaging in the Global LOCKSS Network (GLN) and in LOCKSS networks we manage.

Please contact the LOCKSS team for assistance with this process.