Get off that old Firefox by Friday or you'll be sorry, says Moz If you're running an outdated version of Firefox, update by Friday or risk broken add-ons, failing DRM-protected media playback, and other errors, due to an expiring root certificate. Users with Firefox versions earlier than 128, which was released on July 9 last year, or the extended support release earlier than version 115. …
Librewolf 110.0-1 Windows 10 here. All my addons were disabled with the message "Could not be verified for use in Librewolf and has been disabled" so it appears to affect Firefox and its derivitives.
Setting xpinstall.signatures.required to false restored all my addons.
I've been liking Waterfox so far at work and at home (vertical tabs are pretty nice) although it seemed to take a while to "bed in" when freshly installed on my Windows 10 work PC and was initially a little unstable, seemingly locking up when trying to load web pages. Killing it in task manager then reloading the browser two or three times seems to have fixed it - worked just fine on the various Linux flavours I've tried it on however. Maybe I'll see how Librewolf stacks up against it as Waterfox can feel a touch more sluggish than Firefox did.
LibreWolf also has the ability to counteract more tracking than basic Firefox does.
https://lucb1e.com/randomprojects/cookielesscookies/
https://arkenfox.github.io/TZP/tzp.html
https://coveryourtracks.eff.org
https://privacy.net/analyzer/ (the "Fingerprint analysis" page in particular)
I usually try the above with NoScript, Privacy Badger, UBlock Orign, etc. all disabled just to see how awful my browsers are without protection.
All certificates have an expiry time cooked into them; this cannot be changed and defines the life of the certificate. Mozilla have stated that the root certificate is hard-coded into that version of Firefox, so you probably need to go to a later version to get a new root certificate.
Well given how TLS certificates work there is nothing preventing you from providing a 999 year one except the size of the integer holding the days until expiry value.
The only reason people don't is because it's bad security practice to do so, leaving the only revocation method as a Certificate Revocation List published somewhere, which may or may not work for a certificate hard-coded into the core of an application.
> The only reason people don't is because it's bad security practice to do so
I disagree. It is very common practice to not have arbitrary timeouts for TLS certificates. Just look at most SSH installs. Arguably these are also much higher profile targets too.
It would be like saying that every server in the world is applying bad security practice by not having certificates timing out every so often for SSH.
Root certificates, by design, are not renewable. Before they expire, they get replaced by new certificates. Mozilla did that a few years ago, and included the new certificates in Firefox releases. Once people update to a version of FF that's not ancient, they'll automatically pick up the new one.
The thing is, there's rarely a reason to actually replace/”renew" one. The *only* reason that is regularly given is the expiration, wich is just circular reasoning. They only *actual* reason is to remove or change something that has been broken or compromised. This is actually rare and rarely needs replacement roots, because revocation exists.
In other words this is a manufactured reason to force upgrades, and nothing more.
Seems to me that this push to PKI-based "security"*, especially with shorter and shorter certificate validity times, has a nice side effect of forcing everything to be a live service / subscription model. If you don't keep updating, and paying the subscription** it just stops working.
* The air quotes are deliberate, as I'm not convinced this actually makes anything more secure now, especially in the web/browser world where network-level m-i-t-m snooping of https is normal business.
** Either actual £/$, or by having the latest circle of enshitification (monetisation) forced on you. Good luck keeping an older version of a browser that still supports ublock origin working for much longer, for example.
> Is that just a feeling or can you link to some evidence?
It's been normalised as "best practice" in the corporate world (ref. Google, e.g. https://security.stackexchange.com/questions/107542/is-it-common-practice-for-companies-to-mitm-https-traffic).
No idea how pervasive it is outside corporate environments, but I don't believe anyone who says it can't be done.
> web/browser world where network-level m-i-t-m snooping of https is normal business.
Why would a web browser need to do anything like MITM snooping? It is literally the endpoint, it can do what it wants without before even creating the tunnel. You're confusing web proxies with web browsers.
The certs in question are related to code signing, so it's a good thing they expire.
The reason cert lifetimes have been getting shorter and shorter has nothing to do with money - the push for shorter lifetimes comes mostly from LetsEncrypt, which offers them for free.
The actual reason is that revoking a certificate that has been compromised (letting bad actors impersonate the victim website) is really, really hard. It soft fails - so if the bad actor can block your revocation check, the browser assumes your cert is valid!
Shorter lifetimes limits the damage that a compromised cert can do.
> The reason cert lifetimes have been getting shorter and shorter has nothing to do with money - the push for shorter lifetimes comes mostly from LetsEncrypt, which offers them for free.
I thought the push was coming from Apple and Google. Whatever. This seems to me to be the wrong solution to the problem. Basically we've given up on making certificate revocation work* **, so the only alternative is short-lived certificates, to make sure $badguys have to work overtime once they spot an opportunity.
* Bit like the lazy/incompetent programmer resorting to a poll loop because interrupts were too hard for them.
** The paranoid may suggest this is another happy accident...
It doesn't have to, in fact it's designed not to require root replacement outside of a serious mistake (hard coded keys, leaked keys, etc.) or a compromise. Bad keys can be revoked, so none of that matters unless it involves the root itself. If you are a responsible key maintainer you can sign non-root keys as replacements while revoking an old one, so again, replacing root keys is almost never necessary.
What you are seeing is instead abuse by a vendor, and a common style of abuse ever succeed they noticed they could claim security with keys and also prevent access (even legitimate) with them at the same time.
Exactly. I have a couple legacy endpoints that do non-critical specific tasks just fine with Firefox on Win7 today. They are not used for general browsing, random email links, or are exposed to any such risks.
I seems like more & more there is quiet collaboration within the tech industry to force extra spins on the upgrade-replace-renew wheel. Expire a cert, break Firefox, which cannot be updated on that OS, on hardware that cannot run a newer OS, thus spend money to replace kit that is otherwise still serviceable for the task it performs.
Article states - "Users with Firefox versions earlier than 128, which was released on July 9 last year, or the extended support release earlier than version 115.13, could face the issues starting March 14").
I am currently running ESR 115.20 on W7, which it appears, will continue to work fine on W7 (for now at least) - has just been updated to 115.21.
However, in view of some of the other changes that Mz appear to want to make, I will be likely to switch to something else in the near future anyway.
> firefox users that still run Windows 7? We can't update to the latest firefox
Look in your Win7 Computer, Properties and in your FF Help... About box.
I have Windows 7 Home Premium Service Pack 1, and just regular FF updates brought me to FireFox 115.21.0esr (as nobody just confirmed).
"Firefox versions earlier than 128, ....or the extended support release earlier than version 115.13, could face....
Because my 115.21esr is above the notice's extended 115.13, I am presumed to be safe. (Right?)
https://i.postimg.cc/rK445n3r/FF-esr-Mar2025.gif
"So what is the fix for firefox users that still run Windows 7? We can't update to the latest firefox because it won't run on W7."
As some have mentioned, 115 ESR continues to work fine and receive updates.
Alternatively, (and I would strongly recommend this instead,) Waterfox 6.0.20. It is a privacy-oriented fork of Firefox. It is based on Firefox 128, and the updated root certificate expires on Jan 15, 2038. It supports all of the same extensions as Firefox, including the beloved uBlock Origin.
Other options, such as Plasmafox/Redfox, Supermium, Yandex etc exist as well, but won't necessarily have the same desired functionality.
So this is completely against the best practice of keeping credentials and code separate.
God forbid Mozilla start observing best practices now, why should they change this late in the game?
Does it also mean that I can find this certificate in whatever Mozilla uses for an online code repository?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
