What is TLS (and how does Let's Encrypt fit)?
A short reference on Transport Layer Security — what the padlock actually guarantees, how the certificate chain of trust works, and how Let's Encrypt and the ACME protocol automate issuing the certificate that proves you own a domain.
The one-sentence definition
TLS — Transport Layer Security — is the protocol behind the https:// padlock: it encrypts traffic between client and server and proves the server is genuinely the host it claims to be, using a certificate signed by a trusted authority.
The two jobs TLS does
People think of HTTPS as "encryption," but TLS does two distinct things, and the second is the subtle one:
- Encryption in transit — nobody between you and the server can read or tamper with the traffic.
- Authentication — you are actually talking to
example.dev, not an impostor who intercepted the connection. Encryption to the wrong server would be worthless; authentication is what makes the encryption meaningful.
The authentication half is what certificates exist for.
What a certificate is, and the chain of trust
A TLS certificate is essentially a public key plus a hostname, signed by a Certificate Authority (CA) that vouches "the holder of this key controls this domain." Your browser and OS ship with a built-in list of trusted root CAs. A real certificate is not signed directly by a root, though — it chains:
flowchart TD
ROOT["Root CA<br/><i>in your OS/browser trust store</i>"] --> INT["Intermediate CA<br/><i>signed by the root</i>"]
INT --> LEAF["Leaf certificate<br/><i>for example.dev, signed by the intermediate</i>"]
LEAF --> SITE["Your server presents this<br/>on every HTTPS connection"]
The browser trusts the root, the root vouches for the intermediate, the intermediate signs your leaf certificate — so the browser trusts your site.
When you connect, the server presents its leaf certificate (and usually the intermediate). The client verifies the signatures up the chain to a root it already trusts, checks the hostname matches and the cert has not expired, then both sides agree on a session key and the encrypted conversation begins. (Modern TLS 1.3 uses an ephemeral key exchange, so even a future leak of the server's key cannot decrypt past sessions.)
How Let's Encrypt changed this
Certificates used to cost money and be issued manually. Let's Encrypt is a free, automated CA that issues domain-validated certificates to anyone who can prove they control a domain — and "prove" is automated by a protocol called ACME (RFC 8555). Your server software talks ACME to Let's Encrypt, passes a challenge, and gets a certificate, with no human in the loop.
There are two common challenges, and the difference matters:
| Challenge | How you prove control | Can issue wildcards? |
|---|---|---|
| HTTP-01 | Serve a token at http://your-host/.well-known/acme-challenge/... on port 80 |
No |
| DNS-01 | Create a TXT record in your domain's DNS via the provider's API |
Yes (*.example.dev) |
HTTP-01 is the default for a single hostname; DNS-01 is required for a wildcard certificate because there is no single host to serve a token for *.example.dev. Certificates are short-lived (90 days), which is fine because renewal is automatic.
💡 Tip — You rarely run ACME by hand. A reverse proxy like Caddy speaks ACME for you: you write a hostname in its config and it obtains and renews the certificate automatically. The k3s edge uses the DNS-01 variant to get one wildcard cert for a whole cluster.
The short version
TLS encrypts traffic and authenticates the server, using a certificate that chains up to a root CA your browser already trusts. Let's Encrypt issues those certificates for free, and the ACME protocol automates proving you own the domain — HTTP-01 for one host, DNS-01 for a wildcard — which is what lets tools like Caddy give you "automatic HTTPS" with no manual certificate work at all.