📝 Written ● Intermediate Updated 2026-05-13

How do I set up HTTPS with Let's Encrypt?

TL;DR: On Ubuntu: sudo apt install certbot python3-certbot-nginx, then sudo certbot --nginx -d yourdomain.com. Certbot edits your nginx config and renews automatically every 60 days. Free certs, full TLS, 5 minutes total.

DNS routes traffic; HTTPS encrypts it. Let's Encrypt is a free, automated certificate authority that's been the default answer for "TLS on a Linux server" for nearly a decade. Two commands gets you a real cert; one cron job keeps it valid forever.

HTTPS is the bare minimum table stake for any site that lives on the open web. Browsers warn loudly when it's missing — a giant "Not Secure" badge in the address bar that destroys whatever trust your design earned. Users have learned to read this signal correctly: an HTTP-only site in 2026 looks broken, abandoned, or sketchy. There's no good reason to ship one and many reasons not to.

What makes HTTPS feel like a chore is that historically you bought a TLS certificate from a vendor (Comodo, DigiCert, Let's Encrypt's predecessors) for $50–500/year, validated your ownership through a manual email-and-DNS dance, and installed the cert in your web server by hand. Renewals were a calendar event you sometimes forgot. The whole flow was a small but real ongoing cost.

Let's Encrypt eliminated all of that. It's a free, automated, browser-trusted CA run by the Internet Security Research Group (Mozilla, EFF, Cisco, and others fund it). Their ACME protocol lets a script on your server prove ownership of a domain in seconds and receive a 90-day certificate. The tooling — usually certbot — automates issuance, installation, and renewal. The end result is HTTPS that just works, costs nothing, and renews itself.

What you'll learn

The two validation methods (HTTP-01 vs. DNS-01) and when each works
Installing certbot on a server (Nginx or Caddy)
The single command that gets you a real cert
How automatic renewal works (and what to check)
When NOT to use Let's Encrypt

Step 1: Prerequisites

What has to be in place before TLS

HTTPS depends on three things being already true:

Your domain points at your server. A and/or AAAA records in DNS, resolving to the server's IP. See Connect your domain to a server.
The server is reachable on port 80 from the public internet (for the most common validation method). If you have a firewall, allow port 80. Cloud VPSs usually require this in the cloud-provider firewall (Security Group on AWS, Cloud Firewall on Hetzner, etc.).
You have a web server installed (Nginx, Caddy, Apache). For pure-API servers behind a load balancer the situation is different; for an indie VPS, Nginx or Caddy is the path.

If any of these isn't true, fix that first. Let's Encrypt will fail in confusing ways otherwise.

Step 2: Pick a tool

Caddy is one command; certbot+Nginx is two

Two reasonable paths:

Caddy. Modern web server that includes Let's Encrypt support natively — no separate tool, no separate config. You write example.com { ... } in your Caddyfile and Caddy figures out the cert. Right when you're starting fresh.
Nginx + certbot. The classic combination. Two pieces but very well-documented; every guide on the internet assumes you have these. Right when you already have an Nginx config or want fine control.

For a brand new server with no Nginx baggage, Caddy is easier. For "I already have Nginx running and just want HTTPS added," certbot is right.

Step 3: The Caddy path (zero-config)

Install, configure, done

# Install Caddy on Ubuntu
sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | \
    sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | \
    sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update && sudo apt install caddy

# Configure: edit /etc/caddy/Caddyfile
sudo nano /etc/caddy/Caddyfile

Replace the file's contents with:

example.com {
    reverse_proxy localhost:3000
    # Or root * /var/www/html ; file_server for static files
}

Restart Caddy: sudo systemctl restart caddy. On first request, Caddy contacts Let's Encrypt, validates your domain (your DNS must already resolve to this server), gets a cert, and serves HTTPS. It also renews automatically.

Step 4: The Nginx + certbot path

If Nginx is already installed

Assuming Nginx already runs and you have a server block for example.com:

# Install certbot and the Nginx plugin
sudo apt install -y certbot python3-certbot-nginx

# Issue a cert and edit your Nginx config to use it
sudo certbot --nginx -d example.com -d www.example.com

certbot prompts for your email (used for renewal-failure notifications, won't be otherwise spammed) and agreement to the Let's Encrypt terms. It then talks to Let's Encrypt, validates your domain over HTTP-01 (a temporary file at /.well-known/acme-challenge/... that the LE server fetches), gets the cert, and rewrites your Nginx config to use it.

Test the HTTPS site: curl -I https://example.com should return 200 (or whatever your app returns). The "Not Secure" badge in browsers is gone.

HTTP-01 vs. DNS-01 validation. HTTP-01 (the default) needs port 80 reachable from the internet. DNS-01 instead asks you to add a TXT record to your DNS — useful when port 80 is blocked, when you're issuing certs for hosts not yet reachable, or when you want a wildcard cert (*.example.com requires DNS-01). For DNS-01 with certbot, add --manual --preferred-challenges dns or use a DNS-provider-specific plugin (python3-certbot-dns-cloudflare, etc.).

Step 5: Renewal — already set up

Verify the timer is running

Both Caddy and certbot ship with automatic renewal. Certs are good for 90 days; renewal runs daily and renews any cert within 30 days of expiring. You don't need to set up a cron job; the package's systemd timer is already installed.

Check it's working:

# For certbot:
sudo systemctl list-timers | grep certbot
sudo certbot renew --dry-run  # simulates a renewal without changing anything

# For Caddy: there's nothing to check — Caddy logs renewals to journalctl
journalctl -u caddy | grep -i renew

Set up an email-on-failure notification if you care about being paged: certbot already emails the address you gave it when issuance fails on its own. For Caddy, configure email-on-failure in your monitoring stack.

Step 6: Test the cert

One curl, one online checker

# From your Mac:
curl -I https://example.com
# Expected: 200 OK (or whatever your app returns), with no SSL errors

# Show the cert details:
echo | openssl s_client -showcerts -servername example.com -connect example.com:443 2>/dev/null \
  | openssl x509 -inform pem -noout -text \
  | grep -E "Subject:|Issuer:|Not After"

The Issuer should be "Let's Encrypt" or "ISRG"; the Subject should match your domain; Not After should be 90 days in the future.

For a thorough audit, run your domain through https://www.ssllabs.com/ssltest/. The grade should be A or A+. If it's lower, the report explains what to fix (usually old TLS versions still enabled or weak ciphers).

Step 7: When Let's Encrypt isn't the right answer

Three cases

You're behind a managed host that does TLS for you. Vercel, Netlify, Cloudflare Pages, every modern PaaS already issues and renews certs automatically. Don't run your own Let's Encrypt; their CDN handles it better than you would.
You need extended validation (EV) certs. Some enterprise contexts require EV certs with the legal-entity verification ($200–500/year from commercial CAs). Let's Encrypt is domain-validation only.
You're on an internal-only domain. Let's Encrypt needs to verify domain ownership; if your domain is internal (not in public DNS), use a private CA instead. mkcert is a good local-dev choice.

Rate limits exist. Let's Encrypt limits you to 50 certs per registered domain per week, and 5 duplicate certs per week. For normal use this is plenty; for a runaway script that re-issues constantly, you'll hit the limit and get locked out for a week. Use the staging environment (--staging with certbot) when testing.