I finally did the thing I've been putting off since basically Christmas: I moved techpad over to HTTPS. All of it, every old post back to November 2011, the whole archive. It took about four hours last night, one glass of wine, and exactly one moment of pure panic when the entire site 404'd for about six minutes. So, a pretty normal Saturday night around here.
I'd been putting this off for dumb reasons. Mostly because "certificate authority" sounded like something involving paperwork and a credit card, and I've got a cheap little box running nginx that I like precisely because I don't have to think about it much. But Let's Encrypt has been out of beta since April, it's free, and I'd run out of excuses. So last night, with the WWDC keynote livestream running quietly in another tab (the new lock screen redesign looks fine, Siri on the Mac is going to be a punchline for at least a year, more on that some other day maybe), I sat down and actually did it.
What I actually ran
If you're on Debian-ish Linux with nginx already serving your site, the short version is:
git clone https://github.com/certbot/certbot
cd certbot
./certbot-auto certonly --webroot -w /var/www/techpad -d techpad.example.com -d www.techpad.example.com
It used to be called letsencrypt-auto and apparently they're mid-rename to certbot right now, so half the blog posts and forum threads I found while googling around still call it the old name. That tripped me up more than it should have. I had two versions of the client sitting in two different directories for about twenty minutes before I noticed.
The cert itself takes maybe thirty seconds to issue once the webroot verification passes. The actual work is all in the nginx config: pointing ssl_certificate and ssl_certificate_key at the right files in /etc/letsencrypt/live/, adding a server block on 443, and then deciding what to do about port 80. I redirect everything to https now with a simple 301, which is where my six minutes of panic came from, because I wrote the redirect before I'd actually confirmed the 443 block worked, and for a few minutes nginx was cheerfully redirecting every single request into a config that didn't exist yet. Nice.
The part nobody warns you about
Mixed content. So much mixed content. Every image I ever hotlinked or embedded from a plain http source over the last four and a half years lit up Chrome's console like a Christmas tree, and about a dozen old posts had the little "not secure" warning even after the main cert was working fine, because I'd linked to an old imgur URL without the s. I spent almost as long grepping through old post files fixing http:// to https:// as I did on the actual certificate setup. If you've got a blog that's more than a couple years old, budget time for this part specifically, it is not optional and it is not quick.
The other thing worth knowing: these certs expire every ninety days. Ninety! Not the twelve months you'd get from a paid cert. That's apparently deliberate, something about encouraging automation and reducing the blast radius if a cert ever leaks, and I get the logic, but it does mean you cannot just set this up once and forget about it. You need the renewal cron job working, and you need to actually test it, not just assume it'll fire. I added:
0 3 * * 1 /root/certbot/certbot-auto renew --quiet --post-hook "systemctl reload nginx"
and then ran certbot-auto renew --dry-run right after to make sure it wasn't lying to me. It wasn't, thankfully.
Is any of this hard? No, not really, not compared to what I was picturing in my head for the last six months. But it's fiddly in a way that eats an evening, especially the first time, especially if your site has any age on it at all. If you've been putting off HTTPS on some old personal project because it seems like a hassle, it kind of is, a little, but it's a Saturday-night hassle, not a real problem. Do it before your browser starts yelling at your visitors for you, which is apparently coming down the pipe from Google at some point.
Green padlock's up now. Small thing, felt disproportionately good.