Thread: Add-ons not working due to certificate expiration

Is there going to be a release for Firefox developer version? I’m on 67.0b16 (64-bit) and the problem persist and no new versions are available.

As far as I’m aware updates for dev edition and beta are being worked on. I’d expect them to be released early this week.

However the study hotfix should apply on these, too afaik. See https://blog.mozilla.org/addons/2019/05/04/update-regarding-add-ons-in-firefox/ for details on the study hotfix.

2 Likes

This worked for me… instead of writing google.com or something like that write this:
about:config
then search for this:
extensions.legacy.enabled
and change it to true from false.
Hope I helped someone :slight_smile:

Edit: there’s a better fix available, firefox apparently needs you to change or have master password for addons to work.

Previously:

Things have become much clearer. As far as I can tell:

  • very few users of Waterfox are affected.

If you do find difficulty installing or updating an add-on with Waterfox, then these two things (posted today) might be useful:

  1. an overview for users of Waterfox
  2. a note about the signature of version 3 of Mozilla’s signingca1.addons.mozilla.org certificate.

Any updates/fix for this version?
Thanks!

Please see https://support.mozilla.org/kb/add-ons-disabled-or-fail-to-install-firefox#w_container-add-ons

:arrow_forward: Thread: Add-ons not working due to certificate expiration - FireFox ESR 52.9.0 (32-bit) and older

I have version 56.02, how is it your update disabled my copy? I have updates turned off, how did you disable my addons? Why did you disable my addons and is a fix coming for my version? I do not want to update to anything after this version, please fix this so I do not have to use a different browser from a different org.

There was no update, which is exactly the problem, since a certificate expired, leading to Firefox mistrusting any installed extensions.

It is currently unclear whether a fix will be provided for unsupported Firefox versions.

@freaktechnik, please explain what really had happened.
Because my settings is always to do not update and remains on my current version (66.0.2) and all that nightmare occurred anyway.

You said that there was no update at all, but HOW did Firefox know about extensions certificates? Is there any proccess going underground to check such things and we don’t know about?

When it happened here, I suspected about some kind of malicious .exe file which its task is to inform Mozilla other jobs that we weren’t inform about.

What is really proccessing while we browse site pages?
Is there any thread running in the background to check add-ons, no matter Firefox version?

How did Firefox know about my extensions certificate if I did not update it?

Thanks.

Firefox add-ons are signed, primarily to make it harder for malware to be loaded directly into Firefox. As a result, Firefox checks this signature before loading add-ons (even after they were initially installed, to ensure they were not tampered with). Verifying a cryptographic signature can be done by checking it against a certificate. The infrastructure to verify the signature also verifies that the certificate it’s using is valid.

Since a certificate in the chain for the certificate used for this verification expired, Firefox could no longer verify that add-ons were signed properly, and thus refused to load all add-ons.

The fix to this was to add a certificate to Firefox that is valid inside the chain, so the signature verification of add-ons worked properly again. This certificate has been distributed in both the ways this problem was fixed so far (hotfix via studies system, bug fix update that was released earlier today). If the problem wasn’t fixed after the update, Firefox likely failed to save the new certificate in its certificate storage for one of many reasons.

Thank you very much for your promptly response.
So, if I got it right, every time I run Firefox, it makes its check list proccess to validate all extensions, no matter if those extensions were already installed before.

But what happens if I run it offline?
I tested this way on saturday, to force to keep my extensions from a backuped profile folder and it did show that yellow bar saying that my add-ons was invalid…

Because of that, I suspect about some malicious .exe file running and bringing back the YBOD (“Yellow bar of Death”). :slight_smile:

The certificate and the signed add-ons are stored locally. No internet is needed for this action. That’s also why a patch to Firefox was needed and this couldn’t be solved with a server side update.

Great!
Excellent.

All my doubts are gone.

Thank you for your kind attention.

:wink:

1 Like

So why can’t we just download a valid certificate and store it ourselves? Why all this dancing around various versions some of which can and some that cannot apply the fix, being on older versions for whatever reason?

1 Like

As you’re well aware you can add that certificate yourself, it’s just not officially provided by Mozilla and it hasn’t had consistent results for everyone. Applying the certificate yourself has a couple of drawbacks, starting with ensuring that you’ve got the proper certificate.

Delivering the certificate with official update mechanisms keeps the trust chain unbroken. The fixes also ensure that add-ons are re-enabled as fast as possible, instead of waiting until Firefox next re-checks add-on signatures or other small fixes that may be required.

You’ll also be happy to hear that a fix that should work at least for Firefox 52 and newer is being worked on by Mozilla (however the release of it is TBD, so its timeline is unknown). I’ll avoid linking the bug here until the fix is done to avoid spam in the bug, sorry, but it’s publicly visible on bugzilla. With this fix the goal, too, is to ensure the trust chain is not broken.

1 Like

Thank you. makes sense and am glad to hear that fixes are in the works. I turned on “Study”, it was completed and nothing happened. Add-ons were not re-enabled. I am on 56.0.2

As far as I understand that’s one of the driving reasons for a separate fix. The study fix doesn’t apply on some older versions. Though I expect the fix method to be similar and thus similar known issues to occur (master passwords potentially messing up the fix, themes not being restored etc.)

@freaktechnik, is there a way to “lock” my version and group of extensions?
I mean “lock” is to keep it (Firefox settings and my small group of add-ons) unchanged for the next 12 months or so.

I don’t want to update it every 30 days, I use the browser to ordinary jobs, I’m not a heavy user or hacker nerd. I just want to have a tool untouched for months ahead and don’t want to be bad surprised eventually, like now.

Just to leave my settings and extensions alone. Is it possible?

Again, thank you for taking the time. After all of the foregoing, I found that this did the trick for me. Not sure what will happen once an “official” fix is released.

From a Bugzilla post:
r/mudkip908 from reddit posted the following work-around:

You could also replace all occurrences of "appDisabled":true with "appDisabled":false , and "signedState":-1 with "signedState":2 in extensions.json in your profile directory. (Get to it from about:support )

1 Like

@freaktechnik Yes, a big thank you for the clarity and detail. Don’t think we’d be getting this from… you know who. Sounds like a single-point of failure has been identified (?) but which wouldn’t have been such an issue if the ‘cause’ was explained in FF, with an option to temporarily override the disabling… though I know that’d kind of defeat the whole point! But like any truly useful software, we incorporate it and so become dependent on it - so many reach a tipping point of loss vs risk. But generally speaking… I’ve been very impressed with the response and openess. :slight_smile:
Many thanks to FF devs…