What exactly is IE / Chrome checking when I view the "certification path" tab on cert connection details?

Question

When I bring up certificate details for a web page in IE or Chrome, I have the option to view the certificate hierarchy (under a tab called "Certification Path"). Here's an example for security.stackexchange.com:

I originally thought that this was a summary of the exact certificate chain provided by the server during the TLS connection + root cert on my end. I recently observed though that the certification path section will display different things if I change my own locally stored intermediates (even though I haven't changed anything on the server side).

So my questions are:

• What exactly is this checking? Where is Windows (or more specifically, the Crypto Shell Extension application) populating the information on this tab from?
• How can I see exactly what the browser got in terms of the actual certificate chain (assuming that the server in question is not publicly accessible)

Answer 1

What exactly is this checking? Where is Windows (or more specifically, the Crypto Shell Extension application) populating the information on this tab from?

It is showing the trust path it constructed based on the certificates sent in the SSL handshake (ignoring any root certificates sent by the server), the cached intermediate certificates from other connections, the built-in root certificates and any other certificates it has in the store. Some browsers also download missing certificates and these will be displayed too.

How can I see exactly what the browser got in terms of the actual certificate chain (assuming that the server in question is not publicly accessible)

You will not get this information from the browser. You might use tools like openssl to display the certificates the tool gets:

openssl s_client -showcerts -servername host -connect host:port

These are in most cases the same certificates the browser sees, but a server might actually decide to return different certificates based on parameters of the SSL handshake initiated by the client. This is specifically relevant for the SNI extension so you must include the -servername option with s_client.

But to get a definite knowledge of what the browser sees you need to do a packet capture using tools like tcpdump or wireshark. When viewing the capture with wireshark you then can see the certificates sent by the server. To make sure that you don't get a session resumption where you don't see any certificates make sure you restart the browser before visiting the relevant site.

Answer 2

When you connect to a site via SSL, the server serves the certificate for that site during the SSL session. In the issuer field of this certificate, the subject of the certificate that was used to sign the site's certificate (i.e. the next certificate up in the chain) is specified. That certificate may have been signed by another certificate, and so on and so forth, until finally a root certificate is reached that is trusted by the client (e.g. a CA cert). For each certificate, the issuer field points to the subject of the next certificate up in the chain.

So, how does the client (e.g the web browser) access all of these certificates in the chain? There are a number of ways this can be done. In many cases, the server serves all of the certificates in the chain. This is often done by including all of the certificates in a .pem file. In other cases, the client may already have some (or all) of the certificates in its cache. In other cases, The Authority Information Access field of a certificate in the chain may be used to specify an HTTP location where the certificate that was used to sign this certificate (i.e. the next certificate up in the chain) may be accessed.

For example, for the certificate for *.stackexchange.com that you included a screenshot of in your post, if you look at the issuer field, you will see 'GlobalSign Organization Validation CA - SHA256 - G2'. This is the subject of the certificate that was used to sign the certificate for *.stackexchange.com. Now, if you look at the Authority Information Access field of the certificate for *.stackexchange.com, you will see the URL http://secure.globalsign.com/cacert/gsorganizationvalsha2g2r1.crt. The certificate for 'GlobalSign Organization Validation CA - SHA256 - G2' can be found at this URL. However, your web browser probably would not have to download any of the certificates in the chain from the URLs provided in the Authority Information Access fields, because Stack Exchange's web servers serve all of the certificates in the chain during the SSL session.