Transport Layer Security (TLS) is the successor to Secure Sockets Layer (SSL). It's used to create a secure connection between two endpoints, such as in the HTTPS protocol, which encrypts data being sent between a web browser and a webserver.

When a user visits a website (or comparable client-server interaction), the server needs to authenticate itself to the client. The server doesn't have to care who the client is (or if it does, it will ask for authentication separately, such as a login page with a password for an established account the client holds with the server), but the client needs to be sure it's actually talking to the server, not another computer masquerading as the server.

Furthermore, the data being sent between the client and the server needs to be encrypted. No one should be able to read what's happening besides the client and the server.

Thankfully, public key encryption can solve this problem. Public key, or asymmetric, encryption, gives us the tools to prove who we are and to encrypt our messages so that they cannot be decrypted by anyone but the recipient, as well as the tools to sign our messages, proving that they came from us, and that they haven't been modified. In asymmetric encryption, each party has a private key and a public key. The public key is used to identify them and encrypt messages to them; the private key is used to prove ownership of the public key and to decrypt messages encrypted with the public key. The public key may be given out freely; the private key must be kept secret.

The problem is that key verification is hard. If I prove that I know the private key for my site, then you should believe that I am the owner of the site (or authorized by the owner to represent it). But how do you, the verifier, know that the key that I have proven myself to know, is actually the key for the site, and not just a random new key I created? I could upload it to a public registry of keys, but again, how do you know it was actually the owner of the site who uploaded that key, and not an impostor?

Perhaps I can run some sort of proof with you to verify to your contentment that I am the owner of the site, and then you will accept my key? This works if, for instance, we meet up in person (and you know how to verify my identity as the owner of my site in-person). You can verify that I am the person you think I am, and you can subsequently accept that the key I gave you, telling you it was my key, is my key, and thus represents my site.

But what if we can't meet up? What if I need to talk to so many people that I can't provide sufficient proof to each of them? (What if you don't know who I am?) We might delegate such a proof to an untrusted network. (You might, for example, accept my public key in an unencrypted email from me or because it's listed on some keyserver. Even this is too tedious to do with every single page you visit.

So what we do with TLS is we delegate trust to "authorities" on the matter. A certificate authority (CA) issues TLS certificates to those entities who have successfully convinced the CA of their identities. The TLS certificate can be thought of as a signed statement by the CA that the public key in question belongs to the identity (the domain) it claims to represent. If you trust the CA to be rigorous enough in testing that the key-holder is the owner (or controller) of the domain, then you can delegate the verification of the public keys to them.

In other words, not everyone should have to confirm individually with me that I am the owner of my site; instead, I can prove it to a trusted authority, who will give me a certificate showing, on their authority, that I represent the site.

You might be thinking that this model has centralization problems, and if so, you'd be right. So does the centralized domain registry. But CAs do allow us to add encryption onto the web to a greater degree than would be possible without uphauling everything. Changing standards is hard, especially while maintaining decentralization.