Why do we need certificates confirming certificates?

Question

Why do we need certificates confirming certificates? Why create a hierarchy or tree? These questions makes me confused, could you explain it me?

Answer 1

It's a way of managing "trust". Let's say you do business with MyBank.com. Would you want to type your account number and PIN in the clear, and let any hacker on the network view it? Probably not -- you shouldn't trust such a system. So you want to encrypt the data. Also, would you trust every web page with a pretty logo proclaiming itself to be "MyBank.com"? Would you type your account number and PIN into it? I hope not, because there is nothing secure about showing a copy of a picture. So we know trusting the logos isn't enough. We now have two different, but related problems: we have to secure the data through encryption, and we have to know if we can trust this site is who they say they are. Certificates are designed to help solve both of those problems. The certificate contains the public key of the remote site so we can encrypt the data, and it has a signature we can use to confirm the public key is the right key, and not a fake key provided by a criminal.

But just because a web site encrypts your data, and hands you a certificate, how do you know the certificate you've got is actually for MyBank.com? How can you trust it?

We could confirm it directly. The next time we visit the lobby of MyBank.com we could ask the cashier, "Cashier, please give me a copy of the certificate to your bank's web site, so that I know I can trust it." And that would absolutely work -- for that bank, one certificate at a time.

But let's say you also want to do business with CheapBank.com, located in a distant city. Traveling there just to confirm their certificate would be expensive, so you wouldn't do it. How could you do business with them and still know that you can trust them? You could ask someone else to verify their identity for you. Let's say you have a friend in that city. You call him up, you ask him to drive to CheapBank.com, get a copy of their certificate, and send it to you. That would work, too, but now it's more work. (And it opens a different can of worms - how do you know the mailman or your friend didn't swap certificates?)

The answer we have settled upon is to have a trusted third party sign the certificates. These are companies that anyone with a certificate can go to, provide some kind of proof that they are who they say they are, and this third party will then sign their certificate. This signature is an attestation by Valid-Certificates-R-Us.com that this is actually CheapBank.com's genuine certificate. Of course, how do we know that Valid-Certificates-R-Us.com actually signed their certificate? By validating the signature with their certificate!

This leads to another problem: how do we know that Valid-Certificates-R-Us.com is a trustworthy certificate signer? For all we know, it could be run by a criminal gang, who will sign certificates for anyone trying to commit fraud. The answer is "the self-signed certificate", which means that Valid-Certificates-R-Us.com signs their own certificate with their own signing key. How does this help us? Why should we trust a self-signed certificate just because it was signed by Valid-Certificates-R-Us.com? We shouldn't. It's the same problem we originally had validating the bank.

So, to combat this, your operating system vendor or your browser vendor doesn't trust random self-signed certificates. It only trusts self-signed certificates that it installed. Your OS vendor validates the certificates they are going to install before they package the OS and ship it to you. If you look deep inside your computer, you'll find that there are a few hundred different self-signed certificates, from different certificate signing authorities scattered around the globe. Many are issued by companies in the certificate business, some are issued by various national banks. All have been checked out by your OS or browser vendor. If one of these entities is ever caught issuing bad certificates, an emergency patch from your vendor will remove their certificate from your computer, causing you to no longer trust them, or any of the web sites whose certificates they signed.

So, if you step back from all this and look at the picture of these relationships, it looks like a tree: at the root you have one browser, which trusts hundreds of self-signed certificates, each of those self-signed certificates is used to sign many thousands of other certificates, each of which can attest to one of the millions of web sites out there.

Answer 2

Actually, we don't We need a third party/token to be trusted, and - for censorship convinience this third piece is a certificate. When there're alot of notaries for SSL verification in projects like Perspectives - it is rudimentary to have a single central CA.