I have a keystore, which contains only 1 keypair (foo). From that keypair, I generated a csr, which was signed by a CA using the certificate bar (bar is the issuer of foo). The issue I have is that I'm unable to import back the certificate foo in my keystore with this command
keytool -importcert -alias foo -file foo.p7b keypass 123456 -keystore keystore.jks -storepass 123456
It failed with the error
Failed to establish chain from reply.
If add the public certificate bar in my keystore, then it is working fine.
Therefore, one will simply think that I absolutely need to insert the public certificate bar in my keystore, but what is bugging me here is that if I use KeyStore Explorer to import the certificate foo in my keystore (which is only containing the keypair foo), then it is working fine. In other word, I able to import the certificate with KeyStore Explorer ("Import CA reply"), but not keytool.
Is anyone have an idea what I'm doing wrong ?
Related
I received a new keystore .jks file for ssl connection to replace an old, but working, .jks keystore file, but I got "unexpected handshake message: serve_hello" error. I was told to make sure the keystore contains a client cert, so I used keytool to export its cert to a pem file, then use openssl to check the purpose. The result shows
Certificate purposes:
SSL client : No
SSL client CA : No
SSL server : Yes
SSL server CA : No
...
However when I applied the same process to check the old but working jks file I got the same result. Wonder if this is the right way to verify the certificate? And how to troubleshooting this handshake error with the new jks file?
Thanks!
The extended key usage extension contains OIDs which define the purpose:
id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 }
-- TLS WWW server authentication
-- Key usage bits that may be consistent: digitalSignature,
-- keyEncipherment or keyAgreement
id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 }
-- TLS WWW client authentication
-- Key usage bits that may be consistent: digitalSignature
-- and/or keyAgreement
https://datatracker.ietf.org/doc/html/rfc5280 Page 44
See: https://oidref.com/1.3.6.1.5.5.7.3.1 and https://oidref.com/1.3.6.1.5.5.7.3.2
When opening a certificate on Windows you can see the extension here:
I used this tool in this link to generate a self-signed certificate for a Windows webserver.
The command to generate the cert is like following
New-SelfSignedCertificateEx -Subject "CN=192.168.56.111" -SAN "192.168.56.111" -IsCA $true -EKU "Server Authentication", "Client Authentication" -KeyLength 2048 -KeySpec "Signature" -KeyUsage "DigitalSignature" -FriendlyName "192.168.56.111" -NotAfter $([datetime]::now.AddYears(5)) -StoreLocation "LocalMachine" -Exportable
After installing the certificate with IIS, and add the certificate to the trusted root CA store in a Windows 10 client, I was able to browse the website with no certificate errors.
However when I try to do the same in a ubuntu 18.04 client by installing the cert to the CA certs store and test using cURL, it doesn't work
Install cert to Ubuntu ca-certificates
openssl s_client -connect 192.168.56.111:443 -showcerts > out.txt
#then use vim to edit out.txt and save the cert to 192.168.56.111.crt
sudo cp 192.168.56.111.crt /usr/local/share/ca-certificates
sudo update-ca-certificates
Test the connection using cURL
curl https://192.168.56.111
And got the error message
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
When adding the cert to the Chrome Certifiates store, Chrome shows NET::ERR_CERT_INVALID
So my question is, why does it work in Windows client but not in Ubuntu 18.04? I can't see any error indicating what's wrong with the certificate in Ubuntu so I'm stuck at the moment.
Your openssl command is not correct:
jonathan.muller#jonathan-muller-C02ZC4EPLVDQ$ openssl s_client -connect drylm.org:443 -showcerts
CONNECTED(00000005)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = blog.drylm.org
verify return:1
---
Certificate chain
0 s:/CN=blog.drylm.org
i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
-----BEGIN CERTIFICATE-----
MIIFUzCCBDugAwIBAgISA0xYp5ZHU+NGF1EW/RcUuV0fMA0GCSqGSIb3DQEBCwUA
...
you have a lot of noise in the output.
Here is how to extract the certificate:
echo | openssl s_client -connect 192.168.56.111:443 2>/dev/null | openssl x509 > 192.168.56.111.pem
and you can copy this pem file to the truststore.
Edit:
I just made the exercise by creating a self sign certificate on this website
in my shell:
john#kona$ curl https://test.drylm.org
curl: (60) SSL certificate problem: self signed certificate
More details here: https://curl.haxx.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
then
john#kona$ echo | openssl s_client -connect test.drylm.org:443 2>/dev/null | openssl x509 > test.drylm.org.crt
sudo cp test.drylm.org.crt /usr/local/share/ca-certificates/
john#kona$ sudo update-ca-certificates
Updating certificates in /etc/ssl/certs...
1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
Adding debian:test.drylm.org.pem
done.
done.
and finally:
john#kona$ curl https://test.drylm.org
Path : ~
No more error message with curl.
I'm trying to set up an ssl connection to a mongodb instance I have running in a container on my machine and keep running into,
nioEventLoopGroup-2-4, fatal error: 46: General SSLEngine problem
sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
I created a self signed .pem for mongo with,
openssl req -x509 -newkey rsa:4096 -keyout mongo.key -out mongo.crt -days 365 -nodes
cat mongo.key mongo.cert > mongo.pem
Moved those into a folder, mounted it as a bind volume in my container and added
--sslMode requireSSL --sslPEMKeyFile /etc/boundfolder/mongo.pem
to the mongo startup. I can connect to this with the mongo client.
I am setting up my mongo client in scala like so,
val hostConf = ClusterSettings.builder().hosts(List(new ServerAddress(hostName)).asJava).build()
val clientSettings = MongoClientSettings.builder()
.streamFactoryFactory(NettyStreamFactoryFactory())
.clusterSettings(hostConf)
val withTLS = clientSettings.sslSettings(
SslSettings.builder()
.enabled(true)
.invalidHostNameAllowed(true)
.build())
MongoClient(withTLS.build())
Lastly, I created a keystore with,
keytool -importcert -trustcacerts -file mongo.crt -keystore mongo.keystore
and am starting the application with the following parameters,
-Djavax.net.ssl.keyStore=/path/to/mongo.keystore -Djavax.net.ssl.keyStorePassword=changeit -Djavax.net.debug=SSL
I'm pretty sure the issue is either what, or how, I'm adding the self signed cert to the keystore. Thanks for any help you can give.
I am new to SSL certification generation, I have generated the SSL certification of type BKS. but during the Jboss starting i am getting the exception: -saying "java.security.KeyStoreException: BKS not found". The below are the steps i am doing to create the keystore file.
keytool -genkey -alias abcd -keystore C:/abcd.keystore -storepass abcd -storetype BKS -provider org.bouncycastle.jce.provider.BouncyCastleProvider -providerpath c:/bcpkix-jdk15on-147.jar
I am using JBoss 4.2.3 GA.
Please help me out to resolve this issue.
Thank You,
Pruthvi
Error "BKS not found" would mean that its looking for an alias named BKS. Can you pass on the actual error and also the details of the ssl connector definition (server.xml) ?
Make sure you follow these steps
http://docs.jboss.org/jbossweb/3.0.x/ssl-howto.html
You can try to add the provider into the java.security file as described in Different types of keystore in Java -- BKS
security.provider.N=org.bouncycastle.jce.provider.BouncyCastleProvider
N means the provider index in the provider list.
I've created my own CSR with the following command
openssl req -new -newkey rsa:2048 -nodes -out bgsisson_com.csr -keyout bgsisson_com.key -subj "/C=US/ST=CA/L=Los Angeles/O=Benjamin Sisson/OU=Development/CN=bgsisson.com/emailAddress=myemail#dom.com"
Then I created a CRT with the following command
openssl x509 -req -days 365 -in bgsisson_com.csr -signkey bgsisson_com.key -out bgsisson_com.crt
When I try to upload this cert to https://identity.apple.com/pushcert/ I get a invalid certificate signing request.
Am I creating the certificate wrong? Does the cert need to be verified?
Thanks!
Update - Removed wildcard from CN. I'm still getting an Invalid Cert signing request.
Update - added CSR and CRT. I test uploading both of them, but I think I just need to upload the CSR
Update - added emailAddress to CSR
bgsisson_com.csr
-----BEGIN CERTIFICATE REQUEST----- MIICvDCCAaQCAQAwdzELMAkGA1UEBhMCdXMxCzAJBgNVBAgTAkNBMRQwEgYDVQQH
EwtMb3MgQW5nZWxlczEYMBYGA1UEChMPQmVuamFtaW4gU2lzc29uMRQwEgYDVQQL
EwtEZXZlbG9wbWVudDEVMBMGA1UEAxMMYmdzaXNzb24uY29tMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEAudmpTvmnWLivwLaFNx6w/kgwUbPCr8ujZOtx
1Lu/+alpuHPoQ4Kpyt3rsj9wc/PSWXBFjIV607YCINTJrQfHUJMq55s3aWxeroB9
llqXn0qTJ2GujAmuWBX2nvIZucQVF1xX3/V1179CKM/+z/rE4ehiJdEnMQk6Otrv
HT1W/eIL5rzSjky+ZpaRSguUpyQSsSuD4Cdfo6NMiY5RVvh9N/Q/O+jEpAJxEHOd
nAbJj8WU2WW9MxtUw21UODh5kHX+b8sLfuKB9EJ2XUqwvdJt9MgnrAiYVkvjq1iT
dZFd2nHiKZnLRr2jBZ74u9duqwm9kD8zoOAiMzbFUTjD1AZIHwIDAQABoAAwDQYJ
KoZIhvcNAQEFBQADggEBAK+Zr5pdtcqVUtMD8843wz7h3bAOVIvrJpbr2/g1mUvo
4Pn27Xlw/CZL2aqOniTTCOeGvWAvHtckxaTxPL3Ruid2/QTnOgKecUnqVPAoqaBP
0SPJDo3X1rbWKVTTJOvT67Kywtd8q+Msx46IqE/2YWur+XO47dnKWR4lPJipgjjY
p+zt9TPTAqu+M6xwqsslUy9r68GaQGTdRdQSyZB5XAg+I271mtxrSrImaAPEi1MY
2ch9r4NaFWH9X7CH67Y0QCKsGjKU4Ftz6x8c1cf4n8TuWgD5/S2UeY+zj3JvjVgj
DJlQyKGmYCC6G0FcoWSD7yCvJ+k0DcoJuGUO3094RIg=
-----END CERTIFICATE REQUEST-----
bgsisson_com.crt
-----BEGIN CERTIFICATE----- MIIDajCCAlICCQCMvMl8OXFb3jANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJ1
czELMAkGA1UECBMCQ0ExFDASBgNVBAcTC0xvcyBBbmdlbGVzMRgwFgYDVQQKEw9C
ZW5qYW1pbiBTaXNzb24xFDASBgNVBAsTC0RldmVsb3BtZW50MRUwEwYDVQQDEwxi
Z3Npc3Nvbi5jb20wHhcNMTIwMzIyMTY1MzA1WhcNMTMwMzIyMTY1MzA1WjB3MQsw
CQYDVQQGEwJ1czELMAkGA1UECBMCQ0ExFDASBgNVBAcTC0xvcyBBbmdlbGVzMRgw
FgYDVQQKEw9CZW5qYW1pbiBTaXNzb24xFDASBgNVBAsTC0RldmVsb3BtZW50MRUw
EwYDVQQDEwxiZ3Npc3Nvbi5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQC52alO+adYuK/AtoU3HrD+SDBRs8Kvy6Nk63HUu7/5qWm4c+hDgqnK3euy
P3Bz89JZcEWMhXrTtgIg1MmtB8dQkyrnmzdpbF6ugH2WWpefSpMnYa6MCa5YFfae
8hm5xBUXXFff9XXXv0Ioz/7P+sTh6GIl0ScxCTo62u8dPVb94gvmvNKOTL5mlpFK
C5SnJBKxK4PgJ1+jo0yJjlFW+H039D876MSkAnEQc52cBsmPxZTZZb0zG1TDbVQ4
OHmQdf5vywt+4oH0QnZdSrC90m30yCesCJhWS+OrWJN1kV3aceIpmctGvaMFnvi7
126rCb2QPzOg4CIzNsVROMPUBkgfAgMBAAEwDQYJKoZIhvcNAQEFBQADggEBALa5
1rkRjCAJF1WU2TIM9FA7A7upb8YVKnagthCIn3kLYBqI4wRHO28HPm53IWJP/hUG
80rjczKY03PFjuiikrlPzUdBR99n4jq6UhcFdG4Z948lXoS2WsIJc6vZmA6wBAIE
h+Xe4SjdPvhsKKrVLFEgpSb/67mUdHF2qVkhvkqs8EgJ65fozjW2adyF6NxOWrmG
5Q++Dp/+K1TSkLM/yZieWWbQ042OyYCZ+agIuwpduW5waKbN1+TERKJo0eFlwQUi
w7KsgLpfoyGji4FzznODGxRq/2Ja5VPnnfa4pxG+l0qkn5VoW27qFHJy5E6Z7Bqb
RqpfbiQ6jeLcqCiWgig=
-----END CERTIFICATE-----
You need to sign the certificate request from a vendor with an Enterprise Developer Account. The information is available at http://www.softhinker.com/in-the-news/iosmdmvendorcsrsigning
I suspect that it is tripping over the wildcard in the CN as AppIDs with wildcards are not accepted.