0

With OpenSSL 1.0.2g (MacPorts on OS X) I can check Google's certificate (I have to specify the certificate bundle as OS X usually stores it in the KeyChain)

$ echo Q |  /opt/local/bin/openssl s_client   -connect www.google.com:443 -servername www.google.com -verify 6 -CAfile test/cabundle.crt > /dev/null 
verify depth is 6
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 = www.google.com
verify return:1
DONE

Everything OK. Now if I use the system's version (0.9.8zg) with the very same CA bundle I get an error:

$ echo Q |  /usr/bin/openssl s_client   -connect www.google.com:443 -servername www.google.com -verify 6 -CAfile test/cabundle.crt > /dev/null 
verify depth is 6
depth=2 /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=2 /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
verify error:num=27:certificate not trusted
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=www.google.com
verify return:1
DONE

I don't get where the problem could be since I am specifying the CA bundle manually.

1
  • 1
    If you don't specify -CAfile the results are exactly the same... – techraf Mar 21 '16 at 12:19
0

From https://trac.macports.org/ticket/47805

The problem is that Apple removed a 1024-bit root in Yosemite, that was used as a trust anchor for Google's (and possible other sites) certificates. Normally, this would not affect certificate validity, because one of the intermediate certificates in its chain is not a trusted root CA in OS X (in the case of Google, it's GeoTrust Global CA).

However, OpenSSL before 1.0.2 does not detect this situation as it should (by checking whether any of the intermediates is a trusted root CA) and always follows the chain of trust to the end. In this situation, it fails to verify the certificate, because the end of the chain of certificates is actually not trusted. OpenSSL 1.0.2 added a switch to fix that (activated by -trusted_first in openssl s_client), but this option needs to be enabled by each software separately.

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.