HTTPS stopped being optional years ago — browsers flag plain HTTP as “not secure,” and search engines quietly agree. The good news: Let’s Encrypt has made certificates free since 2016, and the tooling renews them for you. The catch is that the renewal has to be automatic — Let’s Encrypt certificates run 90 days today and are headed shorter over the next couple of years, and they stopped sending expiry-warning emails back in 2025. Set it up once, verify the automation, and forget it. You’ll need SSH access to your server with sudo, running Nginx or Apache.

Check what your host already gives you

If you’re on managed hosting — Pantheon, Kinsta, most cPanel shared hosts — there’s likely a button or a checkbox that does this whole lesson for you, usually labeled “SSL” or “Let’s Encrypt.” Go look before you install anything. This tutorial is for when you run your own server and there is no button. No shame either way; the padlock looks the same.

Install certbot

Certbot is the official client. The maintainers recommend the snap package because it keeps itself current, which matters more as certificate lifetimes shrink:

sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot

If your distro doesn’t do snaps, the OS package works — just make sure it’s version 4.1 or newer, which knows how to ask Let’s Encrypt when to renew instead of guessing.

Issue the certificate

One command, with your web server’s name and every hostname the certificate should cover:

sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com

(Use --apache if that’s what you run.) Certbot proves to Let’s Encrypt that you control the domain, fetches the certificate, and edits your web server config to use it. This only works if DNS already points those names at this server — if the issuance fails, that’s the first thing to check.

Redirect all traffic to HTTPS

Certbot asks during setup whether to redirect HTTP to HTTPS — say yes. If you didn’t, rerun it:

sudo certbot --nginx --redirect -d yourdomain.com -d www.yourdomain.com

One site, one address. Leaving both http and https answering means split caches, split analytics, and a padlock that only some visitors see.

Hunt down mixed-content warnings

If the padlock shows a warning, your pages are loading some asset — images, stylesheets, fonts — over plain http://. Open the browser’s developer console (F12) and it will name each offender. Most live in your site’s database or theme as hard-coded http:// URLs; on WordPress or Drupal, a search-and-replace of http://yourdomain.com to https://yourdomain.com in content clears nearly all of it. Take a backup before bulk edits — always.

Verify auto-renewal is actually scheduled

This is the step people skip, and it’s the one that pages you at 2 a.m. in ninety days. Rehearse the renewal without performing it:

sudo certbot renew --dry-run
systemctl list-timers | grep -i certbot

The dry run should end in a congratulations message, and the timer list should show certbot scheduled to wake up on its own. You’ve verified the whole lesson when three things are true: the site loads with a clean padlock at https://, plain http:// bounces you to it, and that dry run passes. Then check the padlock again in a few months — if it’s still green, the automation is doing its job, which was the point all along.