问题描述
快速背景：我们发布了一个webstart应用程序，其中包括我们自己的应用程序罐和众多第三方jar。 Webstart要求jnlp文件引用的所有分布式jar都由单个证书签名。因此，我们使用自签名证书签署所有罐子（我们的罐子和第三方罐子）。一些第三方罐子已经由生产它们的一方签署，但我们只是再次签署它们，这很好。直到现在。
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.
问题：我们最近从Java 6迁移到Java 7，突然webstart拒绝加载一些罐子，抱怨道：无效的SHA1签名文件摘要。这只发生在一些罐子而不是其他罐子上，并且那些失败的罐子似乎有多个签名。
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.
在搜索S.O.之后。在互联网上，似乎Java的jarsigner的默认签名算法在Java 6和Java 7之间已经发生了变化，从SHA1到SHA256，各种人都建议使用jarsigner -digestalg SHA1来解决验证问题。我试过了，果然我们的多重签名罐子验证了。所以这似乎是我们问题的一种解决方法。
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.
从我可以收集到的内容来看，第三方签名似乎是一个SHA1签名，我们正在签署默认值 - SHA256 - 导致签名混合。当我使用'-digestalg'开关强制SHA1时，我们有两个相同类型的签名，现在验证工作正常。所以似乎问题是由多个签名使用不同的算法引起的？或者是否还有其他因素我不知道。
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.
问题：
- 为什么使用SHA1 + SHA256无法验证，但是使用SHA1 + SHA1进行验证？有技术原因吗？安全政策的原因？为什么不能验证两个签名是否正确？
- 使用（继续使用）SHA1而不是现在默认的SHA256是否有任何缺点？
推荐答案
您可以为每个第三方创建单独的JNLP文件，而不是自己重新签名第三方jar文件指向相关jar文件的签名者，然后使用< extension> 元素让您的主JNLP依赖于这些。所有JAR文件必须由同一签名者签名的限制仅适用于一个JNLP，每个扩展可以有一个不同的签名者。
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.
如果不这样做，你可以删除添加自己的第三方签名（通过重新包装它们而不用 META-INF / *。{SF，DSA，RSA} ）
Failing that, you could strip out the third party signatures before adding your own (by repacking them without META-INF/*.{SF,DSA,RSA})
这篇关于什么阻止Java验证具有多个签名算法的签名jar的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！