I finally did the thing I've been putting off since basically forever: techpad is on HTTPS now. If you're reading this from an old bookmark that still says http://, it should redirect you automatically. If it doesn't, go yell at my nginx config, not me.\n\nThe reason I dragged my feet on this for something like four years is dumb and I'll just admit it: certificates used to cost money and be a pain to renew. My old host wanted something like $60 a year for a basic cert through a reseller, and every time the renewal email showed up I'd think "eh, techpad doesn't take credit card numbers, who cares," and close the tab. Which, fine, mostly true. But Google's been nudging search rankings toward HTTPS sites for a couple years now, and I finally got tired of pretending that didn't matter to a blog that lives and dies by search traffic.\n\nWhat actually pushed me over the edge was Let's Encrypt coming out of beta a few weeks back. It's a free, automated certificate authority backed by Mozilla, EFF, Akamai and a bunch of other names you'd recognize, and the whole pitch is that getting a real cert should take about as much effort as running one command. I'd heard about it since last year but figured "beta" meant "not for a production blog that gets maybe 400 visits a day on a good day," which, looking back, was overly cautious of me.\n\nHow I actually did it\n\nMy setup is boring: a $5-a-month DigitalOcean droplet running Ubuntu 14.04 and nginx, serving a static site built with a homegrown script (not Jekyll — I tried Jekyll back in 2013 and hated fighting with Ruby gems more than I hated writing my own thing, don't come at me). Getting the client running was maybe twenty minutes of actual work. Clone the repo, run it pointed at your webroot and domain, and it drops the cert files straight into /etc/letsencrypt/live/yourdomain/. From there you just point nginx's ssl_certificate and ssl_certificate_key lines at those files and reload.\n\nThe part everyone warns you about, and the part that actually matters, is that these certs expire every 90 days on purpose, to force automation instead of letting people forget about them for a year like I did with the old one. So there's a cron job now, running early Monday mornings, that checks whether anything's within 30 days of expiring and renews it if so, does nothing if not. I tested it with the dry-run flag first, because I did not trust past me to write a cron job correctly at midnight and have it work unsupervised.\n\nThe genuinely annoying part, and nobody warns you about this enough, was mixed content. Every old post going back to 2012 had hardcoded http:// links to images I'd hosted myself, a couple of embedded YouTube players using plain old http, and one ancient post linking out to a since-dead Tumblr that Chrome flagged as insecure even though it's just a link, not anything embedded. I spent longer hunting down four years of my own sloppy markup than I did on the actual certificate setup. That felt about right, honestly. The boring plumbing is never the hard part. Cleaning up after past-me always is.\n\nIs any of this urgent for a personal blog with basically nothing worth stealing on it? Not really, no. But it's free now, it renews itself, and there's a decent chance it helps a little with search visibility, so the math on "why not" got a lot easier once cost stopped being the excuse. If you're running something on a VPS you actually control and you've been putting this off for the same dumb reason I was, it's genuinely not the multi-hour ordeal it used to be a couple years ago. Took me longer to fix my own old blog posts than to get the certificate working in the first place, and I still haven't found every broken image link. There's probably a 2012 post out there right now throwing a console warning that I'll notice by accident sometime in 2018.
Worth saying since it is relevant to this exact post: the domain and hosting for techpad both run through Tricknowtech these days, and the free cert renewal cron job is honestly one less thing I have to remember to babysit.