How to determine effective trust chain for cert on MacOS X?

Question

I'm seeing some curious issues with cert verification for an Issuer: Entrust - L1K cert that was issued and is in use (per inspection of the cert in Chrome and Firefox) for an internal site here.

• I don't see any Subject: Entrust - L1K cert in any of my local keychains, yet browsers connect happily, at least from inside the enterprise.

• I first noticed something amiss with some python scripts, then determined that openssl wouldn't verify the site cert. It also has no representation in the python certifi cert bundle, which is supposedly kept up to date.

• (There's also one verified case of an individual able to connect without issue inside the corporate network but seeing a "can't verify" warning about this Entrust - L1K cert when connecting over VPN, same system, no reboot or anything)

After downloading a cert for Entrust - L1K directly from Entrust with Issuer: Entrust - G2, I can construct a valid trust chain rooted at an Entrust Root CA:

Entrust Root Certification Authority - G2  (this is present in my keychain)
--> Entrust Certification Authority - L1K  (this is the newly downloaded cert)
    --> Local site                         (this is the cert the browser was presented)

Note that I'm doing this with openssl and with cert files manipulated in a working directory. Only the Entrust Root cert noted is present in my keychain.

I have several questions on my mind.

1. (The main one) How can I see the trust chain that leads to my browser not complaining when I connect to the local site, given that I can't find certs in any of my keychains that can build one?

2. Is L1K a new sub-authority under Entrust? The Subject: Entrust - L1K cert has Validity Not Before: Oct 5 19:13:56 2015 GMT. How should a new cert like this normally make its way to end systems?

3. Is there something other than some local cert chain that the client browsers could be using for cert verification, that would explain the happy connections? And what might explain the cert verification failure over VPN?

The text form of the L1K cert obtained manually from Entrust follows. As mentioned, this cert does complete the trust chain between the site cert and the root cert for Entrust Root Certification Authority - G2:

$ openssl x509 -in ../entrust_l1k.pem  -text | more
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            0e:e9:4c:c3:00:00:00:00:51:d3:77:85
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, O=Entrust, Inc., OU=See www.entrust.net/legal-terms, OU=(c) 2009 Entrust, Inc. - for authorized use only, CN=Entrust Root Certification Authority - G2
        Validity
            Not Before: Oct  5 19:13:56 2015 GMT
            Not After : Dec  5 19:43:56 2030 GMT
        Subject: C=US, O=Entrust, Inc., OU=See www.entrust.net/legal-terms, OU=(c) 2012 Entrust, Inc. - for authorized use only, CN=Entrust Certification Authority - L1K
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (2048 bit)
                Modulus (2048 bit):
                    00:da:3f:96:d0:4d:b9:2f:44:e7:db:39:5e:9b:50:
                                    :
                                (elided)
                                    :
                    35:fe:53:19:2f:08:46:c1:2a:b3:1a:62:1d:4e:2b:
                    d9:1b
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE, pathlen:0
            Authority Information Access: 
                OCSP - URI:http://ocsp.entrust.net

            X509v3 CRL Distribution Points: 
                URI:http://crl.entrust.net/g2ca.crl

            X509v3 Certificate Policies: 
                Policy: X509v3 Any Policy
                  CPS: http://www.entrust.net/rpa

            X509v3 Subject Key Identifier: 
                82:A2:70:74:DD:BC:53:3F:CF:7B:D4:F7:CD:7F:A7:60:C6:0A:4C:BF
            X509v3 Authority Key Identifier: 
                keyid:6A:72:26:7A:D0:1E:EF:7D:E7:3B:69:51:D4:6C:8D:9F:90:12:66:AB

Answer 1

Resolved. The site needed to add the intermediate cert to the PEM file. I was overlooking the trust chain view in the browser that showed it was fetching the intermediate cert, a step that wasn't performed in the other use cases.

So to answer my questions:

1. The effective trust chain was in fact visible by calling up the security details by clicking the lock icon in the browser's address bar and viewing certificate information.

2. Not sure about the history of Entrust - L1K, but that's a small detail here. The "how does the cert get to end systems" question is superceded by the answer to part 3 below.

3. The intermediate cert should be provided in the cert bundle the site server presents to the client browser. As it was not, my openssl and python connections were failing, but the browsers used the "Certificate Authority Information Access" certificate extension to retrieve it automatically, at least in some contexts.