So this week Chrome 68 rolled out and now every plain old http:// site gets a big gray "Not Secure" label sitting right in the address bar, left of the URL. Not a warning triangle, not a popup you can dismiss. Just a permanent little label that anyone visiting your site will see the whole time they're on it. Google's been telegraphing this for about a year and a half now (they started with just marking password and card fields back in Chrome 56, then form fields in general, and now it's just... everything), but seeing it actually land made me go check my own sites for the first time in a while, and yeah. Not secure. Great.
I'd been putting off moving techpad fully over to HTTPS because the last time I tried, maybe two years back, I ended up with a half broken site full of mixed-content warnings from old image embeds and a Twitter widget that refused to load over SSL, and I just gave up and reverted. This time I actually sat down and did it properly on a Sunday afternoon with a pot of coffee, so here's what actually worked, in case anyone else is procrastinating on the same thing.
Get a real certificate, for free
If you're self-hosting on a VPS like I am (still on the same cheap DigitalOcean droplet I've had for years, don't judge me), the easiest path by a wide margin is Certbot from the EFF. It's the client for Let's Encrypt, which issues free 90-day certificates and, more importantly, can auto-renew them for you with a cron job so you never have to think about it again. On Ubuntu it's basically:
sudo apt-get install certbot python-certbot-nginx
sudo certbot --nginx -d techpad.example -d www.techpad.example
and it walks you through the rest, including offering to set up the redirect from HTTP to HTTPS automatically. If you're on Apache swap python-certbot-nginx for python-certbot-apache. The whole thing took maybe ten minutes including waiting for DNS to look right.
The actual pain: mixed content
Getting the cert was the easy part, honestly. The annoying part is every image, script, or embed on your site that's still hardcoded to http:// instead of https:// or a protocol-relative //. Chrome and Firefox both block or flag this stuff once your page itself is served over HTTPS, so you end up with a green (well, gray now) padlock but a busted layout because your header image quietly failed to load. I found four years of old blog posts with hardcoded http:// image URLs pointing at my own uploads folder, which is a dumb mistake I clearly made over and over without noticing. A quick find-and-replace across the database fixed most of it. If you're on WordPress, the plugin Better Search Replace will do this safely without you hand-editing SQL, which I'd recommend unless you really enjoy hand-editing SQL at 11pm.
The one thing that still isn't fixed is an embedded SoundCloud player on a 2014 post that apparently only exists as an HTTP iframe and just doesn't render anymore. I could go dig up the new embed code. I have not done that yet. It's on the list, somewhere below "clean the garage" and above "learn Rust."
Was it worth it
Yes, honestly, and I wish I'd just done it back when Let's Encrypt went into public beta instead of assuming it'd be a hassle. The setup fear was way bigger than the actual work. If your site's still sitting on plain HTTP right now, Chrome's new label is basically Google's way of publicly shaming you into fixing it, and it works — I did this specifically because I didn't want people landing on my own blog and immediately seeing "not secure" next to it. Firefox is reportedly planning something similar down the line too, so this isn't a one-browser problem you can ignore by telling people to "just use Firefox instead," which was genuinely my plan for about five minutes.
If you're still stalling, the certbot route is the one to try first before you pay anyone for a cert or mess around with self-signed nonsense. Ninety days, auto-renew, done. Go check your own site's address bar right now, actually — I'll wait.