jarsigner: ce jar contient des entrées dont la chaîne de certificats n'est pas validée
J'essaie de code signer un fichier JAR et utilise JDK 1.7u1. Nous avons acquis un certificat GoDaddy Code Signing et j'ai suivi les instructions (approche 1) ici: http://help.godaddy.com/article/4780
Le fichier JAR signe bien, mais chaque fois que j'essaie d'exécuter la commande: jarsigner -verify sur mon fichier JAR signé à l'aide de JDK 1.7u1, j'obtiens le résultat suivant:
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.
J'ai également essayé la commande jarsigner -verify en utilisant le même fichier JAR que ci-dessus pour JDK 1.6u26 et 1.6u14 et il est revenu comme étant correct. (Sortie ci-dessous 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 manque-t-il une étape supplémentaire à franchir pour que le fichier JAR soit signé correctement pour JDK 1.7?
Vous êtes pas manque quelque chose et vous êtes vraiment pas seul avec ce problème. Après une lutte de près de 12 heures, j'ai compris que la racine du problème réside dans le mélange des fichiers binaires de JDK 1.7 avec une version plus ancienne de Java telle que JRE-1.6. Pour être plus précis, keytool est livré avec JRE, tandis que JDK est fourni avec keytool et jarsigner.
Donc, pour résoudre le problème, j’ai complètement désinstallé JDK-1.7 de mon système et installé JDK-1.6 Update 30. Maintenant, si je faisais jarsigner -verify -verbose -certs blah.jar, cela produirait jar verified sans aucun avertissement, ce que je crois être ce à quoi vous vous attendiez.
J'ai eu le même problème et si cela peut aider les autres, c'est que jarsigner trouve le fichier de clés.
Pour résoudre le problème, procédez comme suit:
jarsigner -verify -keystore xxxx.jks mysignedjar.jar
C'est juste un avertissement que vous pouvez ignorer.
Si vous ne voulez vraiment pas l'ignorer, indiquez à jarsigner où se trouve votre magasin de clés lors de la vérification.
jarsigner -verbose -verify -keystore ${KEYSTORE_PATH} ${YOUR_JAR_FILE}
Ceci est juste une nouvelle fonctionnalité de JDK 7.
J'ai eu un problème similaire avec le "CA DigiCert SHA2 Assured ID Code Signing". Toutes les versions Oracle Java ainsi que OpenJDK se sont comportés de la même manière. L’assistance Digicert m’a redirigé vers cette page, mais rien de ce qui est dit ici ne m’a aidé dans le processus de vérification.
J'essaie de signer un applet, il est donc nécessaire qu'il soit vérifiable également dans le navigateur. L'astuce consistant à fournir le chemin d'accès au fichier de clés vers jarsigner -verify n'est pas applicable.
Le problème principal semble être un bogue dans keytool lors de l'utilisation de certificats utilisant SHA2 au lieu de SHA1, car la même liste d'étapes appliquées sur les certificats SHA1 fonctionne toujours et n'a jamais fonctionné pour SHA2 pour moi. Il me semble que keytool n'est pas capable de détecter la "possibilité de chaîne" des certificats importés dans jks et que jarsigner n'intègre pas la chaîne de certificats appropriée dans le fichier jar signé. Il ne reste que le certificat final stocké dans le fichier META-INF/myalias. Fichier RSA à la place (vérifiable par openssl pkcs7 -in myalias.RSA -print_certs -inform DER -out certs.crt).
Digicert a suggéré " ... nous voyons parfois des problèmes avec la racine qui n'est pas réellement importée correctement ou complètement la première fois, mais exécuter une commande d'importation pointant à la racine à nouveau peut résoudre ce problème ", même si cela n'a pas aidé. mon cas.
Comme il n'y a aucun moyen de dire explicitement à keytool ce que les certificats sont sur le point d'être dans une chaîne, j'ai décidé de construire une chaîne en utilisant openssl et de l'importer comme ceci:
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
Après cela, mykeystore.jks semble contenir uniquement mon certificat, pas DigiCertCA2 ni la racine lorsqu'il est répertorié par la commande keytool -list, mais avec -v (verbose), il révèle la profondeur de la chaîne et ses certificats:
~/$ 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]:
Et c’est ce dont jarsigned a besoin pour signer le bocal correctement, c’est-à-dire pour intégrer la chaîne de certificats appropriée et rendre le bocal vérifiable également pour l’utilisateur final du navigateur.
J'ai constaté que le message "Ce fichier JAR contient des entrées dont la chaîne de certificats n'est pas validée" est également imprimé si vous signez le fichier Jar à l'aide de JRE 1.7.0_21 et que vous le vérifiez avec une version inférieure de JRE 1.7.0.
Conclusion: inutile de passer à Java 1.6, utilisez simplement la même version de jarsigner pour la signature et la vérification.
Il s’agit d’un mécanisme de sécurité dans JDK 7+. Ceci affiche l’avertissement lors de la signature de bocaux sans horodatage, qui peut être transmis avec un indicateur -tsa. Si un pot n'a pas d'horodatage, il cessera de fonctionner au-delà de sa date de validité.
Si vous construisez une cible Android, cet avertissement sera toujours imprimé si vous utilisez un JDK d'une version plus récente que 1.7.0_51. Android recommande généralement de dépasser les 30 ans de validité. Cet avertissement peut donc être ignoré à 100%, à moins que votre plan commercial ne permette aux utilisateurs d’utiliser le même fichier .apk en 2046.
Voici le ticket pour la fonctionnalité, le but est d'encourager l'horodatage, ce qui, je pense, sera efficace. http://bugs.Java.com/view_bug.do?bug_id=8023338 .
Lorsque vous créez/exportez votre certificat vers un p12 (utilisé par jarsigner), assurez-vous que les options suivantes sont sélectionnées (par exemple, si vous exportez à l'aide de l'assistant Internet Explorer), vous devrez sélectionner les éléments suivants dans l'assistant d'exportation.
"Exporter la clé privée" "Incluez si possible tous les certificats dans le chemin de certification" "Exporter toutes les propriétés étendues" cochée sous l'option .PFX ou PKCS # 12.
Si vous créez correctement la p12, jarsign ne nécessite aucun effort particulier.
Si vos certificats proviennent d’Entrust, assurez-vous d’utiliser le nouveau certificat racine.
http://www.entrust.net/knowledge-base/technote.cfm?tn=7875
Problème:
Vous recevez un message d'erreur indiquant votre certificat SLL la validation a échoué en raison de l'absence d'un champ Contraintes de base.
Solution:
En 2009, Entrust a republié le certificat racine de 2048 bits pour inclure le champ Contraintes de base (cn = Autorité de certification Entrust.net (2048), valide jusqu'au 24/07/2029). Entrust a cessé de pousser le racine 2048 bits d'origine via les mises à jour root sous Windows et Java (à partir de la version 1.6 mise à jour 22). Le certificat racine mis à jour contenant les contraintes de base peuvent être trouvés ici:
https://www.entrust.net/downloads/binary/entrust_2048_ca.cer