Couldn't they release an updated certificate? I suppose if you had some critical infrastructure that needed it, you could grab the certificate from a newer version of Firefox.
The certificate is hardcoded in the executable, and Firefox updates with the new certificate were released quite a while ago.
If you run into this issue you're either running Firefox at least nine(!) releases behind current, or you haven't bothered to install any patch updates for the LTS release in over half a year.
Even if they were to release a way to update the certificate in-place, the people who would need it aren't going to bother installing it. They are the same kind of people running Windows Vista in 2025.
This is a certificate used to sign and verify add-ons and (I think based on the reading) some DRM features. They did, in fact, release a new one. This is a warning to the people who haven't run their browser updates and don't have the new one.
There is no point in pulling down the certificate, it's only used by Firefox and there shouldn't be any valid use case to patch an old version to use the new certificate, you would just update your whole browser (it would be easier and safer).
Edit: to whoever downvoted me. I was trying to be helpful with an actual interpretation of the article that this story linked to. I was also answering what was a question in good faith, respectfully. So if my reply is factually inaccurate I would love to know how I misinterpreted it as a matter of curiosity.
> its only used by Firefox and there shouldn't be any valid use case to patch an old version to use the new certificate.
While I'm not the person you commented on I can somewhat provide insight into why it may have happened. In short, the sentiment and statement you made is misplaced and false, and neglects two critical things that are common knowledge at a professional level, which you may not be aware of. I'll elaborate below:
First, customized versions of firefox that have been non-insignificantly patched or may have been rebased into a custom tree or fork. Having a certificate hard-coded, creates by design additional work for anyone not following anything except the mainline tree. From a design perspective its known-brittle and lacking any common resiliency feature normally included in such systems. There's a good chance this was intended, sufficient to treat this as malicious compliance. By those who may maintain repositories, this can be perceived as a resource drain attack on said projects that value privacy but who have limited resources to fix the inevitable failures caused by these design decisions.
Mullvad Browser, or Tor Browsers as examples, albeit they have more resources than some of the other browser projects.
Second, many recent updates have been user hostile by Mozilla. A slew of features supporting bulk data aggregation, while also removing toggles that would frequently disable such features has been growing.
Forcing an update removes user choice and agency which they previously had in older versions, with coercive influence. Most importantly at the professional level, a lot of code changes translates into a lot of bugs, failures, and crashes.
When you have many upstream changes, to control costs you generally keep a local or semi-local repository to manage time cost in support and keeping a foundation you can build upon while staying sane. The software having a kill-switch like this, that's part of your local repository guarantees breakages, and it may not be immediately clear what the problem is (since its hard-coded). Backported security fixes are not uncommon, but the maintainability and time-cost are nullified by a kill-switch. Many view this as a kill switch because its hard-coded. Certificates for security would as a baseline require features for revocation. To my knowledge this isn't possible with these particular certificates.
There's a general rule, the more LOCs you touch, the more likely something is to break, and they've touched quite a lot recently.
Generally speaking, there appears to be quite a lot of effort (which translates into money spent) to embed points of failure within the client, similar to what Google has done in the past with Chrome.
Huh? You're asking why does time pass? I mean if you were asking about like a single player video game then I guess this makes sense, but the whole point of a web browser is like browsing the web. Tim's crap hypermedia thing for the Internet?
Since it's about addons (and not https connections) the same approach as with code-signing certificates could be used. For code signing it only matters that the certificate was valid at the time of signing, not when the signed resource is used.
E.g. when the certificate expires, any resource signed with that certificate while it still was valid continues to be usable, you just can't sign any new releases with the expired certificate.
I'm asking why my computer cares what time it is before it executes a piece of code. I put it there. Mozilla gave me permission at the time. I shouldn't need it again later. Code signing is DRM.
Couldn't they release an updated certificate? I suppose if you had some critical infrastructure that needed it, you could grab the certificate from a newer version of Firefox.
The certificate is hardcoded in the executable, and Firefox updates with the new certificate were released quite a while ago.
If you run into this issue you're either running Firefox at least nine(!) releases behind current, or you haven't bothered to install any patch updates for the LTS release in over half a year.
Even if they were to release a way to update the certificate in-place, the people who would need it aren't going to bother installing it. They are the same kind of people running Windows Vista in 2025.
This is a certificate used to sign and verify add-ons and (I think based on the reading) some DRM features. They did, in fact, release a new one. This is a warning to the people who haven't run their browser updates and don't have the new one.
There is no point in pulling down the certificate, it's only used by Firefox and there shouldn't be any valid use case to patch an old version to use the new certificate, you would just update your whole browser (it would be easier and safer).
Edit: to whoever downvoted me. I was trying to be helpful with an actual interpretation of the article that this story linked to. I was also answering what was a question in good faith, respectfully. So if my reply is factually inaccurate I would love to know how I misinterpreted it as a matter of curiosity.
> its only used by Firefox and there shouldn't be any valid use case to patch an old version to use the new certificate.
While I'm not the person you commented on I can somewhat provide insight into why it may have happened. In short, the sentiment and statement you made is misplaced and false, and neglects two critical things that are common knowledge at a professional level, which you may not be aware of. I'll elaborate below:
First, customized versions of firefox that have been non-insignificantly patched or may have been rebased into a custom tree or fork. Having a certificate hard-coded, creates by design additional work for anyone not following anything except the mainline tree. From a design perspective its known-brittle and lacking any common resiliency feature normally included in such systems. There's a good chance this was intended, sufficient to treat this as malicious compliance. By those who may maintain repositories, this can be perceived as a resource drain attack on said projects that value privacy but who have limited resources to fix the inevitable failures caused by these design decisions.
Mullvad Browser, or Tor Browsers as examples, albeit they have more resources than some of the other browser projects.
Second, many recent updates have been user hostile by Mozilla. A slew of features supporting bulk data aggregation, while also removing toggles that would frequently disable such features has been growing.
Forcing an update removes user choice and agency which they previously had in older versions, with coercive influence. Most importantly at the professional level, a lot of code changes translates into a lot of bugs, failures, and crashes.
When you have many upstream changes, to control costs you generally keep a local or semi-local repository to manage time cost in support and keeping a foundation you can build upon while staying sane. The software having a kill-switch like this, that's part of your local repository guarantees breakages, and it may not be immediately clear what the problem is (since its hard-coded). Backported security fixes are not uncommon, but the maintainability and time-cost are nullified by a kill-switch. Many view this as a kill switch because its hard-coded. Certificates for security would as a baseline require features for revocation. To my knowledge this isn't possible with these particular certificates.
There's a general rule, the more LOCs you touch, the more likely something is to break, and they've touched quite a lot recently.
Generally speaking, there appears to be quite a lot of effort (which translates into money spent) to embed points of failure within the client, similar to what Google has done in the past with Chrome.
ESR 128 and 115.13 was released 8 months ago, so if you had auto-updates enabled in all likelihood you don't need to do anything.
Why does a remote resource disappearing mean I can no longer use my local software? Fuck mozilla and their DRM.
Huh? You're asking why does time pass? I mean if you were asking about like a single player video game then I guess this makes sense, but the whole point of a web browser is like browsing the web. Tim's crap hypermedia thing for the Internet?
Since it's about addons (and not https connections) the same approach as with code-signing certificates could be used. For code signing it only matters that the certificate was valid at the time of signing, not when the signed resource is used.
E.g. when the certificate expires, any resource signed with that certificate while it still was valid continues to be usable, you just can't sign any new releases with the expired certificate.
A "cunning plan" to force upgrades? :-)
That only works with a timestamp service
This requires a trusted timestamp, which is possible, you just have to think of it when you are designing the system.
I'm asking why my computer cares what time it is before it executes a piece of code. I put it there. Mozilla gave me permission at the time. I shouldn't need it again later. Code signing is DRM.