Summary: Root certificates are a critical part of how encrypted connections like https validate the site you're connecting to. Updates happen periodically.
Windows Update has a download for "Windows Root Certificates". It was not critical and I did not know what it was. So a long time ago, I did not download it and turned the download off.
A search on Google gives me differing information on whether Windows Root Certificates are good or bad, or maybe even dangerous?
What are Windows Root Certificates and should I download and install 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.
Related:
Digital Signatures: what are they, and how do they protect me? Digital Signatures use public key cryptography to validate both message sender and message contents. Digital Signatures rely on simple concepts you should know, built on top of very complex mathematics you don't need to worry about.
Is an https connection really all that safe? https is an important part of keeping your data safe, but it's only a part. It's important to understand what it means and what it doesn't mean.
What does "BEGIN PGP SIGNED MESSAGE" mean? PGP SIGNED MESSAGE means that a message has been cryptographically signed. That means who signed it can be verified, and tampering can be detected.
Article C3878 - September 24, 2009
Thank you for that excellent explanation. I've never understood that stuff. So...you neglected to spell it out explicitly, but it's pretty obvious. In answer to your questioner's question, yes, it sounds like you should download and install them.
Posted by: Rosie Perera at September 24, 2009 3:54 PMI notice they are not mandatory downloads. Are they ever mandatory and if not, why? This seems as critical an update as any security update.
01-Oct-2009
Posted by: Gabe at September 30, 2009 8:27 AM
Thank you for the excelent explaination of this process. I'm in net+ training and prepping for the test. Now it all makes sense.
Posted by: Brett Brown at September 30, 2009 1:15 PMI'm missing the part where your web site receives public + private key from the CA and uses the private key to decrypt the message from the browser?
Posted by: Wout at October 22, 2009 2:58 PM