java - para - jarsigner: este jar contiene entradas cuya cadena de certificados no está validada

generar certificado jks

Question

Estoy tratando de firmar un archivo JAR y estoy usando JDK 1.7u1. Adquirimos un certificado de firma de código GoDaddy y seguí las instrucciones (Método 1) aquí: http://help.godaddy.com/article/4780

El JAR firma bien, sin embargo, cada vez que intento ejecutar el comando: jarsigner -verify en mi JAR firmado utilizando JDK 1.7u1 obtengo el siguiente resultado:

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.

También probé el comando jarsigner -verify con el mismo JAR que el anterior en JDK 1.6u26 y 1.6u14 y resultó que estaba bien. (Salida inferior a partir 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.

¿Me estoy perdiendo un paso adicional que necesito para firmar correctamente el JAR para JDK 1.7?

Answer 1

Cuando cree / exporte su certificado a una p12 (utilizado por el jarsigner), asegúrese de seleccionar lo siguiente (por ejemplo, si exporta con el asistente de Internet Explorer) deberá seleccionar lo siguiente en el asistente de exportación.

"Exportar la clave privada" "Incluir todos los certificados en la ruta de certificación si es posible" "Exportar todas las propiedades extendidas" marcada en la opción .PFX o PKCS # 12.

Si crea la p12 correctamente en primer lugar, entonces jarsign no requiere ningún esfuerzo especial.

Answer 2

Descubrí que el mensaje "Este contenedor contiene entradas cuya cadena de certificados no está validada" también se imprime si firma el archivo Jar con JRE 1.7.0_21 y lo verifica con una versión inferior de JRE 1.7.0.

Conclusión: no es necesario cambiar a Java 1.6, simplemente use la misma versión de jarsigner para la firma y la verificación.

Answer 3

Es solo una advertencia que puedes ignorar.

Si realmente no quieres ignorarlo, dile a jarsigner dónde está tu almacén de claves cuando lo verifiques.

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

Esta es solo una nueva característica en JDK 7.

Answer 4

Este es un mecanismo de seguridad en JDK 7+. Esto imprime la advertencia al firmar los frascos sin una marca de tiempo, que se puede pasar con una marca -tsa. Si un frasco no tiene una marca de tiempo, dejará de funcionar después de su fecha de validez.

Si está creando un objetivo de Android, esta advertencia siempre se imprimirá si está utilizando un JDK más reciente que 1.7.0_51. Generalmente, Android recomienda pasar la validez de 30 años, por lo que esta advertencia puede ignorarse al 100% a menos que su plan de negocios sea permitir que los usuarios usen el mismo .apk en 2046.

Aquí está el boleto para la función, el propósito es alentar el sello de tiempo, que creo que será efectivo. http://bugs.java.com/view_bug.do?bug_id=8023338 .

Answer 5

He tenido el mismo problema y si puede ayudar a otros, el problema está en cómo jarsigner encuentra el almacén de claves.

Para solucionar el problema haz:

jarsigner -verify -keystore xxxx.jks mysignedjar.jar

Answer 6

No te estás perdiendo nada y definitivamente no estás solo con este problema. Después de una lucha de casi 12 horas, descubrí que la raíz del problema radica en mezclar binarios de JDK 1.7 con una versión anterior de Java como JRE-1.6 . Para ser más precisos, keytool viene con JRE , mientras que JDK envía con keytool y jarsigner .

Entonces, para resolver el problema, desinstalé JDK-1.7 de mi sistema por completo e instalé la JDK-1.6 Update 30 . Ahora, si quisiera hacer jarsigner -verify -verbose -certs blah.jar , se produciría un jarsigner -verify -verbose -certs blah.jar jar verified sin ninguna advertencia, lo que creo que es lo que esperas.

Answer 7

Si sus certificados son de Entrust, asegúrese de estar usando el certificado raíz más nuevo.

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

Problema:

Recibirá un mensaje de error que indica que la validación de su certificado SLL ha fallado debido a que falta un campo de Restricciones básicas.

Solución:

En 2009, Entrust relanzó el certificado raíz de 2048 bits para incluir el campo Restricciones básicas (cn = Autoridad de certificación de Entrust.net (2048), válido hasta el 24/7/2029). Entrust ha dejado de sacar la raíz original de 2048 bits a través de las actualizaciones de raíz en Windows y Java (a partir de la versión 1.6, actualización 22). El certificado raíz actualizado que contiene restricciones básicas se puede encontrar aquí:

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

Answer 8

Tuve un problema similar con el "DigiCert SHA2 Assured ID Code Signing CA". Todas las versiones de Oracle Java, así como OpenJDK se comportaron igual. El soporte de Digicert me redirigió a esta página, pero nada de lo que se menciona aquí tampoco me ayudó con el proceso de verificación.

Estoy intentando firmar un applet, por lo que necesito que sea verificable también en el navegador, por lo que el truco para proporcionar la ruta del almacén de claves a jarsigner -verify no es aplicable.

El problema principal parece ser un error en keytool cuando se opera con certificados usando SHA2 en lugar de SHA1, porque la misma lista de pasos aplicados en los certificados SHA1 siempre funciona y nunca funcionó para SHA2 para mí. Me parece que keytool no es capaz de detectar la "encadenamiento" de los certificados importados a jks y, por lo tanto, jarsigner no incrusta la cadena de certs adecuada en el frasco firmado, solo hay el certificado final almacenado en el META-INF / myalias. Archivo RSA en su lugar (verificable por openssl pkcs7 -in myalias.RSA -print_certs -inform DER -out certs.crt).

Digicert sugirió que " ... a veces vemos que los problemas con la raíz no se importan correctamente la primera vez, pero ejecutar un comando de importación que apunta a la raíz nuevamente puede solucionar esto ", incluso esto no ayudó en mi caso.

Como no hay manera de decir explícitamente a keytool qué están a punto de formar parte de una cadena, he decidido construir una cadena utilizando openssl e importarla de esta manera:

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

Después de esto, mykeystore.jks parece contener solo mi certificado, no DigiCertCA2 o la Raíz cuando se enumeran mediante el comando keytool -list, pero con -v (verbose) revela la profundidad de la cadena y sus 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]:

Y esto es lo que Jarsigned necesita para firmar el frasco correctamente, es decir, para incrustar la cadena de certificados adecuada y hacer que el frasco sea verificable también para el usuario final del navegador.