What prevents Java from verifying signed jars with multiple signature algorithms

java jar code-signing java-web-start jarsigner
JimN picture JimN · Sep 27, 2012 · Viewed 8.7k times · Source

Quick background: We release a webstart application, which includes our own application jars and numerous third-party jars. Webstart requires that all distributed jars referred to by the jnlp file be signed by a single certificate. We therefore sign all jars (our jars and the third-party jars) using a self-signed certificate. Some third-party jars are already signed by the party which produced them, but we just sign them again, and this works fine. Until now.

Problem: We recently moved from Java 6 to Java 7, and suddenly webstart is refusing to load some jars, complaining: "Invalid SHA1 signature file digest". This only happens for some jars and not others, and the common thread appears among those jars that fail appears to be having multiple signatures.

After searching around on S.O. and the internet, it appears that the default signature algorithm for Java's jarsigner has changed between Java 6 and Java 7, from SHA1 to SHA256, and various people are recommending using "jarsigner -digestalg SHA1" to work around verification issues. I tried that, and sure enough our multiply-signed jars now verify. So this appears to be a workaround for our issue.

From what I can gather, it appears that the third-party signature is a SHA1 signature, and we were signing with the default -- SHA256 -- resulting in a mixing of signatures. When I force SHA1 using the '-digestalg' switch, we have two signatures of the same type, and verification now works. So it seems the problem is caused by having multiple signatures with different algorithms? Or is there some other factor I'm missing.

Questions:

  1. Why does it fail to verify with SHA1 + SHA256, but verifies with SHA1 + SHA1? Is there a technical reason? A security policy reason? Why can't it verify that both signatures are correct?
  2. Is there any drawback to us using (continuing to use) SHA1 instead of the now-default SHA256?

Answer

Ian Roberts picture Ian Roberts · Sep 27, 2012

Rather than re-signing the third party jars yourself, you can create a separate JNLP file for each third-party signer that refers to the relevant jar files, then have your main JNLP depend on these using the <extension> element. The restriction that all JAR files must be signed by the same signer only applies within one JNLP, each extension can have a different signer.

Failing that, you could strip out the third party signatures before adding your own (by repacking them without META-INF/*.{SF,DSA,RSA})

Related questions

Why does Java Web Start say a signed jar file is unsigned?

Java Web Start (JWS) says that it can't launch my application because the jar file is unsigned: Error: Unsigned application requesting unrestricted access to system Unsigned resource: .../dynaccn.jar But the jar file is signed: $ jarsigner -keystore ... dynaccn.jar idv $ …

Read More
How to validate if a signed jar contains a timestamp?

After a jar is signed and the -tsa option was used, how can I validate that the time stamp was included? I tried: jarsigner -verify -verbose -certs myApp.jar But the output does not specify anything about the time stamp. …

Read More
Can't execute jar- file: "no main manifest attribute"

I have installed an application, when I try to run it (it's an executable jar) nothing happens. When I run it from the commandline with: java -jar "app.jar" I get the following message: no main manifest attribute, in "app.…

Read More