2010-08-17 25 views
13

Java Web Start (JWS) mówi, że nie można uruchomić aplikacji, ponieważ mój plik jar jest niepodpisany:Dlaczego Java Web Start mówi, że podpisany plik JAR nie jest podpisany?

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

ale plik jar jest podpisali:

$ 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. 

i zarówno JWS a moja przeglądarka ma certyfikat "Thawte Premium Server CA".

Problem występuje nawet wtedy, gdy pamięć podręczna JWS i obszar pobierania przeglądarki są puste.

Nie wierzę, że komunikat "KeyUsage" ma znaczenie, ponieważ 1) ten sam łańcuch certyfikatów jest używany dla innej aplikacji, która pomyślnie się uruchamia; oraz 2) dokumentacja, którą przeczytałem, wskazuje, że Urząd Podpisywania Kodu Thawte służy jedynie do weryfikacji certyfikatu UNIDATA, a nie do podpisania kodu.

Moje środowisko to Linux 2.6.27.41-170.2.117.fc10.x86_64, Firefox 3.6.8 (i686) i Java 1.7.0-ea.

Dlaczego ta aplikacja nie zostanie uruchomiona?

AKTUALIZACJA: Odkryłem, że aplikacja uruchamia się, jeśli atrybut "codebase" w pliku JNLP odwołuje się do lokalnego katalogu, ale nie, jeśli odwołuje się do adresu URL, który leży za uwierzytelnianiem użytkownika. W tym drugim przypadku javaws (1) interpretuje stronę uwierzytelniającą jako plik JNLP (z oczywistymi wynikami), jeśli wywoływana jest z wiersza polecenia. Jeśli wywołany przez skrypt "deployJava" z strony uwierzytelniającej użytkownika (tak, że przeglądarka ma plik cookie sesji), to javaws (1) mówi, że aplikacja nie jest podpisana. Oba te tryby niepowodzenia są dziwne, ponieważ dokumentacja javaws (1) mówi, że rozumie strony uwierzytelniające użytkownika, a plik jar jest podpisany.

+1

W jaki sposób podpisujesz plik JAR? Doświadczyłem tego rodzaju problemów podczas używania zadania signjar na ant, gdzie atrybut leniwy został ustawiony na wartość true. Usunięcie atrybutu 'lazy = true' sprawiło, że problemy zniknęły. – Pram

+0

@Pram Używam tego wpisu ant (1): . Atrybut "leniwy" nie jest używany. –

Odpowiedz

3

Jestem na Gentoo Linux, z systemem OpenJDK 7, i myślę, że doświadczyłem tego samego problemu.

Nie udało mi się uruchomić go z OpenJDK 7. Tylko ponowne podpisanie z wydaniem Sun Java 6 JDK ostatecznie poprawnie podpisało wniosek. (Zrekonstruowałem też wszystko z powodu zarządzania przez mrówkę, nie wiem, czy to konieczne).

Zwykłe przejście na oficjalny JDK 6 bez przebudowywania powoduje tylko, że ostrzeżenie "[Nieprawidłowe działanie programu CertPath: null]" zostanie zmienione z "jarsigner -verify -verbose -certs", ale nie działa w aplikacji I ostatecznie użyć.

2
  1. Upewnij się, że nie używasz buforowanej (niepodpisanej) wersji słoika. Oczyść folder temp gdzie JWS downloads jars
  2. upewnić się, że wszystkie zależności (słoiki) z twego dzbana, które wymagają specjalnych uprawnień, są również podpisane
+0

Problem występuje nawet wtedy, gdy pamięć podręczna JWS jest pusta. Jest tylko jeden plik jar i zawiera tylko klasy. –

0

Upewnij się owinąć połączeń w aplecie z bloku doPrivileged. Nie jestem pewien, dlaczego tak działa, ale wydaje się działać jak urok.

+0

Aplikacja jest samodzielna: nie jest apletem. –