Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
I'm using this command:
openssl s_client -connect example.com:443 -CAfile /etc/ssl/certs/GTE_CyberTrust_Global_Root.pem
It works. If I don't specify that CAfile I get a code 20. The cert is in /etc/ssl/certs and /usr/lib/ssl/certs -> /etc/ssl/certs It's also included in the ca-certificates.crt
What's governing whether openssl can find my cert or not and how can I get it to accept this cert without explicitly specifying it?
There is a known OpenSSL bug where s_client doesn't check the default certificate store when you don't pass the -CApath or -CAfile argument. OpenSSL on Ubuntu 14.04 suffers from this bug as I'll demonstrate:
Version:
ubuntu@puppetmaster:/etc/ssl$ openssl version
OpenSSL 1.0.1f 6 Jan 2014
Fails to use the default store when I don't pass the `-ca:
ubuntu@puppetmaster:/etc/ssl$ openssl s_client -quiet -connect gmail.com:443
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify error:num=20:unable to get local issuer certificate
verify return:0
Now I pass null as the -CApath and it works:
ubuntu@puppetmaster:/etc/ssl$ openssl s_client -quiet -connect gmail.com:443 -CApath /dev/null
depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority
verify return:1
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = mail.google.com
verify return:1
Unfortunately I don't think a list of affected OpenSSL versions exists. Only way to know is to test it.
/usr/local/ssl which had a certs directory not mapped to /etc/ssl/certs.
Nov 10 '16 at 19:59
"How to get openssl to use a cert without specifying it via -CAfile".
I had the same requirement. I wanted to use a directory of CAs that I "trusted" locally. I did not want any default Trust store polluting results.
c_rehash
Before calling the verify command, the help page: man verify guided me to use c_rehash:
rehash scans directories and calculates a hash value of each ".pem", ".crt", ".cer", or ".crl" file in the specified directory list and creates symbolic links for each file
export CERTS=/Users/{path_to_your_certs}
[path to openssl]/openssl/bin/c_rehash ${CERTS}
Verify a leaf cert
openssl verify -CApath ${CERTS} local_leaf.pem
local_leaf.pem: OK
You load the Root CA and IntCA inside of directory CERTS. If I didn't do the rehash step it would give me error 20 unable to get local issuer certificate.
GTE_CyberTrust_Global_Root.peman intermediate CA? If so, it may be that your webserver is failing to serve that intermediate CA cert along with your site cert. This shortcoming on the part of your webserver could cause compatibility issues with some computers. On the other hand, if theGTE_CyberTrust_Global_Root.pemis a top-level root certificate then it should be working by default.opensslis not configured with any top-level root certs? Have you triedgoogle.com:443?