What prevents Java from verifying signed jars with multiple signature algorithms

Question

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 1

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})

Answer 2

I know this is a bit late - but we are going thru this now. Our problem was the "MD2withRSA" signing issue. I resolved the problem in a couple steps:

1) Worked with Verisign to remove the 'old' algorithm from our certificate - so the MD2withRSA algorithm was no longer used to sign our jars.

2) We also have a pile of 3rd party jars and we just re-sign them with out our certificate. We encountered the 'not all jars signed with the same certificate' when both the SHA1 and SHA-256 algorithms were listed in the MANIFEST.MF. This was just a small subset of the jars - so for those, we removed the bottom half of the MANIFEST.MF file; that part with the Name: class and the algorithm spec. That data is re-generated in the last part of our process. We unzip, exclude the old signing info and re-jar. Last step is to re-sign the jars. We found that in some cases, if the old Name: entry with the SHA1 entry was in the MANIFEST.MF, that the signing did not replace it with the SHA-256 - so we manually handle those jars (for now). Working on updating our Ant tasks to handle this.

Sorry - can't speak to why web start doesn't handle/allow it - just figured out how to make it work!

Good Luck!