2010-08-17 7 views
13

Java Web Start (JWS) dit qu'il ne peut pas lancer mon application car le fichier jar est non signé:Pourquoi Java Web Start indique-t-il qu'un fichier jar signé est non signé?

Error: Unsigned application requesting unrestricted access to system 
     Unsigned resource: .../dynaccn.jar 

Mais le fichier jar est signé:

$ 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, [email protected], 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. 

et les deux JWS et mon navigateur possède un certificat pour "Thawte Premium Server CA".

Le problème se produit même si le cache JWS et la zone de téléchargement du navigateur sont vides.

Je ne crois pas que le message "KeyUsage" soit pertinent parce que 1) la même chaîne de certificats est utilisée pour une autre application qui démarre correctement; et 2) la documentation que j'ai lue indique que l'AC de signature de code Thawte est seulement utilisée pour vérifier le certificat UNIDATA et non pour signer le code.

Mon environnement est Linux 2.6.27.41-170.2.117.fc10.x86_64, Firefox 3.6.8 (i686) et Java 1.7.0-ea.

Pourquoi cette application ne démarre-t-elle pas? MISE À JOUR: J'ai découvert que l'application se lance si l'attribut "codebase" dans le fichier JNLP fait référence à un répertoire local mais pas s'il fait référence à une URL derrière l'authentification de l'utilisateur. Dans ce dernier cas, javaws (1) interprète la page Web d'authentification comme un fichier JNLP (avec des résultats évidents) si elle est invoquée à partir de la ligne de commande. Si elle est invoquée par le script "deployJava" à partir d'une page Web authentifiant l'utilisateur (de sorte que le navigateur dispose d'un cookie de session), alors javaws (1) indique que l'application n'est pas signée. Je trouve ces deux modes de défaillance impairs car la documentation de javaws (1) indique qu'elle comprend l'authentification des pages web par l'utilisateur et que le fichier jar est signé.

+1

Comment signez-vous votre fichier jar? J'ai rencontré ce type de problèmes lors de l'utilisation de la tâche signjar dans fourmi où l'attribut paresseux était défini sur true. La suppression de l'attribut 'lazy = true' à peu près fait disparaître les problèmes. – Pram

+0

@Pram J'utilise cette entrée ant (1): . L'attribut "paresseux" n'est pas utilisé. –

Répondre

3

Je suis sur Gentoo Linux, sous OpenJDK 7, et je pense avoir rencontré le même problème.

Je ne pouvais pas le faire fonctionner avec OpenJDK 7. Seule une nouvelle signature avec une version de Sun Java 6 JDK a finalement signé l'application correctement. (Je l'ai aussi reconstruit parce qu'il était géré par une fourmi, mais je ne sais pas si c'est nécessaire).

Le passage simple au JDK 6 officiel sans reconstruction ne fait disparaître que l'avertissement "[CertPath non validé: null]" lorsque la variable "jarsigner -verify -verbose -certs" disparaît, mais ne semble pas fonctionner dans l'application I finalement utiliser.

2
  1. assurez-vous de ne pas utiliser une version en cache (non signée) du fichier jar. Nettoyez le dossier temp où JWS downloads jars
  2. assurez-vous que toutes les dépendances (pots) de votre pot, qui requièrent des autorisations spéciales, sont également signées
+0

Le problème se produit même si le cache JWS est vide. Il n'y a qu'un seul fichier jar et il contient seulement des classes. –

0

Assurez-vous que vous enveloppez vos appels dans l'applet avec un bloc doPrivileged. Je ne suis pas sûr pourquoi cela fonctionne comme ça mais semble fonctionner comme un charme.

+0

L'application est autonome: ce n'est pas une applet. –

Questions connexes