What are Root Certificates, and why do I need to update them?

Root Certificates are one of the fundamental pieces of public key cryptography used by browsers and other services to validate
certain types of encryption. For example, the root certificates are used whenever you connect via an https connection to make sure
that you’re connecting to who you think you are.

]]>

As usual, I have to throw out this disclaimer to keep the pedants at bay: this is of necessity, an over simplification. I’m not trying to cover the nitty gritty details, just explain the general concepts.

I’m also going to be tossing the terms “key” and “certificate” around kinda loosely. While there are technical differences, again for the purposes of this discussion that’s irrelevant.

•

First, a little diversion into “public key cryptography”.

By now you’re probably already aware of “symmetric key cryptography” – that’s where you use a single key or password to scramble or encrypt some data. Only with that same key or password can you unscramble the data back into its original form. While it’s in its encrypted form the data is unrecognizable.

“Asymmetric key cryptography” relies on some very complicated (and pretty cool) math to generate two keys: I’ll call them “A” and “B”. Anything you encrypt with A can only be decrypted with B, and anything encrypted with “B” can only be decrypted with “A”. And yes, I’ll admit that it’s kind of magical that such a thing is even possible.

“Public key cryptography” makes one of those two keys public and available to anyone, and keeps the other key private and secret. In fact, here’s public key I use. That’s important because:

• Anything you encrypt using my public key is something that only I can decrypt. You want to make sure that I’m the only person who can see something? Encrypt it using my public key.

• Anything I encrypt using my private key is something that can be decrypted by anyone, but it can only be decrypted using my public key. That’s useful, because if you can successfully decrypt something using my public key then you know that only I could have encrypted it.

I want to reiterate that second point again because it’ll be important in what’s to come: if I encrypt something with my private key, you can absolutely confirm that only I could have encrypted it by using my public key.

•

Next, we need to talk a little about “cryptographic signing”.

Let’s say I create a message, and I encrypt it using my private key. When I send you the message I send both the unencrypted and encrypted versions.

You might call the version encrypted with my private key my “signature” because it can prove two things:

• if you can decrypt it using my public key, you’ve proven that the message could only have been encrypted with my private key – in other words, you’ve proven that the message came from me

• if the message you decrypt matches the unencrypted version, then you’ve proven that the unencrypted version was not tampered with or altered between the time I sent it and the time you saw it

(In practice it’s not the entire message that’s encrypted, but rather a mathematical “hash” of the message – a calculated number that’s much smaller in size but that can serve the same validation purpose.)

•

So here’s a question: how do you know that my public key is, in fact, my public key and not a fake?

That’s the dilemma that secure websites face when they use public key cryptography to secure their connections. It works like this:

• Your browser contacts the remote secure site saying “let’s talk, securely”.

• The remote site says “sure, here’s my public key so we can encrypt things”

• Your browser encrypts the rest of the information it sends using that public key so that only that web site can decrypt it.

How do you know that the site you connected to in the first step is who you think it is? They gave you a public key that might well claim to be them, but they could be faking it.

The answer is that the public key is, itself signed by a “certificate authority”.

When I created https://secure.pugetsoundsoftware.com I engaged with a company – Equifax – to generate the public and private keys that the site would use to encrypt the connection. (There are several companies that do this.) After validating who I was, they then signed the public key – that is, they encrypted my public key using their private key, and included both the unencrypted and encrypted versions of my public key in the result.

Now, let’s look at that https conversation in a little more detail:

• Your browser contacts the remote secure site saying “let’s talk, securely”.

• The remote site says “sure, here’s my public key so we can encrypt things”

• Your browser then decrypts and checks the signature included with that public key. If that works, and the key was signed by someone your browser knows is a trusted signer, then that public key could only have come from the actual site it claimed to have come from and no other. You know with certainty who you’re talking to.

• Your browser encrypts the rest of the information it sends using that public key so that only that web site can decrypt it.

“But wait”, I hear you saying, “don’t you need a public key to decrypt the signature in that third step?”

Yes. Yes you do.

That’s a root certificate.

Windows and your browser securely maintain a predefined set of public keys on your machine for each of the official certificate authorities. When your browser establishes a new https connection it validates the signature on the public key it gets from the site using one of those trusted root certificates.

The reason that Windows manages the root certificates is that it needs to be done securely. It’s important that only official and trusted root certificates are made available on your machine. You don’t want to be trying to get them “on the fly” off the internet as you need them either, because of the potential for malicious interception. They need to be securely maintained and placed on your machine by Windows Update, or by some other authority charged with the responsibility.

As I said, there are actually several certificate authorities. I happened to use Equifax, a more recognizable name might be VeriSign, but in reality there are well over 100.

And, the list changes from time to time as authorities update their own certificates, and authorities are added to or removed from the list. Hence the “Root Certificate Update” you’ll occasionally see in Windows Update.