3

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?

Improve this question
6
  • Is GTE_CyberTrust_Global_Root.pem an 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 the GTE_CyberTrust_Global_Root.pem is a top-level root certificate then it should be working by default. – 700 Software Nov 8 '16 at 18:06
  • 1
    @GeorgeBailey Thanks. It is intermediate. No real reason not to share the location: bigfishgames-a.akamaihd.net:443 If I'm asking our web folks to fix this, what would I be asking? Feel free to make your answer an answer (i.e. "Nothing you can do on the client, the server needs to do X"). – Ben Flynn Nov 8 '16 at 18:17
  • That's strange. I would have expected it to work once included in /etc/ssl/certs and ca-certificates.crt – sandyp Nov 8 '16 at 18:19
  • Well it's not obvious yet whether the server is the problem. It looks like the server is serving an Intermediate CA, and that SSLLabs treats CyberTrust as a top-level root. You may be wrong about CyberTrust being an Intermediate, but maybe you are right. I'm not sure. Check the certificate chain/path in your favorite browser and/or on SSLLabs. Perhaps openssl is not configured with any top-level root certs? Have you tried google.com:443? – 700 Software Nov 8 '16 at 18:28
  • Same behavior for google.com – Ben Flynn Nov 8 '16 at 21:52
3

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.

Improve this answer
6
  • Thanks. I was using that version. OpenSSL 1.1.0 does not appear to have fixed the issue. I'm not seeing the issue listed here: github.com/openssl/openssl/issues Can you reference the issue? – Ben Flynn Nov 8 '16 at 21:51
  • It's in the old RT issue tracker. There is a patch there, it's behind a login (guest:guest) It's issue #3697, marked resolved. rt.openssl.org/Ticket/Display.html?id=3697 – Antonius Bloch Nov 9 '16 at 2:33
  • Ok, I confirmed that this is fixed in 1.1, at least in the richsalz fork of it. When I upgraded I initially did not notice the base directory shifted to /usr/local/ssl which had a certs directory not mapped to /etc/ssl/certs. – Ben Flynn Nov 10 '16 at 19:59
  • I can verify the bug exists in CentOS 6.8 (OpenSSL 1.0.1e-fips 11 Feb 2013). – Antonius Bloch Nov 11 '16 at 7:07
  • 1
    Also openssl version -d gives you the base config directory ... – Antonius Bloch Nov 11 '16 at 7:09
0
"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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.