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?
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
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.
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.
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.
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.
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.
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
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.
Related
I have a certificate with a generated a CSR within go daddy.
I tried generating my own CSR to get a certificate for my domain.
I have followed their tutorial to generate a store with the CSR:
keytool -genkey -alias codesigncert -keypass -keyalg RSA -keysize 2048 -dname "CN=displayname,O=companyname,C=US,ST=state,L=city" -keystore codesignstore -storepass
But the godaddy rejected the generated CSR, so I used the one they generate.
After that I used this command from a tutorial at thomasvitale.com.:
keytool -import -alias <my alias> -file <downloadedcertificate file>.crt -keystore keystore.p12 -storepass password
The generated .p12 keystore wouldn't boot because spring said:
DerInputStream.getLength(): lengthTag=109, too big.
Reading a LOT on that I have found out it was the way the keystore was generated and the version of something. Because of that I had to generate another keystore.
To generate the current problematic keystore I tried following medium.com instructions:
Used this to generate the keystore:
keytool -genkey -alias <alias> -keyalg RSA -keystore <keystore.jks> -keysize 2048
Used this to generate a CSR:
keytool -certreq -alias <alias> -keystore <keystore.jks> -file <domain>.csr
Sent the CSR to generate the ssl certificates, downloading them using the tomcat option. Then imported the certificates:
intermediate certificate: keytool -import -trustcacerts -alias <alias> -file gd_bundle-g2-g1.crt -keystore <keystore.jks>
root certificate: keytool -import -trustcacerts -alias <alias> -file e2e56xxxxf40c7.crt -keystore <keystore.jks>
Then I created the pcks keystore this way:
keytool -importkeystore -srckeystore <keystore.jks> -destkeystore <keystore.p12> -srcstoretype JKS -deststoretype PKCS12 -deststorepass <password> -srcalias <src alias> -destalias <dest alias>
After that, my spring boot config to install the certificate is:
After comments on this question I changed to use the JKS and removed ciphers.
server:
port: 8443
ssl:
enabled: true
key-store-type: JKS
key-store: classpath:asgard_keystore.jks
key-store-password: generated
key-alias: asgard
After installing all those to the p12, the server started okay, but any requests to the server would yield: err_ssl_version_or_cipher_mismatch or SSL_ERROR_NO_CYPHER_OVERLAP
Capturing that in wireshark just said Alert 21 using TLS 1.2 Handshake Failure (40).
I'm using undertow as a server. I don't remember if I used the domain in the name and last name field of the CSR.
Decoding my CSR using digicert tool I got:
Common name
<my domain>
Organization
<my org>
Organizational unit
<my city>
City/locality
<my city>
State/province
<my estate>
Country
<my country>
Signature algorithm
SHA256
Key algorithm
RSA
Key size
2048
Seems I'm doing everything exactly like every single tutorial, and every time something fails :(
As per the comment on the question, the keytool -list calls:
keytool -list for the .jks:
Keystore type: jks
Keystore provider: SUN
Your keystore contains 3 entries
Alias name: asgard
Creation date: Dec 7, 2018
Entry type: trustedCertEntry
Owner: CN=Go Daddy Secure Certificate Authority - G2, OU=http://certs.godaddy.com/repository/, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
Issuer: CN=Go Daddy Root Certificate Authority - G2, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
Serial number: 7
Valid from: Tue May 03 07:00:00 UTC 2011 until: Sat May 03 07:00:00 UTC 2031
Certificate fingerprints:
MD5: 96<removed>:40
SHA1: 2<removed>B8
SHA256: 97:3A<removed>E9:76:FF:6A:62:0B:67:12:E3:38:32:04:1A:A6
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 2048-bit RSA key
< not relevant >
]
*******************************************
*******************************************
Alias name: intermediate
Creation date: Dec 14, 2018
Entry type: trustedCertEntry
Owner: CN=<removed>, OU=Domain Control Validated
Issuer: CN=Go Daddy Secure Certificate Authority - G2, OU=http://certs.godaddy.com/repository/, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
Serial number: 5c<removed>
Valid from: Fri Dec 07 20:25:19 UTC 2018 until: Mon Dec 07 18:10:35 UTC 2020
Certificate fingerprints:
MD5: 31<removed>74:77
SHA1: 8D:<removed>:C0:F5:AE:0B
SHA256: 77:14:9<removed>8B:1D:67:46:1A:67:A2:72:2F:2F:9E:F2:16
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 2048-bit RSA key
< not relevant >
]
*******************************************
*******************************************
Alias name: server
Creation date: Dec 7, 2018
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=<removed>, OU=São Paulo, O=Ideas Farm, L=São Paulo, ST=SP, C=BR
Issuer: CN=a<removed>, OU=São Paulo, O=Ideas Farm, L=São Paulo, ST=SP, C=BR
< not relevant >
]
]
*******************************************
*******************************************
full report: pastebin report
I have removed parts of the response that I find not relevant. I found it weird that the pkcs (.p12) file reported as being a jks type.
Also, the files that I received form the certificate authority are:
5<removedhex>6b1b.crt
gd_bundle-g2-g1.crt
gdig2.crt.pem
The gd_bundle contains 3 certificates -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- three times. The other two are just one.
You have told java to use the certificate with an alias of asgard. I can see in your .p12 dump that "asgard" is actually a CA. Look at the owner:
Alias name: asgard
Creation date: Dec 14, 2018
Entry type: trustedCertEntry
Owner: CN=Go Daddy Secure Certificate Authority - G2, OU=http://certs.godaddy.com/repository/, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
Issuer: CN=Go Daddy Root Certificate Authority - G2, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
I'm guessing that you actually want to tell spring to load your .jks file and specify an alias of codesigncert.
Also, delete your ciphers and enabled-protocols properties unless you have a good reason to override what spring sets up as defaults. Spring keep their defaults up to date with the latest security bulletins.
Finally, change your keystore password because the whole internet now knows what it is :)
I have solved the problem.
After fiddling A LOT with each certificate, I have found out that GoDaddy issues the certificate response and 2 equal intermediate certificates. Both come in the download package and there is no root certificate in there.
What happened is that I had a self signed dummy key, as stated in the comments and I didn't knew that I had to import the server certificate (the certificate response) with the same alias as my private key. I was importing with another alias thinking it was something else. My private key would remain self signed and not validated.
The errors I was getting about ciphers were because I was telling spring to use a certificate that was not a private key. Those don't support decoding the handshake.
Another problem that I faced is that godaddy doesn't provide the root certificate in the bundle you download. I was trying to add two intermediates, while the root was avaliable at a repository they had. After downloading and importing the correct root certificate, then I was able to import the private key validation certificate to the same alias as my dummy key.
So the solutin was simply to start with the JKS keystore used to create the CSR (one that contains only the private key I generated). Then add to it the root and intermediate certificates, and finally add the server cert (the one with the hex name), with the same alias as the private key.
Lets say I have a JAVA client app and it tries to connect to a server (example.com) over https. Client app has a trust store JKS , which has the server's certificate and some other certificates as well. In the hand shake process when server sends it certificate to this client app, how correct certificate will be picked up from the trust store jks. i.e based on what parameters java matches the certificate sent by the server with the certificates stored in JKS.
Matching is done by the certificate's Subject.
E.g. if you browse https://www.google.com/ and look at their certificate, it shows a certificate chain with:
Subject: /C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
Issued by: /C=US/O=Google Inc/CN=Google Internet Authority G2
Issued by: /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
Issues by: /C=US/O=Equifax/OU=Equifax Secure Certificate Authority
* Actually obtained using openssl s_client -connect www.google.com:443 -showcerts
The certificate will be trusted if any of these are in your truststore.
You can scan the truststore like this (assuming you have grep):
keytool -list -keystore /path/to/cacerts -storepass changeit -v | grep "CN=GeoTrust Global CA" -B 4 -A 8
To get this kind of output:
Alias name: geotrustglobalca
Creation date: Jul 18, 2003
Entry type: trustedCertEntry
Owner: CN=GeoTrust Global CA, O=GeoTrust Inc., C=US
Issuer: CN=GeoTrust Global CA, O=GeoTrust Inc., C=US
Serial number: 23456
Valid from: Tue May 21 00:00:00 EDT 2002 until: Sat May 21 00:00:00 EDT 2022
Certificate fingerprints:
MD5: F7:75:AB:29:FB:51:4E:B7:77:5E:FF:05:3C:99:8E:F5
SHA1: DE:28:F4:A4:FF:E5:B9:2F:A3:C5:03:D1:A3:49:A7:F9:96:2A:82:12
SHA256: FF:85:6A:2D:25:1D:CD:88:D3:66:56:F4:50:12:67:98:CF:AB:AA:DE:40:79:9C:72:2D:E4:D2:B5:DB:36:A7:3A
Signature algorithm name: SHA1withRSA
Version: 3
I'm trying to troubleshoot an issue with signed jars not working under appletviewer. My main goal is to run it outside of the browser, so I tried using appletviewer - if you have other suggestions, let me know.
Here's the context:
Ubuntu 11.10
Java:
$ java -version
java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)
Here's the problem:
I have a jar myjar.jar that contains an applet inside
It works properly in browser, but not when run under appletviewer
The jar is signed:
$ jarsigner -verify -certs -verbose -keystore /etc/ssl/certs/java/cacerts myjar.jar
...
smk <file size> <file date> <file name>
X.509, CN=xxx, OU=xxx, OU=xxx, O=xxx, L=xxx, ST=xxx, C=xxx
[certificate is valid from m/d/y h:m PM to m/d/y h:m PM]
X.509, CN=yyy, OU=yyy, OU=yyy, O=yyy, C=yyy
[certificate is valid from m/d/y h:m PM to m/d/y h:m PM]
[KeyUsage extension does not support code signing]
X.509, OU=zzz, O=zzz, C=zzz (alias1)
[certificate is valid from m/d/y h:m PM to m/d/y h:m PM]
...
jar verified.
and, though the intermediate signing certificate (yyy above) is not present, the root one (zzz - or alias1) is:
$ keytool -list -v -keystore /etc/ssl/certs/java/cacerts -storepass changeit|grep alias1
alias1, Mmm d, yyyy, trustedCertEntry,
Running this:
$ appletviewer myhtml.html
gives:
Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission preferences)
Question set 1:
Is the assumption that when a root certificate is present, all following intermediate certificates are assumed acceptable for verification purposes? In above case, is it necessary to have yyy in the cacerts file?
When jar is signed, as myjar.jar is, is it assumed that appletviewer should run with no restrictions?
Is there a better way to run it to avoid this?
Why is this working differently in browser than with appletviewer?
Not being sure of above, I tried adding the certificate to another local file, called cacerts2. I can confirm that:
keytool lists that certificate in cacerts
jarsigner output is now like this:
$ jarsigner -verify -certs -verbose -keystore cacerts2 myjar.jar
...
smk <file size> <file date> <file name>
X.509, CN=xxx, OU=xxx, OU=xxx, O=xxx, L=xxx, ST=xxx, C=xxx
[certificate is valid from m/d/y h:m PM to m/d/y h:m PM]
X.509, CN=yyy, OU=yyy, OU=yyy, O=yyy, C=yyy (alias2)
[certificate is valid from m/d/y h:m PM to m/d/y h:m PM]
[KeyUsage extension does not support code signing]
X.509, OU=zzz, O=zzz, C=zzz (alias1)
[certificate is valid from m/d/y h:m PM to m/d/y h:m PM]
...
jar verified.
Note that now I have the intermediate alias (yyy - or alias2) present in the output and verified both against alias1 and alias2. Running the appletviewer like this:
$ appletviewer -J-Djavax.net.ssl.trustStore=cacerts2 -J-Djavax.net.ssl.trustStorePassword=changeit myhtml.html
still results in the same exception.
Question set 2:
Is the above the right way to supply the trust store?
Does the above mean that appletviewer will use it in the same way as jarsigner will when passed -keystore command for its verification purposes?
The third thing I tried is making a policy file like this (this is in mypolicy.policy):
keystore "cacerts2";
// Tried with this and without the next line:
//keystorePasswordURL "cacerts.pass";
// where file cacerts.pass has only "changeit" / "changeit\n" in it (tried both)
// Tried the following three:
grant signedBy "alias1" {
//grant signedBy "alias2" {
//grant {
permission java.lang.RuntimePermission "preferences";
};
and running like this:
$ appletviewer -J-Djava.security.policy=mypolicy.policy myhtml.html
and like this:
$ appletviewer -J-Djavax.net.ssl.trustStore=cacerts2 -J-Djavax.net.ssl.trustStorePassword=changeit -J-Djava.security.policy=mypolicy.policy myhtml.html
Results:
grant without any signedBy specs worked, so I can confirm the policy is picked up
grant with either signedBy is failing
Question set 3:
Is this the correct way to specify policy and signedBy? I find the docs from Oracle incomplete on this topic
Is policy file even used when jar is signed?
Any other ideas? :)
My main goal is to run it outside of the browser,..
Use Java Web Start, which could launch applets free-floating since around the 1.2 days. (Or convert the code to a frame.)
If the main point of this is testing, you might try Appleteer. AFAIR I never got around to implementing a sand-box for it (so even unsigned applet code would behave as if it were trusted).
AppletViewer used to launch applets without a security sand-box, even if they were not signed. Now it is the opposite and has a sand-box, and there is no way to get it to accept signed code as trusted!
IDEs seem to apply a policy file to the viewer, to get it to act however the user configures the IDE.
I get the following error on a self-signed jar:
jar verified.
Warning:
This jar contains entries whose certificate chain is not validated.
Re-run with the -verbose and -certs options for more details.
I signed the jar like this:
"C:\Program Files\Java\jdk1.7.0\bin\jarsigner" -keystore myKeyStore myJar.jar myAlias
My jar has 2 entry points: One for java web start, and one for an applet.
If I run the jar in a java web start way, it has no incidence.
But if I run the jar as an applet. I get a strong security warning at some point when I try to access a bitmap resource embeded in the jar.
Using the -verbose and -certs options shows a lot of lines. And I don't understand anything of this. This is the output: output.txt (part of the 6307 lines reproduced below).
s 157850 Tue Nov 08 12:57:44 CET 2011 META-INF/MANIFEST.MF
X.509, O=keyja.com
[certificate is valid from 17/08/11 17:32 to 24/07/11 17:32]
[CertPath not validated: null]
112909 Tue Nov 08 12:57:44 CET 2011 META-INF/KEYJA_CO.SF
1108 Tue Nov 08 12:57:44 CET 2011 META-INF/KEYJA_CO.RSA
sm 180 Tue Nov 08 12:16:40 CET 2011 com/keyja/client/a/a/a/k.class
X.509, O=keyja.com
[certificate is valid from 17/08/11 17:32 to 24/07/11 17:32]
[CertPath not validated: null]
sm 252 Tue Nov 08 12:16:40 CET 2011 com/keyja/client/a/a/a/r.class
...
(around 6000 lines of other output along the same lines)
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.
How to sign the jar file ?
Just one line answers you question I guess. And if you look closer you'll see it. Here it is
[certificate is valid from 17/08/11 17:32 to 24/07/11 17:32]
As I may hope, you know that today is not July 24 so you just have to re-sign your app
Thanks Andrew Thompson. I have unsigned my jar file, and found the bug. It's better unsigned you're right about this, because signing makes no point since I don't need to get out of the sandbox.
For the record, the bug was the use of the jnlp.jar library. In order to make it work, I launched the applet using jnlp/applet code instead of a standard tag.
I have exactly the same problem.
There is a change in the validation in the new Java 7 and Java 6 versions.
Bug id is : 6861062 java classes_security Disable MD2 in certificate chain validation.
When signing the Jara file , I had some warning message and when executing the command:
jarsigner MyTools.jar -verify -verbose -certs
I had the message:
X.509, OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US
[certificate is valid from 29.01.96 01:00 to 02.08.28 01:59]
[CertPath not validated: Algorithm constraints check failed: MD2withRSA]
My solution is :
- use another version of the JDK to sign and JRE Plugin.
- Update your certificate security in order not to use this algorithm.
I hope it will help you.
Regards
I was trying to sign a jar applet archive with our company .pfx certificate using this guide
(and few others from the internet):
http://www.globalsign.com/support/ordering-guides/SignJavaCodeAppletsPFX.pdf
Everything seems to be fine, but when I try t run apple through the browser I see that
'Publisher' is UNKNOWN (untrusted). And when I go to details I'm able to see proper company
name and certificate vendor (GlobalSign). Why it's not properly displayed as known/trusted?
The one thing which looks suspicious to me is output of command
jarsigner -verify -verbose -certs Applet.jar:
(...)
sm 1936 Wed Apr 13 03:00:50 CEST 2011 org/my/Applet.class
X.509, CN=CompanyName, O=CompanyName, L=Tilst, ST=ProperState, C=DK
[certificate is valid from 18.02.10 14:58 to 18.02.13 14:58]
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
So looks like 'k = at least one certificate was found in keystore' is missing
(should be smk and it is sm). Is it signed only partially? Or what?
Is it possible that .pfx file given to me by GlobalSign is somehow wrong
on not enough to sign applets? For normal executables it was working just fine...
Any ideas? ;)
EDIT
#Jcs
Looks like you are totally right. I checked my PFX file with keytool and I get:
Your keystore contains 1 entry
Alias name: company_alias
Creation date: Apr 13, 2011
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
So looks like chain is not complete.
I'm not sure if it matters, but there are also few extensions like for example:
#1: ObjectId: (some_numbers_here) Criticality=true
KeyUsage [
DigitalSignature
]
#2: ObjectId: (some_numbers_here) Criticality=false
AuthorityInfoAccess [
[
accessMethod: (some_numbers_here)
accessLocation: URIName: http://secure.globalsign.net/cacert/ObjectSign.crt]
]
(...)
Question is: is my PFX file totally wrong, or somehow I need to add globalsign root to it?
According to your post, it seems that there is only one certificate in the signature certificate chain. I verified an applet I signed (this applet works correctly in a browser)
(...)
sm 2419 Thu Mar 31 15:49:14 CEST 2011 org/xml/sax/helpers/XMLReaderFactory.class
X.509, CN=Company Name, O=Company Name, L=Paris, ST=Ile de France, C=FR
[certificate is valid from 8/4/10 2:00 AM to 8/4/12 1:59 AM]
X.509, CN=Thawte Code Signing CA - G2, O="Thawte, Inc.", C=US
[certificate is valid from 2/8/10 1:00 AM to 2/8/20 12:59 AM]
[KeyUsage extension does not support code signing]
(...)
We can see that there is 2 certificates in the chain since my signing certificate has been issued by the Thawte Code Signing CA.
In your case if there is only one certificate in the jarsigner output it may indicates that the intermediate CA is missing and I hardly doubt that GlobalSign is directly issuing certificates from the root CA (which is in the java trust store). Therefore when the applet is loaded and the signatures are verified the JVM is not able to rebuild a certificate chain between the signing certificate and the GlobalSign root CA, explaining the current behaviour.
Maybe the PKF file does not contains that intermediate CA. With OpenSSL you can check how many certificates are present:
[jcs#home:~/]$ openssl pkcs12 -in myfile.pfx
or with keytool
[jcs#home:~/]$ keytool -list -v -storetype pkcs12 -keystore myfile.pfx
Enter keystore password:
Keystore type: PKCS12
Keystore provider: SunJSSE
Your keystore contains 1 entry
Alias name: 2
Creation date: Aug 4, 2010
Entry type: PrivateKeyEntry
Certificate chain length: 2 <-- the chain length is here.
Certificate[1]:
(...)
Thanks a lot for all, especially Jcs :)
I finally discovered that .pfx file was just imported improperly.
I asked my boss to import it for me from scratch with all possible paths/chains/certificates included and now it works :)
So if anyone will have similar problem my advice is to try to get/import certificate again
- it's rather problem with certificate itself than with signing method.