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

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!

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

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

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

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/

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

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