How to get openssl to use a cert without specifying it via -CAfile

  • 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?

    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.

    @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").

    That's strange. I would have expected it to work once included in /etc/ssl/certs and ca-certificates.crt

    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`?

    Same behavior for google.com

  • 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:

    [email protected]:/etc/ssl$ openssl version
    OpenSSL 1.0.1f 6 Jan 2014
    

    Fails to use the default store when I don't pass the `-ca:

    [email protected]:/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:

    [email protected]:/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.

    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: https://github.com/openssl/openssl/issues Can you reference the issue?

    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. https://rt.openssl.org/Ticket/Display.html?id=3697

    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`.

    I can verify the bug exists in CentOS 6.8 (OpenSSL 1.0.1e-fips 11 Feb 2013).

    Also `openssl version -d` gives you the base config directory ...

    It's fixed on the real 1.1 development branch as well. https://github.com/openssl/openssl

License under CC-BY-SA with attribution


Content dated before 7/24/2021 11:53 AM