checcking the details of individual certificate from avalilable certifcates - java

I have one certificate installed in java and I can execute this command under the JRE security director:
keytool -list -keystore cacerts
That gives me the list of installed certificates, but then I want to see the details of one individual certificate from that list. Say I get this result:
Certificate fingerprint (MD5): 7D:6C:16:E4:FC:4D:D1:0B:10:BA:22:BB:4E:1C:6A:8E
verisignclass3g3ca, 25-Mar-2004, trustedCertEntry,
Certificate fingerprint (MD5): CD:68:B6:A7:C7:14:CE:71:E0:1D:4F:57:44:61:91:09
godaddyclass2ca, 11-Jan-2005, trustedCertEntry,
From this I want to see the details of the certificate named verisignclass3g3ca - when this certificate is going to expire and other details. How can I see that?

Related

PKIX path building failed : I added certificate to carcert still failing

I am facing this problem with PKIX path build failuer, this is what I have tried...
I went to the target URL that I am trying to reach
(eg -> https://localdevchannel.master.info/Gate/CustomerManagement/rest/resources/search)
I clicked on the "LOCK" icon and exported the certificate.
I ran below command...
keytool -importcert -file sec.cer -storepass changeit -keystore "C:/Program Files/Java/jdk-11.0.2/jdk-11.0.2/lib/security/cacerts" -alias secCert
The certificate got placed successfully. But I am still facing this issue. Please help what did I do wrong?
javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
ok,
You get this exception if your Certificate is expired, or does not exist in your store, or you updated another cacert file, and your java/and/or app is looking/using another.
1- Inspect your cacert file to actually see if the CERT has been added
with its alias there.
From inside your JDK/jre/bin , you can find the keytool.exe
You can call it like below to read the cacerts file:
susan#SE-00018098 /c/Program Files/Java/jdk1.7.0_80/jre/bin
$ keytool.exe -list -keystore ../lib/security/cacerts
Enter keystore password:
Keystore type: jks
Keystore provider: SUN
Your keystore contains 92 entries
digicertassuredidrootca, 2008-apr-16, trustedCertEntry,
Certificate fingerprint (SHA1): 05:63:B8:63:0D:62:D7:5A:BB:C8:AB:1E:4B:DF:B5:A8:99:B2:4D:43
trustcenterclass2caii, 2008-apr-29, trustedCertEntry,
Certificate fingerprint (SHA1): AE:50:83:ED:7C:F4:5C:BC:8F:61:C6:21:FE:68:5D:79:42:21:15:6E
thawtepremiumserverca, 2009-dec-11, trustedCertEntry,
Certificate fingerprint (SHA1): E0:AB:05:94:20:72:54:93:05:60:62:02:36:70:F7:CD:2E:FC:66:66
swisssignplatinumg2ca, 2008-okt-31, trustedCertEntry,
2- If it is, is it expired? Check the date.
3- Confirm whether your app/java runtime is using the cacert file
you just updated (Do you have multiple Java versions installed? What is your (Java_home)
======== Edited
If the certificate exists, and it is not expired, and you are 100% sure it is the right certificate, then probably your application/or container is not looking at the cacert file.
Try the hack below: I consider this as a hack, as you are hardcoding
a path that may/not exist when you deploy on a different server.
There are many ways of create your own truststore and keystore stores
and having those in the app itself, then you can incorporate them in
your code, but try it to just see if the rest of the code works.
Set the system property before your https connection code:
System.setProperty("javax.net.ssl.trustStore", "java_home_path/jre/lib/security/cacerts");
Replace with the correct path to cacerts file and try.

Java 8 won't use new Sectigo cross-signed certiifcate when downloading jar

We have several web sites hosted on AWS that are all signed with a Sectigo signed SSL certificate. One of these web sites hosts a Java applet/webstart application which worked fine up until May 31, 2020 when the Sectigo AddTrust-External-CA-Root certificate expired.
Since then going to the web site in any browser shows that the web site is secure, but when trying to download the jar file, Java 8u252 complains that the web site is untrusted. This despite the Sectigo knowledge base page saying that Java8u51 or higher should just work. It does for connections made from a Java application, but not for loading the application itself either via WebStart or as an applet.
Our certificate is issued with this intermediate certificate which is issued by COMODO RSA Certification Authority.
My understanding based on the description of cross-signed certificates is that COMODO RSA Certification Authority can be either this certificate (which just expired), this one (issued by this one) or this one. All of these certificate are installed in the cacerts Java file as well as the Windows certificate manager, yet for some reason Java always wants to use the expired one.
I'm not even sure where Java is getting the certificate from. I've removed the expired certificate from cacerts and even gone as far as deleting the cacerts file and Java still uses the expired certificate.
Any idea why Java is using the old expired certificate and how to get it to use the valid one?
>keytool -list -storepass changeit -keystore cacerts | find "AF:E5:D2:44:A8:D1:19:42:30:FF:47:9F:E2:F8:97:BB:CD:7A:8C:B4"
Certificate fingerprint (SHA1): AF:E5:D2:44:A8:D1:19:42:30:FF:47:9F:E2:F8:97:BB:CD:7A:8C:B4
>keytool -list -storepass changeit -keystore cacerts | find "D1:EB:23:A4:6D:17:D6:8F:D9:25:64:C2:F1:F1:60:17:64:D8:E3:49"
Certificate fingerprint (SHA1): D1:EB:23:A4:6D:17:D6:8F:D9:25:64:C2:F1:F1:60:17:64:D8:E3:49
***
adding as trusted cert:
Subject: CN=COMODO RSA Certification Authority, O=COMODO CA Limited, L=Salford, ST=Greater Manchester, C=GB
Issuer: CN=AddTrust External CA Root, OU=AddTrust External TTP Network, O=AddTrust AB, C=SE
Algorithm: RSA; Serial number: 0x2766ee56eb49f38eabd770a2fc84de22
Valid from Tue May 30 06:48:38 EDT 2000 until Sat May 30 06:48:38 EDT 2020
Found trusted certificate:
[
[
Version: V3
Subject: CN=COMODO RSA Certification Authority, O=COMODO CA Limited, L=Salford, ST=Greater Manchester, C=GB
Signature Algorithm: SHA384withRSA, OID = 1.2.840.113549.1.1.12
Key: Sun RSA public key, 4096 bits
params: null
modulus: 595250832037245141724642107398533641144111340640849154810839512193646804439589382557795096048235159392412856809181253983148280442751106836828767077478502910675291715965426418324395462826337195608826159904332409833532414343087397304684051488024083060971973988667565926401713702437407307790551210783180012029671811979458976709742365579736599681150756374332129237698142054260771585540729412505699671993111094681722253786369180597052805125225748672266569013967025850135765598233721214965171040686884703517711864518647963618102322884373894861238464186441528415873877499307554355231373646804211013770034465627350166153734933786011622475019872581027516832913754790596939102532587063612068091625752995700206528059096165261547017202283116886060219954285939324476288744352486373249118864714420341870384243932900936553074796547571643358129426474424573956572670213304441994994142333208766235762328926816055054634905252931414737971249889745696283503174642385591131856834241724878687870772321902051261453524679758731747154638983677185705464969589189761598154153383380395065347776922242683529305823609958629983678843126221186204478003285765580771286537570893899006127941280337699169761047271395591258462580922460487748761665926731923248227868312659
public exponent: 65537
Validity: [From: Tue May 30 06:48:38 EDT 2000,
To: Sat May 30 06:48:38 EDT 2020]
Issuer: CN=AddTrust External CA Root, OU=AddTrust External TTP Network, O=AddTrust AB, C=SE
SerialNumber: [ 2766ee56 eb49f38e abd770a2 fc84de22]
We noticed that someone included the entire certificate chain in the certificate in AWS. The current theory we have is that Java will explicitly use this chain ignoring the fact that there are valid chains that could be used. Browsers don't appear to have this issue.
As stated it is due to the expiration of the AddTrust_External_Root certificate
Here is a quick detailed way to fix it if you are on a linux based server:
remove AddTrust_External_Root.crt from your system (usually found in /etc/ssl/certs)
remove or comment the "mozilla/AddTrust_External_Root" line from /etc/ca-certificates.conf
run sudo update-ca-certificates to update the certificates used by openssl
i hope it helps :)

Windows Tomcat7 SSL CA cert says is self signed

Hi I'm trying to configure tomcat7 (7.0.50) in windows 7 using a cert from a CA (entrust, if it matters). I downloaded the CA root, chain root and chain cert files, and my new certificate. Per the tomcat guide, I used the keystore I generated the csr from and followed these steps
keytool -import -alias entrust -trustcacerts -keystore crush.jks -file entrust.crt.txt
[prompts me the cert exists in the system wide CA keystore, I still add it]
keytool -import -alias chain-root -trustcacerts -keystore crush.jks -file L1Kchainroot.txt
keytool -import -alias chain-root -trustcacerts -keystore crush.jks -file L1Kchain.txt
keytool -import -alias tomcat -trustcacerts -keystore crush.jks -file entrustcert.crt.txt
Now when I list the contents of my keystore I see
C:\Users\crush\My Documents\cert>keytool -list -keystore crush.jks
Enter keystore password:
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 5 entries
entrust, Mar 30, 2015, trustedCertEntry,
Certificate fingerprint (SHA1): B3:1E:B1:B7:40:E3:6C:84:02:DA:DC:3
chain, Mar 30, 2015, trustedCertEntry,
Certificate fingerprint (SHA1): CC:A2:7D:33:C7:35:A7:D0:6D:1F:EC:A
chain-root, Mar 30, 2015, trustedCertEntry,
Certificate fingerprint (SHA1): 9E:1A:0C:35:E7:14:B6:97:92:D0:90:B
tomcat, Mar 30, 2015, trustedCertEntry,
Certificate fingerprint (SHA1): 6A:77:EC:32:1E:F9:AC:4F:BE:C7:CB:5
crush-windows7, Mar 26, 2015, PrivateKeyEntry,
Certificate fingerprint (SHA1): 04:72:8A:36:56:7E:D5:0F:7E:E9:E0:1
Now I edited my server.xml file to be like so
<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol" SSLEnabled="true"
maxThreads="150" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS" sslEnabledProtocols="TLSv1"
keystoreFile="C:\Users\crush\apache-tomcat-7.0.50\conf\crush.jks"
keystorePass="storepassword"
keyPass="keypassword"
/>
When this boots up and I navigate to the page I'll see an untrusted connection warning
crush-windows7.crush.com:8443 uses an invalid security certificate. The certificate is not trusted because it is self-signed. (Error code: sec_error_ca_cert_invalid)
If I use -v with keytool and inspect the returned certificate I'll see the Issuer as Entrust
Owner: CN=crush-windows7.crush.com, ....
Issuer: CN=Entrust Certification Authority - L1K, OU="(c) 2012 Entrust, Inc. - for authorized use only", OU=See www.entrust.net/legal-terms, O="Entrust, Inc.", C=US
But my private key entry has the issuer as myself
Owner: CN=crush-windows7.crush.com, ....
Issuer: CN=crush-windows7.crush.com, ....
I've been messing with this for a couple hours and bashing my head against the wall, I've done this with linux before using openssl instead of keytool without issues. Could this be my issue? No matter what connector config I try, it will not boot without the private key entry as the alias and the keyPass option set. If I remove the private key entry it will boot but never complete the ssl handshake. I use the 'tomcat' alias for the keyAlias it will say
java.io.IOException: Alias name tomcat does not identify a key entry
Can I salvage my current certificate or do I need to generate a new private key and csr and submit a new request then move them to my windows machine? I really feel this is my issue, am I even close to being on point? Using windows for this has been less than comfortable, thanks for helping.
You have made a small mistake in step 4: Instead of updating your PrivateKeyEntry with the certificate issued by Entrust, you have imported it as a trusted certificate.
The right command would have been:
keytool -import -alias crush-windows7 -trustcacerts -keystore crush.jks -file entrustcert.crt.txt

Installation of WildCard SSL certificate (By Comodo) on Tomcat Apache Web Server

I am installing a wild Card SSL certificate to my keystore which will be used for Apache Tomcat web server.
Description :
My Tomcat Server is installed on windows 2012 server.
And I have certificates provided from COMODO.
The wildcard cert I'm using has already been used previously on a few servers. so I am directly installing same on my apache tomcat server .
so what I've generated a public keystore using keytool providing the same information used while purchasing the certificate using following tool command.
keytool -keysize 2048 -genkey -alias tomcat -keyalg RSA -keystore tomcat.keystore
Then I have attached my certificates to the generated keystore using following commond
For "Comodo" certificates
i.keytool -import -trustcacerts -alias root -file AddTrustExternalCARoot.crt -keystoreselfservice.keystore
And I have used correct chain of installation of certificate like root , all intermediate, primary from above command.
And while installing each certificate i received the following message
"Certificate added to keystore"
Though I have not got any error .
And when i have opened my keystore there were no certificate chain , means there is individual entry of each certificate . but there is no chain hierarchy of certificates like Root then intermediate then primary.
And in my final PI or certifcate, i am getting provider as local first name instead of Comodo .
EXAMPLE :
CN=nims.ABC.com,OU=abcCommunications,O=abc Group LLC, L=Roseville,ST=Minnesota,C=US
Provider must be
CN=COMODO RSA Organization Validation Secure Server CA,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB
So I would like to know which steps I have missed or used any extra steps .
Please provide a solution to install a wild card certificate .
Thanks in advance
You did everything correctly. The trust chain is important for another aspect. If you trust one 'certificate' of the chain, you trust the following 'certificates' of the chain too. So to trust all certs of a CA you just have to trust the root CA's cert.
What you realy need to make the wild card certificate work on you server is to import the private key part of it.
I assume you mean Tomcat using Java SSL (JSSE) not APR/Native (OpenSSL). If you want Tomcat-APR, change your question.
If the cert you want to use is already in use on other servers, and you "generated a public keystore using" the keytool command you showed on the NEW server, you generated a NEW KEY which is different from the key the other servers used and different from the key included in the certificate, thus the certificate DOES NOT MATCH that new key and cannot be used with that new key. You also implicitly generated (and have not replaced) a self-signed cert, with both subject and issuer (what you call provider) identifying you rather than a CA like Comodo. This certificate is not good for general use but can be useful for some testing, which is why keytool does it implicitly.
You need to get the certificate, the ALREADY EXISTING private key that MATCHES the certficate, and the needed chain cert(s) into your JKS as a privateKey entry. If an existing SSL server is Java (using JSSE), just copy its JKS. If you want or need to change the password(s) on the copy for your new server, see keytool -storepassword and keytool -keypasswd.
If an existing server is OpenSSL (including Apache httpd and nginx), convert the OpenSSL PEM format to PKCS#12 (preferably on the old server); depending on that server's file layout this is something like
openssl pkcs12 -export -in certfile -inkey keyfile -certfile chaincert -out xxx
and then use keytool to convert PKCS#12 to JKS (preferably on the new server)
keytool -importkeystore -srckeystore xxx -srcstoretype pkcs12 -destkeystore yyy
Note you must use a password on the PKCS#12. This does not need to be the same as the old server keyfile (if any) or the new server JKS, but it's usually more convenient if it is.
If an existing server is IIS, you should be able to export the cert WITH private key AS PFX/PKCS#12 from the Certificate snapin of mmc, and then convert the PKCS12 to JKS as just above.
If an existing server is something else, add it to the question.

Get rid of the "UNKNOWN" publisher from applet security warning

I'm trying to sign an applet so that the publisher does not appear as "UNKNOWN" :
I work for an organisation and we have our own certification authority, certificate chain is the following : ORG Root CA > ORG Trusted Certification Authority > Yann39 (me :D)
I requested a certificate and they provided me a link to get it into the browser.
Then I exported it (from Firefox) to get the PKCS#12 file that I named mystore.p12.
Then I did the following to sign my applet :
/* TO KNOW THE ALIAS */
c:\testrep>keytool -list -storetype pkcs12 -keystore mystore.p12
Enter keystore password: ********
Keystore type: pkcs12
Keystore provider: SunJSSE
Your keystore contains 1 entry
id de yann39, Oct 24, 2012, keyEntry,
Certificate fingerprint (MD5): D7:E3:83:1D:C1:40:68:72:5F:A8:6F:AC:3A:EA:DD:47
/* CREATE FAKE CLASS FILE AND BUILD A JAR */
c:\testrep>echo test > test.class
c:\testrep>C:\oracle\dev10gr2\jdk\bin\jar cf0 test_applet.jar test.class
/* SIGN THE JAR */
c:\testrep>C:\oracle\dev10gr2\jdk\bin\jarsigner -verbose -storetype pkcs12 -keystore mystore.p12 test_applet.jar "id de yann39"
Enter Passphrase for keystore: ********
updating: META-INF/MANIFEST.MF
adding: META-INF/ID_DE_YA.SF
adding: META-INF/ID_DE_YA.RSA
signing: test.class
/* VERIFY THE SIGNATURE */
c:\testrep>C:\oracle\dev10gr2\jdk\bin\jarsigner -verify -verbose -certs test_applet.jar
132 Wed Oct 24 17:49:52 CEST 2012 META-INF/MANIFEST.MF
185 Wed Oct 24 17:49:52 CEST 2012 META-INF/ID_DE_YA.SF
4801 Wed Oct 24 17:49:52 CEST 2012 META-INF/ID_DE_YA.RSA
0 Wed Oct 24 17:48:36 CEST 2012 META-INF/
sm 0 Wed Oct 24 17:47:46 CEST 2012 test.class
X.509, CN=Yann39, CN=794324, CN=myname, OU=Users, OU=Organic Units,
DC=myorg, DC=ch
X.509, CN=ORG Trusted Certification Authority, DC=myorg, DC=ch
X.509, CN=ORG Root CA, DC=myorg, DC=ch
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.
c:\testrep>
Then I load the appled in my application using the following :
<object id="mytestapplet" width="0" height="0" style="position:absolute" type="application/x-java-applet">
<param name="archive" value="https://myhost.ch/rep/test_applet.jar">
<param name="code" value="test">
<param name="scriptable" value="true">
<param name="mayscript" value="no">
</object>
I read some posts like this one : How to sign java applet with .pfx file? and it seems I should get smi when verifying signed file from the jar, not only sm that means the certificate was not found in the keystore.
So I thought the certificate chain was not complete, but when running the following command, I saw that it was not the case :
c:\testrep>keytool -list -v -storetype pkcs12 -keystore mystore.p12
Enter keystore password: ********
Keystore type: pkcs12
Keystore provider: SunJSSE
Your keystore contains 1 entry
Alias name: id de yann39
Creation date: Oct 24, 2012
Entry type: keyEntry
Certificate chain length: 3
Certificate[1]:
Owner: CN=Yann39, CN=794324, CN=myname, OU=Users, OU=Organic Units,
DC=myorg, DC=ch
Issuer: CN=ORG Trusted Certification Authority, DC=myorg, DC=ch
Serial number: 12d21eb200200000a02b
Valid from: Mon Jun 25 14:16:00 CEST 2011 until: Wed Jun 24 14:16:00 CEST 2013
Certificate fingerprints:
MD5: D7:E3:83:1D:C1:41:78:72:5F:A8:6D:BD:3A:ED:DD:48
SHA1: 24:31:1D:25:02:98:0D:F8:28:6A:F1:0E:E8:BB:04:7E:51:E2:E9:66
Certificate[2]:
Owner: CN=ORG Trusted Certification Authority, DC=myorg, DC=ch
Issuer: CN=ORG Root CA, DC=myorg, DC=ch
Serial number: 601fab4c000000000003
Valid from: Tue Oct 02 11:36:53 CEST 2006 until: Mon Oct 02 11:47:53 CEST 2016
Certificate fingerprints:
MD5: 51:A1:EA:33:21:2C:71:60:A1:6F:F1:22:92:A8:51:8D
SHA1: 66:CD:70:13:27:68:F3:C2:08:F3:BE:5F:BF:D4:17:BD:85:9D:10:65
Certificate[3]:
Owner: CN=ORG Root CA, DC=myorg, DC=ch
Issuer: CN=ORG Root CA, DC=myorg, DC=ch
Serial number: 7dc0d089138d1d804b2e68e21b947412
Valid from: Tue Oct 02 10:55:19 CEST 2006 until: Sat Oct 02 11:01:47 CEST 2026
Certificate fingerprints:
MD5: A2:CE:DC:7D:F5:60:D7:2C:5E:B5:29:74:9D:51:F9:49
SHA1: DA:D8:7F:63:95:90:A2:E4:D4:1D:B9:48:FD:F4:C3:5C:FC:2B:B6:A3
*******************************************
*******************************************
c:\testrep>
The chain seems good.
But I still get the security warning with an "UNKNOWN" Publisher. Why ?
EDIT 25-OCT-2012
I forgot to say that it works using Internet Explorer ("Signature has been verified" and Publisher is "Yann39"), not using Chrome or Firefox.
I tried using a self-signed certificate :
keytool -genkey -alias myalias -storetype PKCS12 -keystore mykeystore.p12 -dname "cn=Yann39, ou=UN, o=ORG, st=Geneva, c=CH"
keytool -list -v -storetype pkcs12 -keystore mykeystore.p12
echo test > test.class
C:\oracle\dev10gr2\jdk\bin\jar cf0 myapplet.jar test.class
C:\oracle\dev10gr2\jdk\bin\jarsigner -verbose -storetype pkcs12 -keystore mykeystore.p12 myapplet.jar "myalias"
C:\oracle\dev10gr2\jdk\bin\jarsigner -verify -verbose -certs myapplet.jar
It does not work neither in IE nor in Firefox or Chrome, normal.
I tried to add the 2 trusted certificates from my organisation but it failed :
keytool -import -alias "myalias_root" -file ORGRooTCA.crt -storetype pkcs12 -keystore mykeystore.p12
keytool -import -alias "myalias_auth" -file ORGTrustedCertificationAuthority.crt -storetype pkcs12 -keystore mykeystore.p12
with the error :
keytool error: java.security.KeyStoreException: TrustedCertEntry not supported
I still don't understand why it says that the certificate was not found in the keystore (sm) when verifying the signature.
EDIT 02-NOV-2012
I finally got a reply from my Certification Authority. As code signing certificates are provided for test only (not officially supported in our organisation), they don't provide any help and they closed my ticket...
The 2 certificates ORG Root CA and ORG Trusted Certification Authority are trusted in the 3 browsers (IE, Firefox, Chrome). When running my applet I still get the expected result in IE :
Name: applettest
Publisher: Yann39
From: https://myhost.ch
But not in Firefox and Chrome :
Name: test
Publisher: UNKNOWN
From: https://myhost.ch
Another strange thing is that as you see IE is referencing as “Name” the id of the <object> tag used in the HTML (applettest), while Firefox and Chrome are referencing the name of the main class (test).
What I think is that it is the same thing about the Publisher, IE is looking at the CN RDN (Yann39) while Firefox and Chrome are looking at the O RDN and cannot find one as it is not defined in my certificate.
If anyone has more information about how browsers check the certificates please share.
Thanks.
If you have your own CA and sign applets with certificates issued by that CA, then you obviously need to add that CA's certificate to the list of trusted certificate authorities.
When running inside IE, the Java plugin seems to be able to use the system list of CA, so you just need to add your CA certificate to the system certificate storage (be sure to manually choose the certificate destination as a trusted CA during the import).
When running inside Chrome or Firefox, the Java plugin for some reason does not use system certificate storage, but only its own separate certificate storage. You will get the "insecure" security warning with "UNKNOWN" publisher when running applet in these browsers if the CA's certificate is not present in the Java plugin certificate storage, regardless of whether it is in the "trusted CA" system certificate storage.
To add a certificate to Java plugin storage:
open Java control panel
select "Security" tab
click "manage Certificates..." button
select "Signer CA" option in the "Certificate type" combo-box.
import your CA's certificate
The next time you use Chrome or Firefox to run your applet, you will have a normal "secure" security warning with the option to trust that applet forever.
You need to add CA certificates (up to the root CA) to your p12 file before signing.
The same strange "UNKNOWN" Message appeared when I changed my signing certificate. I imported the certificate of my signing keystore into cacerts (so that my self signed jar would be accepted), but the java cache held the old jarfile. Then when starting the "old" applet with the "new" certificate, a message similar to the one above appeared.
Solution: clear the java cache (via java control panel or javaws -uninstall).
This just in case someone (like myself) stumbles upon this Thread while searching for this Error Message.
I tried to add the 2 trusted certificates from my organisation but it
failed :
Emm... all seems quite unclear because you demo the signing process since certs import only...
I tried using a self-signed certificate It does not work neither in
IE nor in Firefox or Chrome, normal. I tried to add the 2 trusted
certificates from my organisation but it failed :
Of course, it failed. Because you cannot import certs to get chain for non-original keys. And coming back to your test case...
All I can see in your test case things like:
A) You gen maybe myalias or maybe myalias_root and
myalias_auth key(s) - give more details here
B) You try to import ORGRooTCA and
ORGTrustedCertificationAuthority
C) You try to sign a test jar
In step B You try to import 2 certs. So I must ask
Were the two certs generated by using myalias_root and
myalias_auth CSR(s)?
If they weren't so I suppose you just skipped some steps as follows:
A) Gen myalias_root and
myalias_auth key(s)
B) Gen CSR of myalias_root_root and myalias_auth
C) Gen certs ORGRooTCA and ORGTrustedCertificationAuthority by using myalias_root and
myalias_auth CSR(s)
D) import the certs as ORGRooTCA and ORGTrustedCertificationAuthority to get chain
E) Try to sign a test jar
And once again...
I tried to add the 2 trusted certificates from my organisation but it
failed :
As a result, I can advice you
A) Get not only certs from your organization but also its
keystore keys the certs were generated of
B) Or gen your own keys and your own certs by following the
previously mentioned ABCDE steps :)
I requested a certificate and they provided me a link to get it into
the browser. Then I exported it (from Firefox) to get the PKCS#12 file
that I named mystore.p12.
You manually imported it and then you exported it as described here ?
OK... it is quite interesting. If you still sure all things in your pfx right :S still I re-play the your jarsigner using demo. So you sign the test_applet.jar as
/* SIGN THE JAR */
c:\testrep>C:\oracle\dev10gr2\jdk\bin\jarsigner -verbose -storetype pkcs12 -keystore mystore.p12 test_applet.jar "id de yann39"
Enter Passphrase for keystore: ********
updating: META-INF/MANIFEST.MF
adding: META-INF/ID_DE_YA.SF
adding: META-INF/ID_DE_YA.RSA
signing: test.class
... it's pretty standard signing way but I want to point a little detail... I cannot see where jarsigner demands you to enter the "id de yann39" private key password :S ? All I can see you enter keystore password only ... Is the step skipped in your copy-paste version or jarsigner is really doesn't demand you to enter key password?
As a trial, I do recommend you to try sign your jar using -keypass arg as (see example)
jarsigner -keystore C:\working\mystore -storepass myspass
-keypass dukekeypasswd MyJarFile.jar duke
For more details see how to use jarsigner docs...
I don't made any changes to the certificate, so yes I guess it is the
original private key ? About your edit: yes I exported it as described
in your link, but I used "backup all", not "backup" only, else I don't
get the whole certificate chain in my .p12 file. About signing the
.jar file, I don't skipped anything, jarsigner only ask me for the
keystore password. I think keystore password and private key password
are the same,
If you generated keys in your keystore with keytool you must know that keystore has its password and newly generated private key(s) should have its own password; So I suppose maybe something is missing here :S It would be interesting you A) import your pfx to IE and export it with IE as described here : since the "Yes export the private key" instructions + "Include all certificates in the certification path if possible"
P.S.
Please comment if that was helpful

Categories

Resources