Understanding SSL Certificates

I get a lot of questions on understanding certificates in general, this post is intended to answer those general questions and is not specific to any product.  Although I plan on using Windows Home Server and Windows Small Business Server 2008  as examples here.  I do have a previous post on understanding the self-issued certificate in SBS 2003 and SBS 2008, as this post will focus on understanding trusted certificates, and what makes them trusted.

Certificates provide two purposes:

1. Authenticating the server to the client
2. Providing encryption between the server and the client

I will cover the authenticating the server to the client in this part 1 post, and will write a part 2 post that handles the second part of encryption.

Part 1 – Authenticating the Server to the Client

Think of a certificate like a drivers license; a United States drivers license as that’s what I’m most familiar with.  The drivers license has three key components that makes it what it is. 

1. A name that identifies what you are called, in my case, “Sean Daniel”
2. An expiry date, that identifies when the license is valid from.  This ensures data doesn’t get stale, like your picture, or hair colour, or if you need glasses or not to drive
3. An issuing authority, such as Washington State

This is the same as a computer SSL certificate.  It has a valid URL, an expiry date, and an issuing authority.  When the client gets to the intended URL such as https://remote.contoso.com, it asks the server for proof that it is remote.contoso.com, and the server presents it’s certificate.  The client validates the 3 checks.  Does the URL in the certificate match (ie. are you “Sean Daniel”).  Is this certificate valid (is the expiry date past today’s current date and time).  Those are the two easy to understand checks.  The final check is “do I trust the issuing authority”.  In the case of a drivers license, you’d bend it, look at it under a black light to make sure it’s authentic, and then you’d see Washington state issued it and be.  Sure, I trust the state government.

With certificates, it’s slightly different. The computer follows the certificate chain outlined in the certificate path (IE view):

In the above example for Home Server, the client will check if it trusts foo.homeserver.com.  It looks into it’s trusted certificate store for a matching certificate, none would exist of course, so it would then look for the “GoDaddy Secure Certification Authority” in the same store.  Because the “GoDaddy Secure Certification Authority” trusts foo.homeserver.com, the client can base it’s trust on that.  Again, it won’t find that certificate, so it bounces up to the root certificate and looks for “Go Daddy Class 2 Certification Authority” in the trusted root store:

As you can see from a view on my Windows 7 box, Windows 7 by default trusts this certificate, so since I trust that certificate, and that certificate trusts the “Go Daddy Secure Certification Authority”, then my Windows 7 machine also trusts this authority, and since the “Go Daddy Secure Certification Authority” trusts foo.homeserver.com, then My Windows 7 client also trusts foo.homeserver.com, and a trusted certificate connection is established.

In the non-computer world, think of it this way.  When I try to get on a plane, and I present my drivers license (domestic flights only!), they trust WA state and allow me on the plane.  If I were to present my Microsoft Identification, they would probably look at me sideways and ask for another ID, because the airlines don’t trust the Microsoft employee issuing authority.  However, if I go to my companies Christmas party I can present EITHER my drivers license, or my Microsoft ID, and they trust both, since they trust WA state, and the Microsoft employee issuing authority.

In Windows SBS 2003/2008 and the use of self issued certificates.  You install the leaf cert (sbs 2003) or the root cert (sbs 2008) into your client trusted root store, and now your client will trust that issuing authority as mentioned above.  This is outlined in my old post.

On Mobile devices, such as Windows Mobile, you need to ensure the certificate is in that root store as well, which is why some certs work and some don’t on older Windows Mobile devices.  Additionally it’s important to call out that browsers on clients behave differently too.  For example, Firefox has it’s own certificate store and doesn’t use the one in Windows.  The certificates in Windows and also on later mobile devices are updated and maintained through the secure connection of Windows Update.

Hopefully this clears up the server to client authentication.  Of course we know the client authenticates to the server by providing your username and password to prove you are indeed the user the server should give access to. 

Last important thing to remember, is NEVER install a certificate over an unsecure or un-trusted  internet connection, you should always use a SECURE method of installing certificates.  That means you download a cert over an already trusted and secure connection, or you bring it home in your pocket on a USB key.  You never know if there is going to be a malicious server giving you a bad certificate for the wrong server on the Internet.  Then you will just be giving your username and password to the wrong server on the Internet, and that would be disaster.

Update: Continue on to Part 2, now posted.