Public Key Cryptography

SSL (Secure Socket Layer) is the better-known and older name for TLS (Transport Layer Security), which is a technical specification that describes how secure communications happen between services and clients.

It is easier to explain how this technology works with a story.

Alice and Bob are two friends who like to share secrets. They have a habit of sending fun secret letters to each other through the mail. One day, however, Alice discovered that Eve the Evesdropper at the postal service would sometimes read their mail.

The couple were distressed at this, but they formulated a plan. Both of them got padlocks with keys. When Alice wanted to send a message to Bob, she would simply send him a letter saying, I would like to send you a message. Bob would then mail her his padlock.

Alice would then write her message and put it in a box. She would also include her padlock in the box. Once she locks the box, she can't get a hold of the message inside anymore-- and for that matter, neither can Eve! Alice mails the package to Bob.

Bob gets the package and unlocks it with his key. He finds in it the secrets Alice has given him, and Alice's padlock. He writes some secrets down, places his padlock and the note in the box, and relocks it with Alice's padlock. He can't open it once he's locked it, since he doesn't have the key. But neither does Eve. He sends it to Alice, who unlocks the box, and starts the process again.

SSL works in this way. It calls the padlocks "Public Keys", because you can give them away, and people will lock things with them that only you can open, and "Private Keys", which unlock the messages that are locked with your public key (again, the public key is more like a padlock than a key, but we didn't come up with the names. Cryptologists did!)

SSL only transfers the padlocks once, so you don't have to keep sending the padlock in your package over and over, so that's where the analogy breaks down. But these public keys can be registered with outside services. These outside services hold records of people's public keys. This prevents Eve from sending her own padlock to Bob and writing a return address on the box that says it's from Alice. Bob will check with the Public Key Infrastructure (PKI) folks, and ask them, "Is this really Alice's padlock?" They will say "No." and Bob won't use it.

Without these services, you don't know if you have the padlock from the right person. On the other hand, if you know the padlock is good already (for instance, if you set up your own SSL certificate), you don't need a third party to verify for you. If Bob knows Alice's padlock by heart, he won't have to ask anyone whose padlock it is. But if someone else wants to verify Alice's padlock, she'll have to register it.

If you use a self-signed certificate, you'll get an error message like you got when you first signed into the Plesk Panel, because your web browser won't know if the public key really belongs to your webserver. Any other visitors will also get this error message. If you're the only one who uses it, however, you probably don't need to register with the PKI.

Now, the PKI isn't just one organization. It's several that have worked out agreements to trust each other. Some of these organizations are lower down the totem pole than others. So when they issue a statement that says a key is valid, they have this statement encrypted with the public keys of the more prominent organizations every computer has records for. This set of statements is known as a "Certificate Authority Chain". Most SSLs come with these. The chain allows these keys to have the same amount of trust and authority as the top organizations provide.