jarsigner: This jar contains entries whose certificate chain is not validated

Question

I'm trying to code sign a JAR file and am using JDK 1.7u1. We acquired a GoDaddy Code Signing certificate and I followed the instructions (Approach 1) here: http://help.godaddy.com/article/4780

The JAR signs fine, however whenever I try to run the command: jarsigner -verify on 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 command using the same JAR as above on JDK 1.6u26 and 1.6u14 and it came back as being fine. (Output below 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 an extra step I need to take to get the JAR signed properly for JDK 1.7?

Hippel

Answer 1

You are not missing anything and you are definitely not alone with this problem. After a struggle of almost 12 hours, I figured out that the root of the problem lies in mixing binaries from JDK 1.7 with an older version of Java such as JRE-1.6. To be more precise, keytool comes with JRE, while JDK ships with both keytool and jarsigner.

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

Hobbyhorse

This solution is bad... First: it's just a warning Second: if you really want it to go away the solution is to tell it where the keystore is adding -keystore <your keystore path> to the verify command – Asper

thanks!!! just for the reference - the download link is here: oracle.com/technetwork/java/javasebusiness/downloads/… – Zahn

Answer 2

I have been having the same issue and if it can help others the problem is in how jarsigner finds the keystore.

In order to fix the issue do:

jarsigner -verify -keystore xxxx.jks mysignedjar.jar

Tubercular

your answer is correct and it must be the perfect answer.thanks – Integrity

After hours of struggles with ant/JDK 1.7/jarsigner, this is actually a warning that appeated in JDK 1.7, see, Oracle made some changes when it bought Sun, it decided to issue more warnings such as those. There was also an issue of ant not sending the right switches to jarsigner, which I believe is resolved in android target 19 (at least). The funny thing is it now verifies OK two APKs, each signed with a different algorithm, thus not helping determining if ant/jdk1.7/android works. – Reannareap

Answer 3

It's just a warning you can ignore.

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

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

This is just a new feature in JDK 7.

Asper

your absolutely correct ... add the -keystore flag with path and you'll see you have a valid jar file – Heise

The client which downloads the JAR will not have access to the keystore path, but will verify via the chain to the root CA. I.e. you've signed the JAR with your cert, which is issued by the root CA, and the client cannot verify your cert directly without the keystore, but it can verify up the chain and verify the root CA since it will be pre-installed in local client java Signer CAs. It seems like verifying against the keystore is like assuming the cert will be installed on the local client, which it will not, only the root CA will. Wouldn't the client still have a problem with the chain? – Thomasina

Answer 4

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

I am trying to sign an applet, so I need it to be verifiable also in the browser, so the trick with providing the keystore path to jarsigner -verify is not applicable.

Main problem seems to be a bug in keytool when operating with certs using SHA2 instead of SHA1, because the same list of steps applied on SHA1 certs always works and never worked for SHA2 for me. It appears to me, that keytool is not capable of detecting the "chainability" of certificates imported to jks and thus jarsigner does not embed proper certs chain into the signed jar, there is only the final certificate stored in the META-INF/myalias.RSA file instead (verifiable by openssl pkcs7 -in myalias.RSA -print_certs -inform DER -out certs.crt).

Digicert suggested "...we sometimes see issues with the Root not actually being imported correctly or fully the first time, but running an import command that points to the Root again can fix this", even this did not help in my case.

As there is no way to say explicitly to keytool what certs are about to be in a chain, I've decided to build a chain using openssl and import it like this:

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 this mykeystore.jks appears to contains only my certificate, not DigiCertCA2 or the Root when listed by keytool -list command, but with -v (verbose) it discloses chain depth and its certs:

~/$ 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 sign the jar properly, i.e. to embed proper certs chain and make jar verifiable also for final browser user.

Womack

This really helped me. Thanks a lot for posting it – Mediacy

Answer 5

I found that the message "This jar contains entries whose certificate chain is not validated" is also printed if you sign the Jar file using JRE 1.7.0_21 and verify it with a lower version of JRE 1.7.0.

Conclusion: no need to downgrade to Java 1.6, simply use the same jarsigner version for both signing and verification.

Lambda

Answer 6

This is a security mechanism in JDK 7+. This prints the warning when signing jars without a timestamp, which can be passed with a -tsa flag. If a jar has no timestamp, it will stop working past its validity date.

If you are building an Android target, this warning will always print if you are using a JDK newer than 1.7.0_51. Android generally recommends passing 30 years validity, so this warning can be 100% ignored unless you business plan is to allow users to use the same .apk in 2046.

Here is the ticket for the feature, the purpose is to encourage timestamping, which I believe will be effective. http://bugs.java.com/view_bug.do?bug_id=8023338.

Goode

Answer 7

If your certificates are from Entrust, make sure you are using the newer root certificate.

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

Problem:

You receive an error message that states your SLL certificate validation has failed due to a missing Basic Constraints field.

Solution:

In 2009, Entrust re-released the 2048-bit root certificate to include the Basic Constraints field (cn=Entrust.net Certification Authority (2048), valid to 7/24/2029). Entrust has stopped pushing out the original 2048-bit root through root updates in Windows and Java (starting from version 1.6 update 22). The updated root certificate containing Basic Constraints can be found here:

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

Peon

Answer 8

When you create/export your certificate to a p12 (used by the jarsigner) make sure you ensure the following is selected (for example if you export using Internet explorer wizard) you will need to select the following in the export wizard.

"Export the private key” “Include all certificates in the certification path if possible” “Export all extended properties” checked under the option .PFX or PKCS #12.

If you create the p12 properly in the first place then jarsign requires no special effort.

Kruller