Damian Nowak is a CEO at Virtkick. He's a Ruby coder, an Arch Linux hacker, and drinks good beer.
You are developing a secure Java Web Start (JNLP) application, you sign JARs with
you have a valid certificate but some people still get
Found unsigned entry in resource error message
although your JARs are signed and
jarsigner -verify accepts them. Did you encounter this problem too?
Exact error message in applet console:
#### Java Web Start Error: #### Found unsigned entry in resource: http://my.spartez.com/download/screensnipe/jdom-1.0.jar com.sun.deploy.net.JARSigningException: Found unsigned entry in resource: http://my.spartez.com/download/screensnipe/jdom-1.0.jar at com.sun.javaws.security.SigningInfo.getCommonCodeSignersForJar(SigningInfo.java:411) at com.sun.javaws.security.SigningInfo.check(SigningInfo.java:292) at com.sun.javaws.LaunchDownload.checkSignedResourcesHelper(LaunchDownload.java:1741) at com.sun.javaws.LaunchDownload.checkSignedResources(LaunchDownload.java:1508) at com.sun.javaws.Launcher.prepareResources(Launcher.java:1232) at com.sun.javaws.Launcher.prepareAllResources(Launcher.java:621) at com.sun.javaws.Launcher.prepareToLaunch(Launcher.java:327) at com.sun.javaws.Launcher.prepareToLaunch(Launcher.java:199) at com.sun.javaws.Launcher.launch(Launcher.java:116) at com.sun.javaws.Main.launchApp(Main.java:416) at com.sun.javaws.Main.continueInSecureThread(Main.java:248) at com.sun.javaws.Main$1.run(Main.java:110) at java.lang.Thread.run(Thread.java:662)
I googled for it and found this topic. It turns out that disabling Java plugin caching is sometimes a cause of this problem. Just enable Java plugin caching and the problem is gone.
However, because you encountered this problem, you probably want the caching disabled. Applet and Web Start developers tend to disable cache so that they always get a current version of application. How to make the Java Web Start application working with disabled cache?
In my case, application consists of five signed JARs: screensnipe-1.5-rc3.jar, forms-1.2.1.jar, jdom-1.0.jar,
jide-oss-2.5.8.jar and jhlabs-filters.jar. Java claims that JDOM JAR is unsigned, others are fine. I took a look
at the JAR for something distinctive that can cause this particular JAR to fail verification.
Filename length was considered, JARs order in JNLP file, existence of classes in root package, META-INF/ directory
content and so on. It was
META-INF/MANIFEST.MF file that contained something that Java Web Start verifier failed on.
Name: org/jdom/output/ Implementation-Vendor: jdom.org Implementation-Title: org.jdom.output Implementation-Version: 1.0 Specification-Vendor: jdom.org Specification-Title: JDOM Output Classes Specification-Version: 1.0 Name: org/jdom/transform/ (...)
Removing directory entries from Manifest file made it working. Woah. Note: Manifest file is valid - Java Web Start verifier just fails on signed directories when caching is disabled.
I encountered this problem while developing a ScreenSnipe, an awesome screenshot tool that integrates seamlessly with Atlassian JIRA and Confluence. All AtlasHost customers get it preinstalled in their instance. Others can try out ScreenSnipe by grabbing it from Atlassian Plugin Exchange or installing via Atlassian Plugin Manager in your JIRA/Confluence.