So Firefox 52 came out last week and I almost didn't notice, because "point release with WebAssembly support" is not exactly a headline that gets my pulse up. But then I clicked into the login field on my own dashboard Tuesday night to fix a typo in a post and got this little grey warning icon with a line through it, plus a dropdown telling me "This connection is not secure. Logins entered here could be compromised." On my own blog. That I have run since November 2011. Cool cool cool.
Turns out this is by design. Starting with 52, Firefox flags any password field sitting on a plain HTTP page, even if the form itself posts somewhere secure behind the scenes. Chrome's been inching toward the same thing for a while, and I think it's the right call even though it embarrassed me a little. Most of us have some login form somewhere - an admin panel, a comment system, a stupid little internal tool - that never got the SSL memo because it felt like a hassle nobody would ever notice.
Anyway I spent about two hours Wednesday fixing it, and since I know at least a few of you reading this run your own WordPress or static-site setups, here's what I actually did, in case Firefox nags you too.
Step one: figure out what's actually still on HTTP
Don't assume. I thought my whole site was already HTTPS because I "did that thing" back in 2015. Turns out only the main domain was covered - my old subdomain for photos (still limping along, don't ask) was serving everything plain. Pull up your site in an incognito window and just click around every login-adjacent page. Comment forms count. Newsletter signup counts if it asks for a password anywhere, which honestly it shouldn't.
Step two: get a real certificate, and don't pay for it
If you're still paying $69 or $89 a year for an SSL cert like it's 2013, stop. Let's Encrypt has been live for almost a year now and it's free, and more importantly a lot of hosts have started baking it in as an automatic thing rather than something you configure by hand. I'm on shared hosting with cPanel, and AutoSSL was sitting there the whole time, quietly doing nothing because I never flipped it on. Took maybe four minutes once I found the toggle. If your host doesn't offer that yet, Certbot is the tool basically everyone points you to for grabbing a cert manually and it's not as scary as the command-line-ness of it suggests.
Step three: force the redirect, then go hunting for mixed content
Getting the cert is the easy part. The annoying part is that once you force HTTP to redirect to HTTPS, a pile of old image tags and embedded scripts pointing to http:// URLs will suddenly show up as "mixed content" warnings, and depending on the browser some of that stuff just won't load at all. I found this out because a Flickr embed from a 2013 post about my old apartment just silently vanished. Went and found probably fifteen posts from 2012-2013 with hardcoded http image links and swapped them to https or protocol-relative. Tedious. Not hard, just tedious, and there's no great automated way to do it if your posts are old enough that half the embeds don't even exist anymore.
I'll say this too, unrelated but related: Chrome 57 shipped a few days before Firefox 52 with this new background tab freezing thing, where inactive tabs basically get put to sleep so they stop chewing CPU. My laptop fan has been noticeably quieter this week and I genuinely didn't put it together until I looked at the changelog - I just thought my machine was having a good week. Small thing, but after years of Chrome eating a battery for breakfast it's nice that somebody over there is finally looking at the memory situation instead of just shipping more UI.
None of this is glamorous work. But if you've got a blog or a little side project that's been running for years like this one has, odds are decent there's some login form out there you forgot about that's about to start getting flagged too. Worth the two hours before it's your readers finding out instead of you.