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
Related
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.
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 :)
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?
To make a SSL connection with some server, whenever i run following command, followed by key-store default password "changeit" in windows to import the certificate in java keystore, following error occurred:
COMMAND :
keytool -import -file "E:\postgrescert\server.crt" -keypass changeit -keystore "C:\Java\JDK\jre\lib\security\cacerts" -alias pgssslninet
ERROR:
keytool error: java.lang.Exception: Input not an X.509 certificate
The server.crt is having below content:
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
a1:ea:8c:61:61:0a:7d:69
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=CA, L=fg, O=XYZ, OU=IT, CN=Common Name/emailAddress=xyz.some#org.com
Validity
Not Before: Jun 14 23:59:25 2013 GMT
Not After : Jul 14 23:59:25 2013 GMT
Subject: C=US, ST=CA, L=fg, O=XYZ, OU=IT, CN=Common Name/emailAddress=xyz.some#org.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:de:7c:dd:6e:5f:98:85:52:b4:13:45:2d:69:26:
61:6c:d7:ad:d6:12:27:bf:e1:07:53:a4:76:27:29:
ca:3d:82:e5:63:8c:9e:a5:b0:24:f6:77:86:92:ab:
42:e5:26:8a:4a:ea:ea:4a:65:20:a1:3b:05:c7:e0:
31:8e:4c:6e:e5:9e:e4:9c:de:05:02:b3:59:70:00:
df:fb:b9:62:e1:5b:8e:1b:29:2d:7c:41:86:41:a9:
9e:24:f8:65:54:8c:cf:44:c4:7b:fa:12:b4:84:d1:
d7:d7:2f:14:32:f9:2e:7b:c2:d8:0b:35:c9:f5:8b:
64:ed:cf:84:6e:bf:97:d0:44:7b:6b:67:c6:5b:6f:
92:5d:f6:d7:01:b6:ba:96:37:c8:3b:f8:be:01:b5:
02:d1:6b:21:67:83:c8:fd:37:bd:70:e5:c1:e4:81:
b0:42:a9:04:b1:3d:33:4c:43:2b:33:cc:50:65:1e:
c0:15:8d:e3:5f:b0:9c:d9:04:09:18:e7:8f:80:56:
6f:45:1d:0a:c2:2d:02:7e:67:2a:8a:1b:73:4a:db:
80:e0:52:d6:33:23:c7:aa:48:b0:5c:ad:7f:8c:96:
7c:d4:84:61:4d:ae:d3:9c:ef:59:c1:bd:71:83:c3:
5e:a4:04:84:8f:cd:76:82:3a:86:43:ab:c1:f4:e9:
02:d5
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
C1:4F:FA:2E:8F:F3:36:FE:AE:9B:12:73:C7:08:C9:59:96:53:71:A7
X509v3 Authority Key Identifier:
keyid:C1:4F:FA:2E:8F:F3:36:FE:AE:9B:12:73:C7:08:C9:59:96:53:71:A7
X509v3 Basic Constraints:
CA:TRUE
Signature Algorithm: sha1WithRSAEncryption
6b:2f:5f:33:f8:bb:55:66:c3:48:c9:ae:64:c1:89:5b:e1:54:
9a:bc:ae:34:87:7e:bc:e7:30:26:9e:65:58:42:79:19:e2:ee:
93:2a:c7:2d:a9:45:b4:1c:7b:5f:5a:ec:12:e3:76:38:c5:44:
aa:7f:bd:60:b6:a6:83:90:68:9d:8f:1c:7a:69:4a:58:a8:55:
5a:36:9e:e3:69:76:50:0e:4c:30:54:11:4c:de:10:91:6f:aa:
49:34:19:1c:96:cb:8a:6c:fd:df:19:ed:e1:84:2b:05:12:68:
e6:af:c5:59:c2:61:ca:10:2c:8e:cc:0a:34:7e:08:e5:22:ac:
01:fd:fc:4d:16:4f:66:29:58:ac:8e:25:79:3d:de:b6:ef:55:
6e:26:c5:75:9d:6d:57:4e:02:89:b8:c1:b8:47:b7:09:9b:07:
cf:5b:a3:bc:a3:6b:ef:a1:4c:95:a0:be:0f:d4:63:fe:35:c6:
c6:42:10:0b:28:13:02:a3:6e:b3:bf:ae:57:a8:bd:a1:25:6a:
2d:cd:c7:20:64:4b:2e:f2:b2:c9:5c:85:cf:6f:de:39:86:84:
94:d3:01:c5:25:b7:ec:65:1b:5f:93:ec:9d:cc:81:fa:c7:34:
fc:e4:e2:5c:3f:4b:cc:83:bb:f0:67:88:1f:f6:a1:3b:9e:00:
7b:ba:b2:79
-----BEGIN CERTIFICATE-----
MIID7zCCAtegAwIBAgIJAKHqjGFhCn1pMA0GCSqGSIb3DQEBBQUAMIGNMQswCQYD
VQQGEwJVUzELMAkGA1UECAwCQ0ExEDAOBgNVBAcMB0ZyZW1vbnQxEjAQBgNVBAoM
CURhdGFndWlzZTELMAkGA1UECwwCSVQxFDASBgNVBAMMC0NvbW1vbiBOYW1lMSgw
JgYJKoZIhvcNAQkBFhlzcmluaS5zdWJyYUBkYXRhZ3Vpc2UuY29tMB4XDTEzMDYx
NDIzNTkyNVoXDTEzMDcxNDIzNTkyNVowgY0xCzAJBgNVBAYTAlVTMQswCQYDVQQI
DAJDQTEQMA4GA1UEBwwHRnJlbW9udDESMBAGA1UECgwJRGF0YWd1aXNlMQswCQYD
VQQLDAJJVDEUMBIGA1UEAwwLQ29tbW9uIE5hbWUxKDAmBgkqhkiG9w0BCQEWGXNy
aW5pLnN1YnJhQGRhdGFndWlzZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
ggEKAoIBAQDefN1uX5iFUrQTRS1pJmFs163WEie/4QdTpHYnKco9guVjjJ6lsCT2
d4aSq0LlJopK6upKZSChOwXH4DGOTG7lnuSc3gUCs1lwAN/7uWLhW44bKS18QYZB
qZ4k+GVUjM9ExHv6ErSE0dfXLxQy+S57wtgLNcn1i2Ttz4Ruv5fQRHtrZ8Zbb5Jd
9tcBtrqWN8g7+L4BtQLRayFng8j9N71w5cHkgbBCqQSxPTNMQyszzFBlHsAVjeNf
sJzZBAkY54+AVm9FHQrCLQJ+ZyqKG3NK24DgUtYzI8eqSLBcrX+MlnzUhGFNrtOc
71nBvXGDw16kBISPzXaCOoZDq8H06QLVAgMBAAGjUDBOMB0GA1UdDgQWBBTBT/ou
j/M2/q6bEnPHCMlZllNxpzAfBgNVHSMEGDAWgBTBT/ouj/M2/q6bEnPHCMlZllNx
pzAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQBrL18z+LtVZsNIya5k
wYlb4VSavK40h3685zAmnmVYQnkZ4u6TKsctqUW0HHtfWuwS43Y4xUSqf71gtqaD
kGidjxx6aUpYqFVaNp7jaXZQDkwwVBFM3hCRb6pJNBkclsuKbP3fGe3hhCsFEmjm
r8VZwmHKECyOzAo0fgjlIqwB/fxNFk9mKVisjiV5Pd6271VuJsV1nW1XTgKJuMG4
R7cJmwfPW6O8o2vvoUyVoL4P1GP+NcbGQhALKBMCo26zv65XqL2hJWotzccgZEsu
8rLJXIXPb945hoSU0wHFJbfsZRtfk+ydzIH6xzT85OJcP0vMg7vwZ4gf9qE7ngB7
urJ5
-----END CERTIFICATE-----
Can anyone help me to locate the exact issue behind this error.
PS : When i removed every thing above -----BEGIN CERTIFICATE-----, it get successfully imported. Does the information above -----BEGIN CERTIFICATE----- is really required. Please help.
Regards,
Arun
Can anyone help me to locate the exact issue behind this error.
Keytool can handle two formats. One is ASN.1/DER encoding, which looks like binary data under a hex editor. The other is RFC 1421, Certificate Encoding Standard, which is a Base64 encoding of the certificate. See the docs on the Keytool at the Solaris site.
When i removed every thing above -----BEGIN CERTIFICATE-----, it get successfully imported. Does the information above -----BEGIN CERTIFICATE----- is really required.
The format you describe above is Internet RFC 1421 Certificate Encoding Standard. Keytool should be able to handle the format. The manual clearly states that format is allowed:
Certificates are often stored using the printable encoding format
defined by the Internet RFC 1421 standard, instead of their binary
encoding. This certificate format, also known as "Base 64 encoding",
facilitates exporting certificates to other applications by email or
through some other mechanism.
...
Certificates read by the -import and -printcert commands can be in
either this format or binary encoded.
In the above, the "this format" is RFC 1421. The "binary encoded" is ASN.1/DER.
With that said, the certificate looks like a client certificate since it has a PKCS#9 email address in the Common Name, and it does not have a DNS name (like example.com). Yet is also has a Basic Constraint of CA=TRUE.
Placing email addresses and DNS names in the Common Name field is deprecated by both the IETF and CA/B Forums. Those names should be placed in Subject Alternate Name field. Use the Common Name for a friendly name or a display name like "John Doe" or "Datametrics".
Java also seems to follow the IETF standards closer than most others (others meaning tools and libraries; and not standards). But the RFCs tend to run fast and loose, and I don't recall the PKCS#9 email address/CA=TRUE flag being prohibited.
That issue may affect its import-ability. Bruno or EJP would probably know for certain.
Same problem here. I just added an empty line at the end and keytool was happy.
I had following qustions about timestamping a jar: (exe timestamping is working fine)
Do we have to "purchase" anything for timestamping , similar to code signing certificate?
Is it mandatory to timestamp the exe/jar from the same TSA , with which it is signed? We have purchased a code signing certificate from GoDaddy.
The "http://support.godaddy.com/help/article/4833/about-code-signing-certificates" link of GoDaddy says:
Is there a limit to the amount of time stamp requests allowed for a
Code Signing certificate? No. Unlike some of our competitors, we do
not limit the number of time stamp requests which can be issued by a
single Code Signing certificate.
From above statement, I understand tha the timestamp can be done, if you have code signing certificate purchased.
using command:
jarsigner -keystore mykeys -sigfile SIG -signedjar SignedApp.jar -tsacert testalias app.jar johndoe
where testalias is the TSA's public key certificate.
Where can I get GoDaddy's TSA public key certificate ?
If I use below command to timestamp
jarsigner -verbose -keystore C:\a.pfx -storepass <password> -storetype pkcs12 C:\abc.jar -tsa http://tsa.starfieldtech.com <pfx certificate alias>
I get the following error:
jarsigner: Certificate chain not found for: -tsa. -tsa must reference a valid KeyStore key entry containing a private key and corresponding public key certificate chain.
Apart from How to validate if a signed jar contains a timestamp?, is there any easier way to check the
timestamp of a jar
No, you don't have to purchase anything else. Your certificate is enough.
It is desirable to timestamp your jars, because otherwise they will expire when your certificate expire.
It looks like you permuted the options for jarsigner. Try this order:
jarsigner -verbose -keystore C:\a.pfx -storepass <password> -storetype pkcs12 -tsa http://tsa.starfieldtech.com C:\abc.jar "<pfx certificate alias>"