How does my java application get a public key, for example the google or facebook domains WITHOUT THE NEED to add their .cer files in cacerts keystore?
I suspect that the reason is that such domains use well-known Certification authority, CA, that may already be in java cacerts keystore file (depending on version java? I tried to see if there are certificates up to 2030-2040 validity, or I'm wrong in my theory). But if I guess correctly, then where are the public keys from these domains stored? I would like an expert opinion on this matter.
You are correct - if a cert provided by a server is not signed by recognised CA then the cert that signed the provided cert needs to be added to CACERTS. By recognised CA I mean one that is the CACERTS of the default Java install.
Strictly speaking it's a bit more complicated. A cert will be trusted if it's signing path (signed-by, signed-by...) can be traced back in the cert chain provided by the server to one in CACERTS.
The public keys are part of the certs. If you want to see all the public keys in CACERTS run the following from your JAVA_HOME with bin on the path:
keytool -list -rfc -keystore jre/lib/security/cacerts
password is changeit
This will give you lots of output that will include the actual certs, eg:
-----BEGIN CERTIFICATE-----
MIICsDCCAhmgAwIBAgIQZ8jh6OO+HL38kTuOpiOHSTANBgkqhkiG9w0BAQUFADCB
izELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxML
RHVyYmFudmlsbGUxDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUVGhhd3RlIENl
cnRpZmljYXRpb24xHzAdBgNVBAMTFlRoYXd0ZSBUaW1lc3RhbXBpbmcgQ0EwHhcN
OTcwMTAxMDAwMDAwWhcNMjEwMTAxMjM1OTU5WjCBizELMAkGA1UEBhMCWkExFTAT
BgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxDzANBgNV
BAoTBlRoYXd0ZTEdMBsGA1UECxMUVGhhd3RlIENlcnRpZmljYXRpb24xHzAdBgNV
BAMTFlRoYXd0ZSBUaW1lc3RhbXBpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBANYrWHhhRYZT6jR7UZztsOYuGA7+4F+oJ9O0yeB8WU4WDnNUYMF/9p8u
6TqFJBU820cEY8OexJQaWt9MevPZQx08EHp5JduQ/vBR5zDWQQD9nyjfeb6Uu522
FOMjhdepQeBMpHmwKxqL8vg7ij5FrHGSALSQQZj7X+36ty6K+Ig3AgMBAAGjEzAR
MA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQEFBQADgYEAS+mqF4EF+3kKMZ/F
QfRWVKvpwuWXjhj+kckMPiZkyaFMJ2SnvQGTVXFuF0853BvcSTUQOSP/ypvIz2Y/
3Ewa1IEGQlIf4SaxFhe65nByMUToTo1b5NP50OOPJWQx5yr4GIg2GlLFDUE1G2m3
JvUXzMEZXkt8XOKDgJH6L/uatxY=
-----END CERTIFICATE-----
Then use a site like this to inspect the public key - it is under 'RAW OUTPUT"
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (1024 bit)
Modulus:
00:d6:2b:58:78:61:45:86:53:ea:34:7b:51:9c:ed:
b0:e6:2e:18:0e:fe:e0:5f:a8:27:d3:b4:c9:e0:7c:
59:4e:16:0e:73:54:60:c1:7f:f6:9f:2e:e9:3a:85:
24:15:3c:db:47:04:63:c3:9e:c4:94:1a:5a:df:4c:
7a:f3:d9:43:1d:3c:10:7a:79:25:db:90:fe:f0:51:
e7:30:d6:41:00:fd:9f:28:df:79:be:94:bb:9d:b6:
14:e3:23:85:d7:a9:41:e0:4c:a4:79:b0:2b:1a:8b:
f2:f8:3b:8a:3e:45:ac:71:92:00:b4:90:41:98:fb:
5f:ed:fa:b7:2e:8a:f8:88:37
Exponent: 65537 (0x10001)
Related
I have a customer who replaced the keystore and truststore of our product components. After replacement the components can't communicate with each other (2 way SSL).
On SSL logs I see:
http-nio-8100-exec-2, fatal error: 42: null cert chain
javax.net.ssl.SSLHandshakeException: null cert chain
%% Invalidated: [Session-6, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256]
http-nio-8100-exec-2, SEND TLSv1.2 ALERT: fatal, description = bad_certificate
http-nio-8100-exec-2, WRITE: TLSv1.2 Alert, length = 2
http-nio-8100-exec-2, fatal: engine already closed. Rethrowing javax.net.ssl.SSLHandshakeException: null cert chain
They have configured the same keystore and truststore files on both sides.
I've opened their keystore and truststore and this is how they are built:
keystore
entry1 - server
cert[1] MD5: X
cert[2] MD5: Y
cert[3] MD5: Z
truststore
entry1 - root
cert[1] MD5: Z
entry2 - intermediate
cert[1] MD5: Y
It seems to me that the fact that cert[1] in the keystore (with MD5 X) is missing from the truststore is problematic.
Am I right?
Can you see any other problem with the way their keystore and truststore was built?
It looks like your problem is related to some missing certificates either in your keystore and/or truststore.
Generally speaking, when the client sends a request to the server, the server presents its certificate chain which must include the server's certificate as the first entry followed by its issuer and other issuers. Each following certificate must directly certify the one preceding it unless it is present in the truststore on the client-side.
You need to check whether your cert[1] in keystore is a self-signed certificate. You can achieve this in the following way:
For .jks Java keystore type:
keytool -list -v -keystore [keystore-file-name].jks
-For #PKCS12 keystore type:
keytool -list -keystore [keystore-file-name].p12 -storetype PKCS12 -v
When the certificate is printed, check the 'Issuer' attribute.
If it matches the 'Owner' attribute, it means it's a self-signed certificate and you need to add the 'cert[1]' into the truststore.
If they don't match, try one of the following alternatives:
Generate a new 'cert[1]' signed by either 'Y' or
'Z' and add it into the keystore or replace the existing one. The decision whether to replace it or add depends how your code reads the certificate. A replacement might be a better option.
Add the current 'Issuer' of 'cert[1]' of the keystore into the
truststore.
If the certificate of the 'Issuer' of 'cert[1' in the keystore is already present in the truststore, I would've expected the SSL handshake to be successful.
Here is how you add an issuer to a truststore:
1) Get hold of the Public Certificate of the issuer, which is stored in .cer file. If the issuer is self-generated and you've got access to its keystore, the certificate an be exported from there using the following command:
keytool -export -keystore [issuer-keystore].jks -alias [alias]-file [output-file-name].cer
2) Import the .cer file into the truststore:
keytool -importcert -file [output-file-name].cer -keystore [truststore-file-name].jks -alias [alias]
Am I right?
No. As long as the truststore contains one of the certificates in the keystore's certificate chain, it should trust the certificate in the KeyStore.
I have self signed certificates for my https protocol based web application.but I want to know the domain mentioned in the keystore/truststore.
can any one help me to know it?
List certificates in keystore using following command:
keytool -list -v -keystore yourkeystorefile -storepass keystorepassword
Find your certificate and check the common name (CN) value in "Owner" tag. This is the domain name the certificate is created for.
Alternative domain names you may use are listed in optional SubjectAlternativeName section.
Before adding new certificates in keystore or truststore its good to see, count and verify already installed certificates. run following keytool command to get a list of certififcates from keystore:
javin#localhost:C/Program Files/Java/jdk1.6.0_26/jre/lib/security keytool -list -keystore cacerts
Enter keystore password: changeit
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 76 entries
digicertassuredidrootca, 07/01/2008, trustedCertEntry,
Certificate fingerprint (MD5): 87:CE:0B:7B:2A:0E:49:00:E1:58:71:9B:37:A8:93:72
trustcenterclass2caii, 07/01/2008, trustedCertEntry,
Certificate fingerprint (MD5): CE:78:33:5C:59:78:01:6E:18:EA:B9:36:A0:B9:2E:23
You see currently keystore "cacerts" holds 76 certificates.
Read more: http://javarevisited.blogspot.com/2012/03/add-list-certficates-java-keystore.html#ixzz39n3jfusy
Our IT dept gave me 4 .cer files, that constitute certificate chain: thawte_root.cer->intermediate1_pem.cer->intermediate2_pem.cer->our_company.cer.
I need to sign some code (via jarsigner) using our_company.cer.
Therefore, I have to create a keystore, containing our_company.cer and the chain-to-the-root.
I've tried to simply concatenate these 4 files into one using notepad and then import the resulting file, but keystore imports only the first one and when I try to launch jarsigner, I get
"jarsigner: Certificate chain not found for: our_company. our_company must reference a valid KeyStore key entry containing a private key and corresponding public key certificate chain."
I get the same message when I import only our_company.cer or when I import each certificate one-by-one.
So the question is: how can I import 4 certificates as one chain?
Thanks in advance. Vitaly.
Chain all certificates into one file (order is sub to root)
cat intermediate2_pem.cer intermediate1_pem.cer thawte_root.cer > chain.cer
Run this openssl command
openssl pkcs12 -export -in our_company.cer -inkey private.key -out company.p12 -name company -CAfile chain.pem -caname sub2 -caname sub1 -caname root -chain
Create keystore
keytool -importkeystore -destkeystore company.keystore -srckeystore company.p12 -srcstoretype PKCS12 -alias company
Your keystore will be ready (pick a password and type it in for all circumstances). You will also need to have your private.key ready.
See this link for more detailed information.
As you probably know, code signing works using public-key encryption. To sign code you need to have a private key, and clients wanting to use your code must trust the corresponding public key.
The CER files that you have are certificate files corresponding to the public keys. When you import them with keytool -importcert without the corresponding private keys, they are imported as trusted certificates. (See the documentation for more details. Depending on your system setup, you probably don't need to import them all - you probably already trust the Thawte certificate, for example.)
Since you want to sign code as YourCompany, you will need the private key corresponding to our_company.cer - I suppose your IT department can provide this, since it will have been used to generate the Certificate Signing Request sent to Thawte. If they are not willing to pass this on to you you will need to generate your own private/public key pair using keytool -genkeypair, generate a CSR with keytool -certreq and send it to your IT department who can then issue you a certificate. The final chain of trust in this case would be thawte_root.cer->intermediate1_pem.cer->intermediate2_pem.cer->our_company.cer->your_department.cer
so here's what I'm trying to do:
I connect to my SSL server
It sends me two certificates, and one of them is self-signed
At this stage, there are no problems, I've:
X509Certificate[] myTwoCerts;
// with 2 certificates in there, and I'm sure it's there because, I print them in my console.
Now I want to create .p12 file with 2 certificates inside.
Until now, I've tried something like this:
KeyStore pkcs12Store = KeyStore.getInstance("PKCS12");
pkcs12Store.load(null, null);
X509Certificate cert1 = myTwoCerts[0];
X509Certificate cert2 = myTwoCerts[1]
String alias1 = "FIRST";
String alias2 = "SECOND";
pkcs12Store.setCertificateEntry(alias1, cert2);
pkcs12Store.setCertificateEntry(alias2, cert2);
But I'm getting the following Exception:
Exception in thread "main" java.security.KeyStoreException: TrustedCertEntry not supported
Can anybody help me plz??
The PKCS12 keystore in Java cannot be used to store certificates or certificate chains without their private keys.
See this note in the JCA reference guide:
"pkcs12" is another option. This is a cross platform keystore based on the RSA PKCS12 Personal Information Exchange Syntax Standard. This standard is primarily meant for storing or transporting a user's private keys, certificates, and miscellaneous secrets. As of JDK 6, standards for storing Trusted Certificates in "pkcs12" have not been established yet, and thus "jks" or "jceks" should be used for trusted certificates.
(Despite mentioning JDK 6, this still is in the JDK 7 documentation.)
If you want to store a private key + certificate (chain) in a PKCS#12 store in Java, there needs to be a private key and you need to use the setKeyEntry method.
keytool -trustcacerts -keystore keystore.p12 -storetype pkcs12 -alias root -genkeypair
KeyStore pkcs12 = KeyStore.getInstance("PKCS12");
String filename = "/tmp/keystore.p12";
keyStore.load(
new FileInputStream(/*"myKeyStore.jks"*/filename),
password);
Our company purchased a code signing certificate from Thawte a few weeks ago. When we finally received the certificate from the purchasing team they didn't know the alias for the certificate!
I don't seem to be able to import the cert without the alias and they have no clue at all what it is. Is there a way of retrieving the alias? Has anybody else run into this problem? Is there any way of importing without the alias?
The alias is specified during the creation of the private key of the RSA certificate. It is not decided by the certificate signing authority, rather by the person creating the private and public keys.
I can't speak on whether your purchasing department ought to know this, but you'll need to check with the person/department who generated the CSR to determine the toolkit used to generate the CSR, and the key store format.
Now, assuming that the Java keytool utility was utilized to create the CSR, and that the private key is managed in a JKS keystore, you can utilize the keytool command to determine the contents (and hence the alias) of the keystore. This can be done using the keytool -list as indicated in the other answer. A sample run is demonstrated below, with the alias appearing in the output:
keytool -list -v -keystore foo.jks
Enter keystore password:
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 1 entry
Alias name: foo
Creation date: Sep 1, 2010
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=foo, OU=foo, O=foo, L=foo, ST=foo, C=foo
Issuer: CN=foo, OU=foo, O=foo, L=foo, ST=foo, C=foo
Note that you do not need to know the keystore password to read the contents of the keystore, in which case a warning will be displayed.
In case you are using another toolkit and/or keystore format, you'll need to adopt a similar approach to determine the contents of the keystore, for the alias is not bound to appear in the CSR.
Try with:
keytool -list -keystore certificate.jks
(Note that if your keystore isn't JKS, for example, PKCS12, you can add an optional -storetype option to change the keystore type:)
keytool -list -keystore certificate.p12 -storetype PKCS12
You'll have something like:
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 1 entry
mykey, Feb 1, 2010, trustedCertEntry,
Certificate fingerprint (MD5): 0F:73:59:5C:35:8C:F2:F0:27:7E:F7:B7:AF:0A:95:B4
Your certificate alias is shown on the first line of the certificate description, here 'mykey'.