google certificates correct CA

Question

I view certificates of https://www.google.com.ua/

So I thought, when requesting via cURL, if I point by CURLOPT_CAINFO to those certificates (GeoTrust Global CA and Google Internet Authority G2 in a bundle or whatever), the validation of google's certificate would be passed. But the only CA that does it is the Equifax Secure CA (discovered it by plain enumeration of git's CA bundle). Could someone explain why is it so? Thanks a lot.

UPD: it's not only google's behaviour, another site behaves that way too, so I suppose either I misinterpret something (which is likely) or some wrong information is being shown (again, why is this happening)

Answer 1

This is most likely an obsolete "bridge" now leading to the wrong place.

There are two valid trust chains for this cert. There is a root cert for GeoTrust Global CA, valid from 2002, which is in current Windows/IE and Firefox stores (and Java); and also a "cross-signed" cert for that CA under Equifax Global CA as follows:

Data:
    Version: 3 (0x2)
    Serial Number: 1227750 (0x12bbe6)
Signature Algorithm: sha1WithRSAEncryption
    Issuer: C=US, O=Equifax, OU=Equifax Secure Certificate Authority
    Validity
        Not Before: May 21 04:00:00 2002 GMT
        Not After : Aug 21 04:00:00 2018 GMT
    Subject: C=US, O=GeoTrust Inc., CN=GeoTrust Global CA
    Subject Public Key Info: <snipped: same as root>
   X509v3 extensions:
        X509v3 Authority Key Identifier:
            keyid:48:E6:68:F9:2B:D2:B2:95:D7:47:D8:23:20:10:4F:33:98:90:9F:D4
        X509v3 Subject Key Identifier:
            C0:7A:98:68:8D:89:FB:AB:05:64:0C:11:7D:AA:7D:65:B8:CA:CC:4E
        X509v3 Basic Constraints: critical
            CA:TRUE
        X509v3 Key Usage: critical
            Certificate Sign, CRL Sign
        X509v3 CRL Distribution Points:
            Full Name:
              URI:http://crl.geotrust.com/crls/secureca.crl
        X509v3 Certificate Policies:
            Policy: X509v3 Any Policy
              CPS: https://www.geotrust.com/resources/repository
<snip signature>

This is apparently a "bridge" cert, often used when a renamed (here) or new CA root is created and wants to temporarily leverage the existing trust of an older CA root; the Equifax root is valid from 1998 so in say 1999 and 2000 there were lots of clients that would know the Equifax root and not the GeoTrust root. 12 years later it should be obsolete.

Running 'openssl s_client' confirms www.google.com.ua is providing in the SSL handshake its own cert, the Google Internet Authority G2 intermediate cert, and the bridge cert. IE, FF, and Java are all smart enough to ignore the bridge and use the GeoTrust root which they have internally stored. OpenSSL, which curl uses, is not, or at least not yet; thus you must tell curl to give OpenSSL the Equifax root. (The OpenSSL 1.0.2 release, currently in beta, is announced to have enhancements in the area of cert chain validation, which I haven't looked at in detail yet.)

EDIT 3/13: I can't comment on my answer(!) so adding here. As I said, there are TWO certs for GeoTrust Global CA: one root, and one "bridge".

IE/Windows and FF DO have the GeoTrust root; you already saw it in Certification Path in IE or FF with the webpage open, or you can look directly in the truststores with InternetOptions/Content/Certificates/TrustedRoots and Tools/Options/Advanced/Certificates/Authorities. Both also have the Equifax root, but don't use it here. Both IE and FF display the certification path used even though it differs from what the server sent; that may be "wrong" in one way of looking but "right" in another.

A root cert is always self-signed; that's necessary to be a root (not always for an anchor, but leave that aside). The GeoTrust root cert is a root. The GeoTrust bridge cert is not a root, it links to the Equifax root cert which is a root. And, again, the Equifax root is the one curl + openssl needs.

EDIT 9/01: https://knowledge.geotrust.com/support/knowledge-base/index?page=content&id=AR1426&actp=search&viewlocale=en_US&searchid=1283360269668 confirms this is a bridge cert back to Equifax.

UPDATE 2017/03/28: first, OpenSSL 1.0.2 did add -trusted_first which uses the GeoTrust root if present and ignores the bridge cert. Second, this is now more important because the Equifax root has been removed from the Mozilla/NSS truststore, and thus the curl-project CAfile used by many clients, see https://serverfault.com/a/841071/216633 .