1

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)
3

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.

  • Thanks. I think that answers my question. I'm confused though: if the browser certificate view isn't necessarily showing me 100% accurate information about the cert chain it received during the actual connection, what's the point of it? How can I know if certificate issues/errors are a result of missing/incorrect local store information... or a server side issue? – Mike B Jul 25 '15 at 20:21
  • @MikeB: for the user it is only relevant if the certificate for the server can be trusted. It does not matter for the user if the browser/OS fills in missing chain certificates by itself as long as a trusted path to a local root CA can be built. If you need more technical information to debug a problem then you need to use the more technical tools. – Steffen Ullrich Jul 25 '15 at 20:35
  • So I take that to mean that alerts highlighting serious flaws in the trust are based off of the actual cert chain in the TLS session and aren't susceptible to false positives based on the user's local trust store? – Mike B Jul 25 '15 at 21:02
  • @MikeB: I don't know which kind of problems you mean. Either the certificate was signed by a CA trusted by the browser/OS or its sub-CA or not. If it was signed it does not matter if the trust path gets built with intermediate certificates sent by the server or with local certificates. And if was not signed directly or indirectly by something trusted by the browser it does not matter what the server sends - it will stay untrusted. Of course the user can explicitly add new CA or remove the trust to existing CA, but these are explicit decisions by the user or company. – Steffen Ullrich Jul 25 '15 at 21:35
0

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.

  • Thank you for the detailed response however my question wasn't regarding how TLS works. I want to understand why the certification path section of the crypto shell extension view can-be/is specifically different (and why). – Mike B Jul 25 '15 at 20:18

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.