I’ve been working on a quick training at my work on handling certificates in the enterprise. While I was writing a section on the SSL Chain I started wondering about intermediate certificates and where they were stored. Now, I know a lot of people probably already know the answer to this question and will probably find this post a bit funny, but I thought it would be something great to post for those who haven’t quite understood how this works.

So first with some basics. If you don’t already know, certificates are used to secure information. Their uses usually fall into 4 categories.

  • Authentication – Can be used as a credential to identify the identity of a sender or receiver.
  • Privacy – Think TLS. Secures communication between endpoints.
  • Encryption – Hide information written to disk that can only be de-crypted using a key (EFS for example)
  • Digital Signatures – Confirms identity of the entity who created a file and includes evidence that the data in a file has not been altered.

For the rest of this post, I’m primarily going to be framing the conversation around the privacy category (TLS), but could technically refer to all 4.

It’s also worth pointing out that certificates follow chains of trust to verify the identity of those certificates.

Image from msdn.microsoft.com


So, from looking at the trust tree up above, we can see that in order to trust a tier 2 cert, we need to trust the intermediate certificate authority (tier 1) and the root certificate authority (Root CA). All pretty basic stuff.

Windows gets the root certificate authorities from windows updates and keeps them in the Trusted Root Certificate Authority store. These are pretty easy to see by opening an MMC, adding the certificate (local computer) snap-in, and opening the Trusted Root Certification Authorities Store.


But if we open the Intermediate Certification Authorities store, we’ll find that there’s really not that much there.


So what the heck is going on here? There’s likely thousands of intermediate certificate authorities out there delivering certs for all the major GoDaddies and Verisigns of the world. Why am I trusting an intermediate when I look at the certificate chain for a website in my browser?

What? I work in IT and sit all day. Don’t judge me 🙂

At this point I figured, maybe I could find the certificate using the thumbprint and searching through my entire certificate store. So, off to Power Shell we go!

CD Certs:
Get-ChildItem -Recurse | where {$_.Thumbprint -eq "d6ad07c6675630f57b927f66be8ce1f768f87948"}
But I get nothing….

It was at this point that it hit me. I was such a FOOL! The intermediate cert must be getting delivered during the initial TLS handshake! But, I wanted to be sure, so off we go to Wireshark! I basically took a capture of opening an https webpage in a browser and followed the TCP stream. Then took a look at the packets after the TCP Server Hello and expanded the SSL Section of the packet.

There you are!!

So, there you go. Intermediate Certs are delivered with the public key in the initial TLS handshake. This was just something fun I just learned and thought I would share it here on the blog!