ti-enxame.com

jarsigner: Este jar contém entradas cuja cadeia de certificados não é validada

Estou tentando código assinar um arquivo JAR e estou usando o JDK 1.7u1. Adquirimos um certificado de assinatura de código GoDaddy e segui as instruções (Abordagem 1) aqui: http://help.godaddy.com/article/4780

O JAR assina bem, no entanto sempre que tento executar o comando: jarsigner -verify no meu JAR assinado usando o JDK 1.7u1, recebo a seguinte saída: 

s        180 Mon Dec 05 10:24:32 EST 2011 META-INF/MANIFEST.MF

      [entry was signed on 12/5/11 10:24 AM]
      X.509, CN=Removed Company Name, O=Removed Company Name, L=Removed City, ST=Removed State, C=US
      [certificate is valid from 12/2/11 4:30 PM to 12/2/13 4:30 PM]
      X.509, SERIALNUMBER=00000000, CN=Go Daddy Secure Certification Authority, OU=http://certificates.godaddy.com/repository, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
      [certificate is valid from 11/15/06 8:54 PM to 11/15/26 8:54 PM]
      X.509, OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US
      [certificate is valid from 6/29/04 1:06 PM to 6/29/34 1:06 PM]
      [CertPath not validated: null]

         342 Mon Dec 05 10:24:34 EST 2011 META-INF/JAVACSC.SF
        6180 Mon Dec 05 10:24:34 EST 2011 META-INF/JAVACSC.RSA
           0 Mon Dec 05 10:24:30 EST 2011 META-INF/
sm      2161 Wed Nov 30 10:23:20 EST 2011 C:/Users/Seth/Desktop/JAR/RunAppSF.class

      [entry was signed on 12/5/11 10:24 AM]
      X.509, CN=Removed Company Name, O=Removed Company Name, L=Removed City, ST=Removed State, C=US
      [certificate is valid from 12/2/11 4:30 PM to 12/2/13 4:30 PM]
      X.509, SERIALNUMBER=00000000, CN=Go Daddy Secure Certification Authority, OU=http://certificates.godaddy.com/repository, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
      [certificate is valid from 11/15/06 8:54 PM to 11/15/26 8:54 PM]
      X.509, OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US
      [certificate is valid from 6/29/04 1:06 PM to 6/29/34 1:06 PM]
      [CertPath not validated: null]


  s = signature was verified 
  m = entry is listed in manifest
  k = at least one certificate was found in keystore
  i = at least one certificate was found in identity scope

jar verified.

Warning: 
This jar contains entries whose certificate chain is not validated.

Eu também tentei o comando jarsigner -verify usando o mesmo JAR como acima no JDK 1.6u26 e 1.6u14 e ele voltou como sendo bom. (Saída abaixo de 1,6u26).

         180 Mon Dec 05 10:24:32 EST 2011 META-INF/MANIFEST.MF
         342 Mon Dec 05 10:24:34 EST 2011 META-INF/JAVACSC.SF
        6180 Mon Dec 05 10:24:34 EST 2011 META-INF/JAVACSC.RSA
           0 Mon Dec 05 10:24:30 EST 2011 META-INF/
sm      2161 Wed Nov 30 10:23:20 EST 2011 C:/Users/Seth/Desktop/JAR/RunAppSF.class

      [entry was signed on 12/5/11 10:24 AM]
      X.509, CN=Removed Company Name, O=Removed Company Name, L=Removed City, ST=Removed State, C=US
      [certificate is valid from 12/2/11 4:30 PM to 12/2/13 4:30 PM]
      X.509, SERIALNUMBER=00000000, CN=Go Daddy Secure Certification Authority, OU=http://certificates.godaddy.com/repository, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
      [certificate is valid from 11/15/06 8:54 PM to 11/15/26 8:54 PM]
      [KeyUsage extension does not support code signing]
      X.509, OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US
      [certificate is valid from 6/29/04 1:06 PM to 6/29/34 1:06 PM]


  s = signature was verified 
  m = entry is listed in manifest
  k = at least one certificate was found in keystore
  i = at least one certificate was found in identity scope

jar verified.

Estou faltando uma etapa extra que preciso fazer para obter o JAR assinado corretamente para o JDK 1.7?

44
Seth

Você está não faltando nada e você está definitivamente não sozinho com este problema. Após uma luta de quase 12 horas, descobri que a raiz do problema está na mistura de binários de JDK 1.7 com uma versão mais antiga de Java, como JRE-1.6. Para ser mais preciso, keytool vem com JRE, enquanto JDK é enviado com keytool e jarsigner.

Portanto, para resolver o problema, eu desinstalei completamente o JDK-1.7 do meu sistema e instalei JDK-1.6 Update 30. Agora, se eu fizesse jarsigner -verify -verbose -certs blah.jar, ele produziria jar verified sem qualquer aviso que acredito ser o que você espera.

48
gsbabil

Eu tenho tido o mesmo problema e, se puder ajudar os outros, o problema está em como o jarsigner encontra o keystore.

Para corrigir o problema, faça: 

jarsigner -verify -keystore xxxx.jks mysignedjar.jar
76
Alain P

É apenas um aviso que você pode ignorar.

Se você realmente não quiser ignorá-lo, informe ao jarsigner onde está seu keystore quando você verificar.

jarsigner -verbose -verify -keystore ${KEYSTORE_PATH} ${YOUR_JAR_FILE}

Este é apenas um novo recurso no JDK 7.

18
Daniele Segato

Eu tive um problema semelhante com o "DigiCert SHA2 Assured Code ID Assinatura CA". Todas as versões do Oracle Java, bem como o OpenJDK, se comportaram da mesma forma. O suporte do Digicert me redirecionou para esta página, mas nada aqui declarado me ajudou com o processo de verificação também.

Eu estou tentando assinar um applet, então eu preciso que ele seja verificável também no navegador, então o truque de fornecer o caminho do keystore para jarsigner-verify não é aplicável.

O principal problema parece ser um bug no keytool ao operar com certs usando SHA2 em vez de SHA1, porque a mesma lista de etapas aplicadas em certs SHA1 sempre funciona e nunca funcionou para SHA2 para mim. Parece-me que a keytool não é capaz de detectar a "chainability" de certificados importados para jks e, portanto, jarsigner não incorpora a cadeia de certs apropriada no jar assinado, existe apenas o certificado final armazenado no META-INF/myalias. Em vez disso, o arquivo RSA (verificável por openssl pkcs7-in myalias.RSA -print_certs -inform DER -out certs.crt).

Digicert sugeriu " ... às vezes vemos problemas com a raiz não sendo realmente importados corretamente ou totalmente na primeira vez, mas a execução de um comando de importação que aponta para a raiz novamente pode corrigir isso ", mesmo isso não ajudou em o meu caso.

Como não há como dizer explicitamente ao keytool o que os certs estão prestes a ser em uma cadeia, decidi construir uma cadeia usando openssl e importá-la assim:

cat TrustedRoot.pem DigiCertCA2.pem my.crt  >chain
openssl pkcs12 -nodes -export -in my.crt  -inkey my.key -out tmp.p12 -name myalias -certfile chain
keytool -importkeystore -destkeystore mykeystore.jks -srckeystore tmp.p12 -srcstoretype PKCS12

Depois disso mykeystore.jks parece conter apenas o meu certificado, não o DigiCertCA2 ou o Root quando listado pelo comando keytool -list, mas com -v (verbose) ele revela a profundidade da cadeia e seus certificados:

~/$ keytool  --list --keystore mykeystore.jks  -v|grep -e chain -e Certificate\\[
Enter keystore password:  123456
Certificate chain length: 3
Certificate[1]:
Certificate[2]:
Certificate[3]:

E é isso que o jarsigned precisa para assinar o jar corretamente, ou seja, para incorporar a cadeia de certs adequada e tornar o jar verificável também para o usuário final do navegador.

5
tomas

Descobri que a mensagem "Este frasco contém entradas cuja cadeia de certificados não é validada" também é impressa se você assinar o arquivo Jar usando o JRE 1.7.0_21 e o verificar com uma versão inferior do JRE 1.7.0. 

Conclusão: não é necessário fazer o downgrade para o Java 1.6, basta usar a mesma versão do jarsigner para assinatura e verificação.

2
lyaffe

Este é um mecanismo de segurança no JDK 7+. Isso imprime o aviso ao assinar jars sem timestamp, que pode ser passado com um sinalizador -tsa. Se um frasco não tiver registro de data e hora, ele deixará de funcionar após a data de validade.

Se você estiver criando um destino Android, esse aviso sempre será impresso se você estiver usando um JDK mais novo que 1.7.0_51. O Android geralmente recomenda uma validade de 30 anos, portanto, esse aviso pode ser 100% ignorado, a menos que o plano de negócios seja permitir que os usuários usem o mesmo .apk em 2046.

Aqui está o ingresso para o recurso, o objetivo é incentivar o registro de data e hora, o que, acredito, será eficaz. http://bugs.Java.com/view_bug.do?bug_id=8023338 .

2
mateor

Ao criar/exportar seu certificado para uma p12 (usada pelo jarsigner), certifique-se de que o seguinte está selecionado (por exemplo, se você exportar usando o assistente do Internet Explorer), precisará selecionar o seguinte no assistente de exportação.

"Exportar a chave privada" "Incluir todos os certificados no caminho de certificação, se possível" "Exportar todas as propriedades estendidas" marcadas com a opção .PFX ou PKCS # 12.

Se você criar o p12 adequadamente em primeiro lugar, o jarsign não requer nenhum esforço especial.

0
PGP

Se os seus certificados forem da Entrust, verifique se você está usando o certificado raiz mais recente.

http://www.entrust.net/knowledge-base/technote.cfm?tn=7875

Problema:

Você recebe uma mensagem de erro informando que a validação do certificado SLL Falhou devido a um campo Basic Restaints ausente.

Solução: 

Em 2009, a Entrust relançou o certificado raiz de 2048 bits para incluir O campo Restrições Básicas (cn = Autoridade de Certificação Entrust.net (2048), válido para 24/7/2029). A Entrust parou de empurrar a raiz original de 2048 bits Por meio de atualizações de raiz no Windows e no Java (A partir da atualização 1.6 da versão 1.6). O certificado raiz atualizado Contendo Restrições Básicas pode ser encontrado aqui:

https://www.entrust.net/downloads/binary/entrust_2048_ca.cer

0
cmcginty