How Certbot Gets You a TLS Certificate — Explained

This is simplified for beginners to understand and may be slightly inaccurate due to simplification.

When you set up HTTPS on your server, you need a TLS certificate. But who gives you that certificate, and how do they know you actually own the domain? Here's exactly how that works.

The Players

Let's Encrypt is a Certificate Authority (CA) — an organisation trusted to issue TLS certificates. It was created by a non-profit called ISRG. To make certificate issuance fully automated, Let's Encrypt exposes HTTP endpoints following a standard called ACME (Automated Certificate Management Environment).

Certbot is a free, open-source command-line tool built by the EFF (Electronic Frontier Foundation, a non-profit focused on internet rights). It is an ACME client — it knows how to talk to Let's Encrypt's ACME endpoints to request and obtain certificates on your behalf.

The Core Problem: Proving You Own the Domain

Anyone can run a server and claim it hosts yourdomain.com. So before Let's Encrypt hands over a certificate, it needs to verify that the person asking actually owns the domain — meaning they have the authority to change its DNS records in the registrar.

Certbot solves this with a challenge-response process.

How the Verification Works

When you run Certbot on your server:

1. Certbot spins up a temporary HTTP server on port 80 and hosts a specific file at a known path
2. Let's Encrypt makes an HTTP request to http://yourdomain.com/<filepath>
3. Let's Encrypt checks whether the file it receives back matches what Certbot placed there

For this check to pass, yourdomain.com in your DNS registrar must point to the same server where Certbot is running.

If your domain's IP in the registrar is ip1 but Certbot is running on a server with ip2, Let's Encrypt's request reaches the wrong machine — the file won't match — and the certificate is denied.

Why a Malicious User Cannot Get Your Certificate

Say an attacker on ip2 wants a certificate for yourdomain.com, which they don't own. To pass the challenge, they'd need yourdomain.com to point to ip2 in the DNS registrar. But only the real domain owner can change DNS records in the registrar. If they can't do that, they can't pass the challenge — and they don't get the certificate.

This is the proof of ownership: if you can make a specific file appear at http://yourdomain.com/<path>, it proves you control the server that domain points to, which proves you control the domain.

After the Certificate Is Granted

Once the certificate is issued, the domain owner is free to move things around:

• Transfer the certificate to a different machine
• Change the domain's DNS to point to a new IP
• Set up a CNAME pointing elsewhere

Certbot doesn't police any of this. It only verifies domain ownership at the moment of certificate issuance — not permanently. The certificate belongs to whoever obtained it.

Summary

1. Let's Encrypt is the CA that issues the certificate; Certbot is the tool that talks to it
2. To prove domain ownership, Certbot hosts a file on your server and Let's Encrypt fetches it via your domain
3. This works only if your domain's DNS points to the same server running Certbot — at the time of issuance
4. After the certificate is granted, you can move it or reassign your domain freely

What Was Simplified — For the Curious

1. HTTP-01 is one of several challenge types: The file-hosting method described above is called the HTTP-01 challenge. There are others — notably DNS-01, where instead of hosting a file, you prove ownership by adding a specific TXT record to your domain's DNS. This is useful when port 80 isn't available or when issuing wildcard certificates.
2. Certbot is one of many ACME clients: Because ACME is an open standard, there are many other ACME clients besides Certbot — acme.sh, Caddy (which handles this automatically), and others. They all work with the same Let's Encrypt infrastructure.
3. Certificates expire and must be renewed: Let's Encrypt certificates are valid for 90 days. Certbot can be set up to auto-renew them. The short validity period is intentional — it limits damage if a certificate is ever compromised.
4. The actual certificate contains more than just a public key: What Let's Encrypt issues is not a bare public key. It's a signed certificate containing your domain name, your public key, validity dates, and Let's Encrypt's own digital signature — which is what browsers use to trust it.