Jarsigner: this jar contains records whose certificate chain has not been verified

Question

I am trying to enter the JAR file code and am using JDK 1.7u1. We purchased the GoDaddy code signing certificate, and I followed the instructions (approach 1) here: http://help.godaddy.com/article/4780

The JAR subscribes fine, however whenever I try to run the command: jarsigner -verify in my signed JAR using JDK 1.7u1 I get the following output:

 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. 

I also tried the jarsigner -verify using the same JAR as above on the JDK 1.6u26 and 1.6u14, and it returned as beautiful. (The output below is from 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. 

Am I missing the extra step I need to take to get the JAR signed correctly for JDK 1.7?

Answer 1

You are not missing anything, and you are definitely not on your own with this problem. After nearly 12 hours of fighting, I realized that the root of the problem was mixing binary files from JDK 1.7 with an old version of Java, such as JRE-1.6 . More precisely, keytool comes with the JRE , and the JDK comes with keytool and jarsigner .

So, to solve this problem, I completely uninstalled JDK-1.7 from my system and installed JDK-1.6 Update 30 . Now, if I did jarsigner -verify -verbose -certs blah.jar , it would produce jar verified without any warning, which I believe is what you expect.

Answer 2

I had the same problem, and if it can help others, the problem is how jarsigner finds the keystore.

To fix the problem, follow these steps:

 jarsigner -verify -keystore xxxx.jks mysignedjar.jar 

Answer 3

This is just a warning that you can ignore.

If you really don't want to ignore it, tell jarsigner where your keystore is when you check.

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

This is just a new feature in JDK 7.

Answer 4

I had a similar problem with "DigiCert SHA2 Assured ID Code Signing CA". All versions of oracle java as well as OpenJDK behaved the same way. Digicert support redirected me to this page, but none of this helped me in the verification process.

I'm trying to sign an applet, so I need this to be checked in the browser too, so the trick of providing a path to the keystore for jarsigner -verify is not applicable.

The main problem seems to be a keytool error when working with certificates using SHA2 instead of SHA1, because the same list of steps applied to SHA1 certificates always works and never worked for SHA2 for me. It seems to me that keytool is not able to detect "chains" of certificates imported into jks, and therefore jarsigner does not insert the correct certificate chain into a signed bank, there is only the final certificate stored in META-INF / myalias. RSA file (checked by openssl pkcs7 -in myalias.RSA -print_certs -inform DER -out certs.crt).

Digicert suggested "... we sometimes see problems with Root that are not actually imported correctly or completely for the first time, but running an import command that points to Root again can fix this," even this did not help me with the case.

Since I cannot explicitly specify which certificates should be in the chain, I decided to create a chain using openssl and import it as follows:

 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 

After that, mykeystore.jks seems to contain only my certificate, not DigiCertCA2 or Root, when it is specified with the keytool -list command, but with -v (verbose) it reveals the chain depth and its certificates:

 ~/$ 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]: 

And this is what jarsigned needs to properly sign the jar, i.e. embed the proper certificate chain and make the bank validation also for the end user of the browser.

Answer 5

I found that the message "This attendant contains entries whose certificate chain has not been verified" also prints if you sign the Jar file with JRE 1.7.0_21 and check it with a lower version of JRE 1.7.0.

Conclusion: There is no need to upgrade to Java 1.6, just use the same version of jarsigner for signing and verification.

Answer 6

This is the security mechanism in JDK 7+. This displays a warning when signing banners without a timestamp, which can be transmitted with the -tsa flag. If the bank does not have a timestamp, it will stop working after the date it was valid.

If you create a target for Android, this warning will always be printed if you use a JDK newer than 1.7.0_51. Android generally recommends skipping the 30-year warranty, so this warning can be ignored 100% if you are not planning a business plan so that users can use the same .apk in 2046.

Here's a ticket for this feature, the goal is to encourage a time reference that I believe will be effective. http://bugs.java.com/view_bug.do?bug_id=8023338 .

Answer 7

If your certificates are owned by Entrust, make sure you use the new root certificate.

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

Problem:

An error message appears stating your SLL certificate. Verification failed due to the absence of the main restriction field.

Decision:

In 2009, Entrust reissued a 2048-bit root certificate to include the Basic Restrictions field (cn = Entrust.net Certificate Authority (2048), valid until 7/24/2029). Entrust stopped pushing the original 2048-bit root through root updates in Windows and Java (since version 1.6 of Update 22). An updated root certificate containing basic restrictions can be found here:

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

Answer 8

When you create / export your certificate to p12 (using jarsigner), make sure that you select the following (for example, if you export using the Internet Explorer wizard), you will need to select the following in the export wizard.

"Export secret key" "Include all certificates in the certification path, if possible" "Export all advanced properties" is marked in the option .PFX or PKCS # 12.

If you create p12 correctly, then jarsign does not require much effort.