Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

All my addons "Could not be verified for use in firefox and has been disabled" (just seen today)

  • 8 replies
  • 1 has this problem
  • 152 views
  • Last reply by Alex_Pk

more options

Hi everyone,

I am running Firefox 91.5 on Red Hat Enterprise Linux 8.5 and just noticed that all my addons have been disabled and can't re-enable them.

Some of them are quite common modules such as Disconnect or Privacy Badger, so wondering what this may be.

There is a similar post on this forum dating back to 2019 and it mentioned a fix on Firefox was to be developped.

Anyone experiencing the same issue at the moment.?

Please see attached screenshot.

Kind regards,

Alex

Hi everyone, I am running Firefox 91.5 on Red Hat Enterprise Linux 8.5 and just noticed that all my addons have been disabled and can't re-enable them. Some of them are quite common modules such as Disconnect or Privacy Badger, so wondering what this may be. There is a similar post on this forum dating back to 2019 and it mentioned a fix on Firefox was to be developped. Anyone experiencing the same issue at the moment.? Please see attached screenshot. Kind regards, Alex
Attached screenshots

Chosen solution

Hi @jonzn4SUSE, many thanks for your follow up. I tried to observe things a little bit more before closing, and indeed, there is still something between Firefox add-ons, including with version 91.6, and FUTURE policies.

Eg. - with crypto policies set to DEFAULT, I can install extensions such as Privacy Badger or Disconnect, and these will still work after I changed the policy to FUTURE and rebooted the computer - however, with these policies set to FUTURE, a number of add-ons can't be added and there is a red box saying the add-on couldn't be added because it is corrupt. Happens to add-ons such as Ghostery, Cookies & HTTP header, HTTPS everywhere - back to DEFAULT, the same add-ons that were presented as corrupt can be added again to Firefox, and seem to work fine.

Looks like it would make sense to stay with DEFAULT setting on the computer for the time being.

Hi @ jscher2000, many thanks for your message, didn't think about that. So I check this point and my RHEL install runs chrony and the conf file points to a server, so looks like this seems ok!

And what do you think about the ticket itself? Should be closed because it works with DEFAULT, or is there something to look at about the FUTURE policies? Can't make that call myself, not being a specialist, but please feel free to recommend :).

Cheers,

Alex

Read this answer in context 👍 0

All Replies (8)

more options

I tried 1 of the extensions and it works for me. see screenshot Is there a reason for the old version of Firefox? Try downloading another copy of Firefox, run it from the folder and see if you have the same issue.

https://www.mozilla.org/en-US/firefox/all/#product-desktop-release


Operating System: openSUSE Tumbleweed 20220210 KDE Plasma Version: 5.24.0 KDE Frameworks Version: 5.90.0 Qt Version: 5.15.2 Kernel Version: 5.16.5-1-default (64-bit) Graphics Platform: X11 Processors: 4 × Intel® Core™ i7-4810MQ CPU @ 2.80GHz Memory: 31.0 GiB of RAM Graphics Processor: Mesa DRI Intel® HD Graphics 4600

Helpful?

more options

Hi @jonzn4SUSE,

Many thanks for your reply, much appreciated!

So the reason for not using the most recent version of Firefox (91.5) is that I kept in line with the RHEL repo.

From your screenshot, I can see indeed that you're using one of the add-ons that I enabled (HTTPS Everywhere) and it looks fine on your computer.

Since I published this post, I have had a further look at the discussions on Mozilla forum as to how it was addressed in bugzilla back in 2019. From there, I assumed the issue could be linked to an interaction of Firefox with some hardening parameters I updated in RHEL.

In fact, since this morning, the Firefox package is updated to 91.6 and the add-ons don't get disabled if the above mentioned parameters are changed, so all good !

Many thanks again and read you soon!

Helpful?

more options

Cool. If your issue is fixed, mark your comment as resolved and have a good day.  ;-)

Helpful?

more options

Is your system clock correct? SSL certificate verification is date sensitive. It would be preferable to enforce verification if you can get it working.

Helpful?

more options

Chosen Solution

Hi @jonzn4SUSE, many thanks for your follow up. I tried to observe things a little bit more before closing, and indeed, there is still something between Firefox add-ons, including with version 91.6, and FUTURE policies.

Eg. - with crypto policies set to DEFAULT, I can install extensions such as Privacy Badger or Disconnect, and these will still work after I changed the policy to FUTURE and rebooted the computer - however, with these policies set to FUTURE, a number of add-ons can't be added and there is a red box saying the add-on couldn't be added because it is corrupt. Happens to add-ons such as Ghostery, Cookies & HTTP header, HTTPS everywhere - back to DEFAULT, the same add-ons that were presented as corrupt can be added again to Firefox, and seem to work fine.

Looks like it would make sense to stay with DEFAULT setting on the computer for the time being.

Hi @ jscher2000, many thanks for your message, didn't think about that. So I check this point and my RHEL install runs chrony and the conf file points to a server, so looks like this seems ok!

And what do you think about the ticket itself? Should be closed because it works with DEFAULT, or is there something to look at about the FUTURE policies? Can't make that call myself, not being a specialist, but please feel free to recommend :).

Cheers,

Alex

Helpful?

more options

Hi Alex, I tried to look up this setting on https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening and that says:

DEFAULT : The default system-wide cryptographic policy level offers secure settings for current threat models. It allows the TLS 1.2 and 1.3 protocols, as well as the IKEv2 and SSH2 protocols. The RSA keys and Diffie-Hellman parameters are accepted if they are at least 2048 bits long. FUTURE : A conservative security level that is believed to withstand any near-term future attacks. This level does not allow the use of SHA-1 in signature algorithms. It allows the TLS 1.2 and 1.3 protocols, as well as the IKEv2 and SSH2 protocols. The RSA keys and Diffie-Hellman parameters are accepted if they are at least 3072 bits long.

I have no idea why this impacts Firefox's extension signing certificate, but I guess the system is involved?? You could file a bug and see whether this is going to get fixed in the future.

https://bugzilla.mozilla.org/

Modified by jscher2000 - Support Volunteer

Helpful?

more options

Hi Jscher2000, many thanks again for your message.

Yes, the RHEL guide you quoted is precisely the one I have been using to explore RHEL 8.5 :) and the topic of this conversation came up in the process of my practice of various chapters of this guide.

Can't pretend to be an expert of these matters at all, but indeed the lines you put in bold in the extract are the kind of issue I kind of suspected, as in 2019, a issue was identified on a intermediary certificate. But I don't know what certs are used for add-ons neither how does this interact with RHEL crypto policies.

I have started a conversation over the same matter in the RHEL community forum, as I wasn't sure where to look (in Firefox and/or in RHEL). A very senior member (RJ) has responded and I shared with him the same status as with you (btw, I checked again the time sync in the RHEL web console, and it was ok).

Will see when RJ can share his thoughts on the update I just shared, and with all your inputs, I'll see to create a ticket in bugzilla.

Many thanks again and kind regards,

Alex

Modified by Alex_Pk

Helpful?

more options

Hi Jscher2000,

Just a quick message to let you know that, as suggested, I have just created a bug repoirt in Bugzilla. https://bugzilla.mozilla.org/show_bug.cgi?id=1757541

The idea is to report this behaviour to find out what's the interaction between Firefox add-ons and RHEL, and if need be, see if there will be a fix.

Many thanks again for your help !

Kind regards,

Alex

Helpful?

Ask a question

You must log in to your account to reply to posts. Please start a new question, if you do not have an account yet.