为什么Java Web Start说签名的jar文件是未签名的？

Question

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
$ jar tf dynaccn.jar
META-INF/MANIFEST.MF
META-INF/IDV.SF
META-INF/IDV.RSA
META-INF/
edu/
edu/ucar/
edu/ucar/unidata/
edu/ucar/unidata/dynaccn/
App$1.class
...
$ jarsigner -verbose -certs -verify dynaccn.jar
       28325 Tue Aug 17 09:41:58 MDT 2010 META-INF/MANIFEST.MF
       28404 Tue Aug 17 09:41:58 MDT 2010 META-INF/IDV.SF
        2880 Tue Aug 17 09:41:58 MDT 2010 META-INF/IDV.RSA
           0 Tue Aug 17 09:41:58 MDT 2010 META-INF/
           0 Mon Aug 16 10:10:34 MDT 2010 edu/
           0 Mon Aug 16 10:10:34 MDT 2010 edu/ucar/
           0 Mon Aug 16 10:10:34 MDT 2010 edu/ucar/unidata/
           0 Mon Aug 16 10:10:34 MDT 2010 edu/ucar/unidata/dynaccn/
...
sm       486 Mon Aug 16 10:10:34 MDT 2010 App$1.class

      X.509, CN=University Corporation for Atmospheric Research, OU=UNIDATA, O=University Corporation for Atmospheric Research, L=Boulder, ST=Colorado, C=US
      [certificate will expire on 2/6/11 4:59 PM]
      X.509, CN=Thawte Code Signing CA, O=Thawte Consulting (Pty) Ltd., C=ZA
      [certificate is valid from 8/5/03 6:00 PM to 8/5/13 5:59 PM]
      [KeyUsage extension does not support code signing]
      X.509, EMAILADDRESS=premium-server@thawte.com, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA
      [certificate is valid from 7/31/96 6:00 PM to 12/31/20 4:59 PM]
      [CertPath not validated: null]
...
jar verified.

Warning: 
This jar contains entries whose signer certificate's KeyUsage extension doesn't allow code signing.
This jar contains entries whose signer certificate will expire within six months. 
This jar contains entries whose certificate chain is not validated.
This jar contains signed entries that's not signed by alias in this keystore.

and both JWS and my browser have a certificate for "Thawte Premium Server CA".

The problem occurs even if the JWS cache and the browser download area are empty.

I don't believe the "KeyUsage" message is relevant because 1) the same certificate chain is used for another application that does launch successfully; and 2) documentation I've read indicates that the Thawte Code Signing CA is only used to verify the UNIDATA certificate and not to sign code.

My environment is Linux 2.6.27.41-170.2.117.fc10.x86_64, Firefox 3.6.8 (i686), and Java 1.7.0-ea.

Why won't this application launch?

UPDATE: I've discovered that the application launches if the "codebase" attribute in the JNLP file references a local directory but not if it references a URL that lies behind user authentication. In the latter case, javaws(1) interprets the authentication webpage as a JNLP file (with obvious results) if invoked from the command-line. If invoked by the "deployJava" script from a user-authenticating webpage (so that the browser has a session cookie), then javaws(1) says that the application isn't signed. I find both of these failure modes odd as the javaws(1) documentation says that it understands user authenticating web pages and the jar file is signed.

Answer 1

I'm on Gentoo Linux, running OpenJDK 7, and I think I experienced the same problem.

I could not get it to work with OpenJDK 7. Only re-signing with a release of the Sun Java 6 JDK ultimately signed the application correctly. (I also re-built it all due to it being managed by ant, I don't know if that is necessary, though).

Merely switching to the official JDK 6 without rebuilding only makes the "[CertPath not validated: null]" warning when varifying with "jarsigner -verify -verbose -certs" disappear, but does not appear to work in the application I ultimately use.

Answer 2

1. make sure you are not using a cached (unsigned) version of the jar. Clean the temp folder where JWS downloads jars
2. make sure that all dependencies (jars) of your jar, that require special permissions, are also signed

Answer 3

Make sure you wrap your calls in the applet with a doPrivileged block. I am unsure why it works like this but seems to work like a charm.