Below is my current JKS
bash-3.2$ keytool -list -keystore /web/myfolder/maincert.jks
Enter keystore password:
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 4 entries
root, Aug 1, 2017, trustedCertEntry,
Certificate fingerprint (SHA1): 02:FA:F3:E2:91:43:54:68:60:78:57:69:4D:F5:E4:5B:68:85:18:68
maincert, Aug 1, 2017, PrivateKeyEntry,
Certificate fingerprint (SHA1): A0:BF:8A:61:D7:AE:82:A6:EE:4B:EB:E0:22:19:73:2E:FC:85:F8:AC
intermediate2, Aug 1, 2017, trustedCertEntry,
Certificate fingerprint (SHA1): 70:60:8B:40:D0:B7:76:17:4A:4E:D8:54:16:58:27:70:B3:07:B9:05
intermediate1, Aug 1, 2017, trustedCertEntry,
Certificate fingerprint (SHA1): EA:B0:40:68:9A:0D:80:5B:5D:6F:D6:54:FC:16:8C:FF:00:B7:8B:E3
I then deleted the "maincert" using this command
keytool -delete -alias maincert -keystore /web/myfolder/maincert.jks
Then i added the CA signed new cert [maincert.crt_2018] with the same old alias name as shown below:
keytool -import -file /web/myfolder/maincert.crt_2018 -alias maincert -keystore /web/myfolder/maincert.jks
But the new cert now shows as trusted entry in the JKS instead of PrivateKeyEntry like before. Please see below:
bash-3.2$ keytool -list -keystore /web/myfolder/maincert.jks
Enter keystore password:
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 4 entries
root, Aug 1, 2017, trustedCertEntry,
Certificate fingerprint (SHA1): 02:FA:F3:E2:91:43:54:68:60:78:57:69:4D:F5:E4:5B:68:85:18:68
maincert, Aug 28, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): D2:7F:D0:86:79:0D:F3:06:66:C4:09:2E:29:A0:8F:8A:F3:E2:09:10
intermediate2, Aug 1, 2017, trustedCertEntry,
Certificate fingerprint (SHA1): 70:60:8B:40:D0:B7:76:17:4A:4E:D8:54:16:58:27:70:B3:07:B9:05
intermediate1, Aug 1, 2017, trustedCertEntry,
Certificate fingerprint (SHA1): EA:B0:40:68:9A:0D:80:5B:5D:6F:D6:54:FC:16:8C:FF:00:B7:8B:E3
Can you please suggest what is the problem here ?
The issue was that the crt certificate file was corrupt.
With the correct crt I did not have to delete anything from the JKS ... simply adding the crt worked and now it shows PrivateKeyEntry
Related
I have a 'test6r.jks' file which conatins 1 private key and 3 trusted certs I would like to get 3 crts as public.pem and private key as private.pem
keytool -list -keystore test6r.jks
Enter keystore password:
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 4 entries
symantecclass3secureserverca-g4, Mar 25, 2015, trustedCertEntry,
Certificate fingerprint (SHA1):
FF:67:36:7C:5C:D4:DE:4A:E1:8B:CC:E1:D7:0F:DA:BD:7C:86:61:35
verisignsvrg3, Mar 25, 2015, trustedCertEntry,
Certificate fingerprint (SHA1): 5D:EB:8F:33:9E:26:4C:19:F6:68:6F:5F:8F:32:B5:4A:4C:46:B4:76
verisignroot, Mar 25, 2015, trustedCertEntry,
Certificate fingerprint (SHA1): 4E:B6:D5:78:49:9B:1C:CF:5F:58:1E:AD:56:BE:3D:9B:67:44:A5:E5
test6r, Nov 9, 2016, PrivateKeyEntry,
Certificate fingerprint (SHA1): C9:E4:A7:CB:A1:31:89:DA:EE:59:A3:50:CD:0E:04:7D:36:6B:23:CB
How do I export trusted certificates from jks file to .pem and get the private key as .pem?
For mostly learning purposes so far, I'm attempting to generate a SHA2 Certificate using Java's keytool. However, when I generate the keys, it says that Certificate Fingerprint is SHA1, not SHA2.
keytool -genkey -alias test_sha2_rsa_key -keyalg RSA -keysize 2048 -keystore .keystore -sigalg "SHA256withRSA"
Here is the result when I list the keys.
keytool -list
Enter keystore password:
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 1 entry
test_sha2_rsa_key, Jul 6, 2016, PrivateKeyEntry,
Certificate fingerprint (SHA1): DD:9E:55:B7:90:9F:91:6C:68:D3:5C:24:E7:D4:45:D1:7D:8C:3A:5A
Am I reading this wrong, or doing this wrong?
The SHA-1 fingerprint is calculated over the binary (DER) encoded certificate. It is not contained in the certificate and is - as Dave already stipulated - not related with the signature over the tbsCertificate (the part of the certificate "to be signed"). Actually, as it is over the entire certificate, the signature algorithm reference (OID) and signature itself is also included in the fingerprint data.
Beware that fingerprinting a certificate using SHA-1 is about as safe as signing a certificate with SHA-1. It depends on how the fingerprint is used, but in principle this could introduce a vulnerability if (or when) SHA-1 is broken.
Jetty 9.3.1.v20150714 configured with a keystore containing 3 certificates: server's certificate, CA cert and GeoTrust root cert.
Using keytool -list -keystore jetty/etc/keystore -storetype pkcs12 shows it has these certs -
Keystore type: PKCS12
Keystore provider: SunJSSE
Your keystore contains 4 entries
jetty, Aug 29, 2015, PrivateKeyEntry,
Certificate fingerprint (SHA1): A3:...:10
root, Aug 30, 2015, trustedCertEntry,
Certificate fingerprint (SHA1): DE:28:F4:A4:FF:E5:B9:2F:A3:C5:03:D1:A3:49:A7:F9:96:2A:82:12
ca, Aug 30, 2015, trustedCertEntry,
Certificate fingerprint (SHA1): 0E:34:14:18:46:E7:42:3D:37:F2:0D:C0:AB:06:C9:BB:D8:43:DC:24
server, Aug 30, 2015, trustedCertEntry,
Certificate fingerprint (SHA1): 20:...:E3
When server loads, log shows it loads the certificates -
2015-08-30 05:32:47 main ServerConnector [INFO] Started ServerConnector#34849eef{HTTP/1.1,[http/1.1, h2c, h2c-17, h2c-16, h2c-15, h2c-14]}{0.0.0.0:8080}
2015-08-30 05:32:47 main SslContextFactory [DEBUG] Certificate cn alias=jetty cn=example.com in SslContextFactory#7af707e0(file:///usr/share/jetty/jetty-distribution-9.3.1.v20150714/etc/keystore,file:///usr/share/jetty/jetty-distribution-9.3.1.v20150714/etc/keystore)
2015-08-30 05:32:47 main SslContextFactory [DEBUG] Certificate cn alias=root cn=GeoTrust Global CA in SslContextFactory#7af707e0(file:///usr/share/jetty/jetty-distribution-9.3.1.v20150714/etc/keystore,file:///usr/share/jetty/jetty-distribution-9.3.1.v20150714/etc/keystore)
2015-08-30 05:32:47 main SslContextFactory [DEBUG] Certificate SAN alias=server cn=example.com in SslContextFactory#7af707e0(file:///usr/share/jetty/jetty-distribution-9.3.1.v20150714/etc/keystore,file:///usr/share/jetty/jetty-distribution-9.3.1.v20150714/etc/keystore)
2015-08-30 05:32:47 main SslContextFactory [INFO] x509={example.com=server} wild={} alias=null for SslContextFactory#7af707e0(file:///usr/share/jetty/jetty-distribution-9.3.1.v20150714/etc/keystore,file:///usr/share/jetty/jetty-distribution-9.3.1.v20150714/etc/keystore)
2015-08-30 05:32:47 main SslContextFactory [DEBUG] managers=[sun.security.ssl.SunX509KeyManagerImpl#36c54a56] for SslContextFactory#7af707e0(file:///usr/share/jetty/jetty-distribution-9.3.1.v20150714/etc/keystore,file:///usr/share/jetty/jetty-distribution-9.3.1.v20150714/etc/keystore)
But when trying to connect the server using HTTPS, it fails due to bad (self signed) certificate.
Inspecting the returned certificate with openssl s_client -connect example.com:443 returns -
CONNECTED(00000003)
depth=0 C = ..., CN = example.com
verify error:num=18:self signed certificate
verify return:1
depth=0 C = ..., CN = example.com
verify return:1
---
Certificate chain
0 s:/C=.../CN=example.com
i:/C=.../CN=example.com
---
This shows only 1, self-signed certificate, instead of the ones in the keystore. When trying to send an HTTPS command to the server, it shows in logs -
2015-08-30 06:06:52 qtp1579572132-17 SslContextFactory [DEBUG] Customize 1d4638d[SSLEngine[hostname=12.13.14.15 port=25453] SSL_NULL_WITH_NULL_NULL]
2015-08-30 06:06:52 qtp1579572132-17 SslContextFactory [DEBUG] Enable SNI matching 1d4638d[SSLEngine[hostname=12.13.14.15 port=25453] SSL_NULL_WITH_NULL_NULL]
2015-08-30 06:06:52 qtp1579572132-20 SslContextFactory [DEBUG] matches=type=host_name (0), value=example.com for org.eclipse.jetty.util.ssl.SslContextFactory$AliasSNIMatcher#22497dda
2015-08-30 06:06:52 qtp1579572132-20 SslContextFactory [DEBUG] matched example.com->server
2015-08-30 06:06:52 qtp1579572132-16 HttpParser [WARN] parse exception: java.lang.IllegalStateException: too much data seeking EOF in CLOSE for HttpChannelOverHttp#37b97125{r=1,c=false,a=IDLE,uri=-}
I've made sure it's connecting to the correct server by shutting it down, then got a CONNECTION REFUSED, also tried to remove the keystore file and server failed to load, meaning it was using the correct file.
Where does this self signed, 1-long certificate chain come from? Is it possible the server has two keystores defined?
Update
Replacing the keystore with a different (working) one was shown correctly using openssl s_client, with all 3 certs.
This means that problem lies in the original keystore, as shown above it has 3 public certs, but openssl outputs only 1, self-signed cert.
Here are the commands used to produce the keystore -
keytool -genkeypair -storetype pkcs12 -keyalg RSA -keysize 2048 -keystore keystore.p12 -alias jetty
keytool -certreq -alias jetty -keystore keystore.p12 -storetype pkcs12 -file jetty.csr -keyalg RSA
# send CSR file to a CA for signing. got back 3 CRT files.
keytool -import -alias root -keystore keystore.p12 -storetype pkcs12 -trustcacerts -file root.crt
keytool -import -alias ca -keystore keystore.p12 -storetype pkcs12 -trustcacerts -file ca.crt
keytool -import -alias server -keystore keystore.p12 -storetype pkcs12 -trustcacerts -file server.crt
Keystore was built incorrectly.
The last entry added to the keystore had the alias server instead of jetty, which is the alias of the private key. Doing this prevented from recognising the certificate reply to the private key.
To fix this, I've removed all certificates from the keystore and added them with the correct aliases.
keytool -import -alias root -keystore keystore.p12 -storetype pkcs12 -trustcacerts -file root.crt
keytool -import -alias inter -keystore keystore.p12 -storetype pkcs12 -trustcacerts -file ca.crt
keytool -import -alias jetty -keystore keystore.p12 -storetype pkcs12 -trustcacerts -file server.crt
after the last command, keytool will respond with Certificate reply was installed in keystore, indicates it recognises the server certificate response.
I'm not sure if it has an affect, but instead of calling the CA's intermediate certificate ca, I called it inter in the working keystore, I don't think it's required but this worth mentioning in case it does.
Really weird behaviour on a particular p12 file.
If I run
keytool -list -storetype pkcs12 -keystore my_debug_keystore.p12 -storepass debug
keytool -v -list -storetype pkcs12 -keystore my_debug_keystore.p12 -storepass debug
I get,
Alias name: 1
Creation date: Aug 17, 2014
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=sixminute, OU=, O=, C=IE
Issuer: CN=sixminute, OU=, O=, C=IE
Serial number: xxxxxxxxxxxxxxxxx
Valid from: Wed Nov 07 13:34:40 GMT 2012 until: Sun Nov 08 13:34:40 GMT 2037
Certificate fingerprints:
MD5: xxxxxxxxxxxxxxxxx
SHA1: xxxxxxxxxxxxxxxxx
Signature algorithm name: SHA1withRSA
Version: 3
and
Your keystore contains 1 entry
1, Aug 17, 2014, PrivateKeyEntry,
Certificate fingerprint (MD5): xxxxxxxxxxxxxxxxx
However, if I don't provide the password in the commands,
keytool -list -storetype pkcs12 -keystore my_debug_keystore.p12
keytool -v -list -storetype pkcs12 -keystore my_debug_keystore.p12
the output is different,
Alias name: 2
Creation date: Aug 17, 2014
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=sixminute, OU=, O=, C=IE
Issuer: CN=sixminute, OU=, O=, C=IE
Serial number: 2d36623161363935353a31336165303361636133313a2d38303030
Valid from: Wed Nov 07 13:34:40 GMT 2012 until: Sun Nov 08 13:34:40 GMT 2037
Certificate fingerprints:
MD5: xxxxxxxxxxxxxxxxx
SHA1: xxxxxxxxxxxxxxxxx
Signature algorithm name: SHA1withRSA
Version: 3
and
Your keystore contains 1 entry
2, Aug 17, 2014, PrivateKeyEntry,
Certificate fingerprint (MD5): xxxxxxxxxxxxxxxxx
Specifically a different alias for the same key (the MD5 and SHA1 are still the same for the keys).
Any idea at all why this would be the case?
Aliases are not quite a PKCS 12 concept. There is a Friendly Name attribute but it is very optional. So I would guess that Java is just making up the Alias names it reports. No idea why it would be different though, as the safe bag order should be the same.
For example - let's take jks which contains Comodo CA root cert, few intermediate certs and own server signed cert:
# keytool -list -keystore akira.jks
Enter keystore password:
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 5 entries
comodoutnsgcca, Jan 16, 2014, trustedCertEntry,
Certificate fingerprint (MD5): C7:1E:D8:79:91:4C:01:AC:ED:ED:00:30:4C:47:F0:E4
akira, Jan 16, 2014, PrivateKeyEntry,
Certificate fingerprint (MD5): A6:90:2D:8A:0E:4B:A3:0A:B5:50:9A:E3:F9:B8:E5:AC
essentialsslca_2, Jan 16, 2014, trustedCertEntry,
Certificate fingerprint (MD5): B5:1A:6D:2D:44:CC:72:D6:C6:2A:1B:97:5A:18:3D:91
utnaddtrust, Jan 16, 2014, trustedCertEntry,
Certificate fingerprint (MD5): 55:07:0F:1F:9A:E5:EA:21:61:F3:72:2B:8B:41:7F:27
addtrustexternalcaroot, Jan 16, 2014, trustedCertEntry,
Certificate fingerprint (MD5): 1D:35:54:04:85:78:B0:3F:42:42:4D:BF:20:73:0A:3F
How can I see exactly viewing cert's entry - that it require other cert in chain?
If I run -list with -v option - I see a lot of info like "Extensions", "#1: ObjectId" and so on.
So - which one line there describes the dependencies?
So, here is an answer:
# openssl s_client -connect localhost:8443
CONNECTED(00000003)
depth=4 /C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
0 s:/OU=Domain Control Validated/OU=Hosted by LeaderTelecom Ltd./OU=Free SSL/CN=akira.setevoy.kiev.ua
i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=EssentialSSL CA
1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=EssentialSSL CA
i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO Certification Authority
2 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO Certification Authority
i:/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/OU=http://www.usertrust.com/CN=UTN - DATACorp SGC
3 s:/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/OU=http://www.usertrust.com/CN=UTN - DATACorp SGC
i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
4 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
Here is full chain - from local signed cert (CN=akira.setevoy.kiev.ua) till root CA - (CN=AddTrust External CA Root).
s here is "subject" - "name" of cert and i is issuer - who issued this cert.
So Root have name AddTrust External CA Root and it's issued by AddTrust External CA Root.
Other way - use online tools like SSL Checker.