121
An intermediate signing certificate, used by Mozilla to sign add-ons, has expired. This causes Firefox to consider add-ons signed with that certificate to be untrusted. The issue is being tracked in Bugzilla 1548973 and on Mozilla's blog.
Mozilla has released Firefox 66.0.5 for desktop and Android and 60.6.3 ESR, "which include the permanent fix for re-enabling add-ons that were disabled starting on May 3rd." It is recommended that you update Firefox to the latest version. The update replaces the studies, which means if you only enabled "studies" to get this fix, you can disable them again once you update to the current version of Firefox.
For anyone who doesn't choose to update to the current version of Firefox or Firefox ESR, Mozilla plans to release an update that will work with Firefox versions 52 through 65. The plan is that it will be a user-installable extension. The expectation is that they will update their blog post when more information is available. This was all the information that was available as of May 8, 19:28 EDT.
To update your Firefox version on Windows or MacOS, click on the menu in the top right, then select "Help" followed by "About Firefox". The update should then automatically download, and will be applied when you restart Firefox.
Not all package managers on Linux have released the new version yet. If your distribution's package manager has no updates available, then you may have to resort to either updating manually (using your preferred method) or trying one of the solutions below.
As of 2019-05-14, Mozilla's blog lists extensions that can be installed for users of older versions of Firefox who don't want to update (emphasis added):
- If you are running Firefox versions 61 – 65 and 1) did not receive the deployed fix and 2) do not want to update to the current version (which includes the permanent fix): Install this extension to resolve the expired security certificate issue and re-enable extensions and themes.
- If you are running Firefox versions 57 – 60: Install this extension to resolve the expired security certificate issue and re-enable extensions and themes.
- If you are running Firefox versions 47 – 56: install this extension to resolve the expired security certificate issue and re-enable extensions and themes.
[Note: the following fix requires that you enable "studies", which allows Mozilla to automatically download code to run on Firefox in the affected profile(s) (most users only have one profile). In addition, it requires that you enable "Allow Firefox to send technical and interaction data to Mozilla". If you've turned these off over privacy concerns, you should consider if you want to do this. You don't have to leave these settings enabled, but you do need to enable them to allow the studies that fix this problem to run. For those who don't want to enable "studies" and data reporting to Mozilla, please see Solution 3 (below; Solution 2 by default will send data to Mozilla and sometimes their partners). Using the study (Solution 1) by installing it using Alternative 3 (direct download) probably doesn't turn on reporting to Mozilla, but I have not tested for that.]
Mozilla has a fix for the problem for desktop users on Release, Beta, and Nightly, if you have "Studies" enabled. From Mozilla's blog, written by Kev Needham, licensed under CC BY-SA 3.0:
The fix will be automatically applied in the background within the next few hours. No active steps need to be taken to make add-ons work again.
Please note: The fix does not apply to Firefox ESR or Firefox for Android. We’re working on releasing a fix for both, and will provide updates here and on social media.
To provide this fix on short notice, we are using the Studies system. This system is enabled by default, and no action is needed unless Studies have been disabled. Firefox users can check if they have Studies enabled by going to:
- Firefox Options/Preferences -> Privacy & Security -> Allow Firefox to install and run studies (scroll down to find the setting)
- Studies can be disabled again after the add-ons have been re-enabled
It may take up to six hours for the Study to be applied to Firefox. To check if the fix has been applied, you can enter “about:studies” in the location bar. If the fix is active, you’ll see “hotfix-update-xpi-signing-intermediate-bug-1548973” as follows:
You may also see “hotfix-reset-xpi-verification-timestamp-1548973” listed, which is part of the fix and may be in the Active studies or Completed studies section(s).
Mozilla is working on a fix that does not need the studies system. They are aware that some users report that their extensions remain disabled even when both of the above studies are installed. That issue is being tracked in bug 1549078.
If you have studies enabled it may take up to 6 hours for Firefox to check for these new studies.
The user David, in a comment on the blog suggested the following for making Firefox check for studies quicker:
The six-hour wait can be dropped to seconds if you temporarily change the value of “
app.normandy.run_interval_seconds
” inabout:config
, restart, and then change it back to21600
(six hours) after things are working.
I'd suggest you don't set it below 60
seconds, or so. It's certain that it's been more than 1 minute since the last time Firefox checked for studies, or you'd already have the studies installed. Using a number like 60 will give you enough time to have the studies installed and to set the number back to 21600
, without having Firefox check for studies continuously. Just be prepared to change it back to 21600
once the studies are installed and then restart Firefox again.
I tried copying the study/hotfix from another profile. Manually adding the study/hotfix file to another profile did not work. When loading it this way it is recognized as a regular extension. However, it appears to use WebExtension Experiments, which is not enabled for normal extensions in the release version of Firefox.
It's likely that the configuration files in the profile directory could be modified to make it work (they are mostly JSON). However, I did not delve into it sufficiently to figure out what was needed.
It appears that you can directly install the primary "study" by directly going to the URL used for downloading it. I first saw the URL for the hotfix-update-xpi-intermediate@mozilla.com.xpi in this comment by Samuel Vuorela on Mozilla's blog post.
Machavity has an answer on this question describing his experience with downloading the study from that URL and more detail describing where that URL can be found in Mozilla's studies feed. It was his answer which got me to try downloading it directly, so if you find the direct install URL helpful, upvoting his answer would be appropriate. In that answer it's described that while directly downloading/installing the study *.xpi file is functional, doing so will not result in the hotfix being shown in either the studies list or add-ons list. It is shown as a study if Firefox later downloads it through its studies updates.
The content of the download at the above URL is an exact match for the hotfix-update-xpi-intermediate@mozilla.com.xpi file stored in the extensions directory after it is installed through the normal "studies" feed. Looking in the Browser Console indicates that installing directly from the download does not exhibit the same problem that manually installing the *.xpi from a previously downloaded copy does (i.e. it doesn't have the same problems which make installing it via Alternative 2 non-functional).
If you install Firefox Developer Edition or Firefox Nightly in about:config
you can set xpinstall.signatures.required
to false
. This will disable extension signature testing.
Firefox Nightly is a nightly build of the bleeding edge of Firefox development. It is only recommended if you are willing to live with any bugs which may exist.
Both Developer Edition and Nightly send "data to Mozilla — and sometimes our [Mozilla's] partners — to help us [Mozilla] handle problems and try ideas. Learn what is shared."
Firefox permits you to have multiple versions of Firefox installed at one time on a single machine. Personally, I have several versions installed. A fairly easy solution is to install Developer Edition and set xpinstall.signatures.required
to false
. You can then use Developer Edition for a few days until Mozilla gets the whole thing figured out and fixed. You could then go back to using the Release version of Firefox by just running that version.
Setting xpinstall.signatures.required
to false
will not work on the Beta or Release versions of Firefox on Mac or Windows. Doing so has no effect. On Linux, depending on your distribution, the setting may be respected and does work on some distributions of the release version of Firefox.
The preferred solution is to use the "studies" mentioned above. However, if that does not work for you, you can resolve this by disabling signature checking.
Signature checking is a security feature. Disabling it makes Firefox less secure. Once Mozilla gets their certificate issue resolved, it's recommended that you remove this code to re-enable signature checking. With this code installed to disable signature checking, you should be careful to only install extensions that you fully trust (e.g. ones that are hosted on Mozilla Add-ons).
Note: the rest of this answer was originally copied from my answer to How can I disable signature checking for Firefox add-ons? on Stack Overflow, but it's been modified a bit.
The following instructions will disable signature checking on Firefox for the Firefox profile in which you install the files. You are going to be adding some files to the chrome directory under your Firefox Profile directory.
I've tested this on Firefox 66.0.3+.
As of Firefox 69+, it is expected that, in addition to the instructions below, you will need to have toolkit.legacyUserProfileCustomizations.stylesheets
set to true
in about:config
. If it does not exist, then you will need to create it ("new" in the right-click context menu) as a Boolean option. See Bugzilla 1541233 for more detail about the addition of this option.
IIRC, some slightly different code was needed for Firefox 65. I believe I left that code in the try
/ catch
blocks when I modified it for Firefox 66, but I'm not sure about that.
This will not work if you have javascript.enabled
set to false
in about:config
. The default value for that configuration option is true
, so it should be fine unless you've specifically disabled it.
We're going to use a technique which allows you to run arbitrary JavaScript code in the browser context from files stored in your Firefox profile directory. I found how to do this from Haggai Nuchi's GitHub repository: Firefox Quantum compatible userChrome.js. This code is run once when Firefox starts, and then again each time you open a new window.
On Windows, your Firefox profile directory will be %appdata%\Mozilla\Firefox\Profiles\[profileID]
. If you have only one profile, the [profileID]
will be the only directory in the %appdata%\Mozilla\Firefox\Profiles
directory. If you have multiple profiles, you will need to select the one(s) you want to install this hack into.
Once you get to your profile directory, your will need to create a directory called chrome
, if it does not already exist. You will be adding the 2 files below to that directory:
userChrome.css
userChrome.xml
You will then need the following code in userChrome.css
, which is available from Haggai Nuchi's GitHub repository:
/*Enable userChrome.js */ /* Copyright (c) 2017 Haggai Nuchi Available for use under the MIT License: https://opensource.org/licenses/MIT */ @namespace url(http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul); toolbarbutton#alltabs-button { -moz-binding: url("userChrome.xml#js"); }
You will need userChrome.xml
(slightly modified from the version available in Haggai Nuchi's GitHub repository):
<?xml version="1.0"?>
<!-- Copyright (c) 2017 Haggai Nuchi
Available for use under the MIT License:
https://opensource.org/licenses/MIT
-->
<!-- This has been modified from the version available from
https://github.com/nuchi/firefox-quantum-userchromejs/blob/master/userChrome.xml
to include code by Makyen to disable add-on signing. If you want to load an additional JavaScript
file of your own, please see the original file by Haggai Nuchi.
This modified version is released under both the MIT and CC BY-SA 3.0 licenses.
-->
<bindings id="generalBindings"
xmlns="http://www.mozilla.org/xbl"
xmlns:xul="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
xmlns:xbl="http://www.mozilla.org/xbl">
<binding id="js" extends="chrome://global/content/bindings/toolbarbutton.xml#toolbarbutton-badged">
<implementation>
<constructor><![CDATA[
//Worked on FF65 and lower. The 3 different resources are used in different versions of FF.
try {
Components.utils.import("resource://gre/modules/addons/XPIProvider.jsm", {}).eval("SIGNED_TYPES.clear()");
} catch(e) {}
try {
Components.utils.import("resource://gre/modules/addons/XPIInstall.jsm", {}).eval("SIGNED_TYPES.clear()");
} catch(e) {}
try {
Components.utils.import("resource://gre/modules/addons/XPIDatabase.jsm", {}).eval("SIGNED_TYPES.clear()");
} catch(e) {}
//Tested on Firefox 66
try {
const {XPCOMUtils} = ChromeUtils.import("resource://gre/modules/XPCOMUtils.jsm");
XPCOMUtils.defineLazyModuleGetters(this, {
XPIDatabase: "resource://gre/modules/addons/XPIDatabase.jsm",
});
XPIDatabase.SIGNED_TYPES.clear();
console.log('Add-on signing disabled.');
} catch(e) {
console.error(e);
}
]]></constructor>
</implementation>
</binding>
</bindings>
After adding these two files in your profile's chrome directory, you will need to restart Firefox. You can verify that the code is running by looking for "Add-on signing disabled." in the Browser Console (in FF66+; the console output may not be displayed in earlier versions of Firefox).
Add-ons which were disabled or removed by Firefox may not be automatically enabled. You may need to re-install them, or at least manually enable them from about:addons
. You can install them by draging-and-droping the *.xpi file onto a Firefox window and confirming that you want to install, or going to the add-on's page on Mozilla Add-ons.
If you are wanting to get the *.xpi file for any particular extension from Mozilla Add-ons you can download it by right clicking on the "install" button and selecting "Save As", or "Remove".
If you have problems with FF<57, please see my answer to "How can I disable signature checking for Firefox add-ons?" on Stack Overflow. I believe I've incorporated everything from the comments on that question, but the comments describe some problems that other people encountered.
Unfortunately, I don't recall with which version of Firefox this method stopped working. I know I was using it on Firefox 54, 55, 52ESR and FF56.*.
I initially found this solution for disabling forced add-on signature checking in this blog post, which is the original source for the (somewhat modified) code in this answer. Making these changes will allow you to install unsigned add-ons into profiles using the Firefox distribution you modify. For most people, this will be your main Firefox installation. However, if you have installed multiple versions, you will need to make this modification in each installation. However, once you make the modifications, they will remain through normal Firefox updates.
You will need to add a couple of files within the Firefox installation directory. You can find a list of installation directory examples for Windows, Linux, and Mac OS on mozillaZine. The most common install directories are:
You then need to add code below as the file <Install directory>/defaults/pref/disable-add-on-signing-prefs.js
(Windows: <Install directory>\defaults\pref\disable-add-on-signing-prefs.js
):
//This file should be placed in the defaults/pref directory (folder)
//within the Firefox installation directory with the with the name:
// disable-add-on-signing-prefs.js
pref("general.config.obscure_value", 0);
pref("general.config.filename", "disable-add-on-signing.js");
You also need to add the code below as the file <Install directory>/disable-add-on-signing.js
(Windows: <Install directory>\disable-add-on-signing.js
):1
//This file should be placed in the Firefox installation directory
//(folder) with the with the name:
// disable-add-on-signing.js
try {
Components.utils.import("resource://gre/modules/addons/XPIProvider.jsm", {})
.eval("SIGNED_TYPES.clear()");
} catch(e) {}
try {
Components.utils.import("resource://gre/modules/addons/XPIInstall.jsm", {})
.eval("SIGNED_TYPES.clear()");
} catch(e) {}
With the current release version of Firefox, I've been using this solution for a while now to have a few extensions I built for my own use installed and to test new versions of extensions I'm working on (when I want to test in the Release version instead of Firefox Developer Edition or Nightly).
NOTE: In about:addons
Firefox may show (under some conditions) the add-on as enabled (not greyed-out), but have text stating that the add-on "could not be verified and has been disabled". The text is not accurate! The add-on is enabled and functioning.
[This is an explanation of older code, but the current code is very similar.]
Within resource://gre/modules/addons/XPIProvider.jsm
the const SIGNED_TYPES
is defined as a Set
. In order for an add-on to require signing, its type must be a member of that Set
. The Set.prototype.clear()
method is used to clear all entries from the Set
. This results in no add-on types which require signing (code 1, code 2).
If you wanted to, you could individually disable the signature check for any of the types: "webextension"
, "extension"
, "experiment"
, or "apiextension"
.
1If you are not seeing any active studies on about:studies
page, try disabling your Firewall. – DxTx – 2019-05-04T19:52:05.580
3FYI, Solution 3 only works if javascript.enabled
is not set to False
in about:config
. When Mozilla killed all add-ons on 04 May 2019 I had temporarily disabled Javascript to prevent unpleasant, normally-blocked content from loading -- then found doing so prevented this solution 3 from working also. – dbc – 2019-05-04T23:00:25.697
Perhaps one thing to note for alternative 3 is that you first need to save the file, and then drag-and-drop it into Firefox. At least, I had to do that. The automatically downloaded study fix didn't work for me, for some reason. – SeverityOne – 2019-05-05T07:06:56.743
One more solution for Firefox 56: https://stackoverflow.com/a/55990005
– Athari – 2019-05-05T08:10:32.453People who don't want to enable studies should just install the study manually. The other options are all unnecessary security risks. – OrangeDog – 2019-05-05T20:51:48.693
Given that the point of add-on signing is to prevent installers for other software dropping malicious extensions in your Firefox, shouldn't Mozilla be treating the user chrome hack as a security issue? There's nothing to stop a malicious installer from applying it to your Firefox to disable extension signing, which is the same reasoning behind why the about:config setting gets ignored in release Firefox. – interfect – 2019-05-06T20:52:14.107
2@interfect If malicious software has access to your files to change things in your profile's directory, you have larger problems than it potentially adding a malicious extension in FF. At the time extension signing was introduced, the issue was Mozilla wanting to prevent extensions from being installed from the internet which had not gone through the review process for listing on Mozilla Add-ons. In addition, they wanted the ability to blacklist malicious add-ons which they found in the wild. The threat model wasn't to prevent malicious code already running on the user's machine outside FF. – Makyen – 2019-05-06T21:18:08.863
@interfect If you read through the userchrome.xml, it seems they already did patch out something that used to work on older versions of Firefox. It is highly likely they are working to remove this exploit, too. ' – trlkly – 2019-05-06T23:26:40.123
@Makyen That's not entirely correct. I was around at the time, and they were definitely concerned with programs sideloading addons into Firefox. They even put in an additional sideloading check where Firefox will prompt you if any program tries to add an addon. They were definitely concerned with malware being able to modify a Firefox preference file, which is why there is no preference to disable signing in release versions. This is an exploit, and I fully expect Mozilla to work on patching it, like they apparently did with an exploit that worked on previous Firefox versions. – trlkly – 2019-05-06T23:32:45.717
Note that the only thing the 'study' does is install an intermediate certificate in Firefox's "Authorities" tab and force a signature re-check. At least the former bit can be done manually. – user1686 – 2019-05-09T04:41:10.197
Firefox 66.0.3 is on Ubuntu 14.04 (which is EOL), not on 16.04, which lives on. On 16.04, Firefox version is 67.0. – Ruslan – 2019-06-05T15:06:52.000
55
The intermediate code signing certificate expired. This means that all add-ons signed with the cert are no longer trusted. In this case the browser is doing it's job.
Mozilla will need to get the add-ons resigned and/or push a new cert out. Work is in progress to fix it. There is no resolution at this time unless you are on a developer code branch which you can go into about:config
and set xpinstall.signatures.required
to false
.
This will not work for most users and if you don't set it back may put you at some security risks. Best option is to wait this out. I imagine they will have this fixed in a few hours.
1
This post from Reddit demonstrates how you can temporarily load the addon manually in the meantime: https://www.reddit.com/r/firefox/comments/bkcjoa/all_of_my_addons_got_disabled_and_they_are_all/emggvbx/
– Marc.2377 – 2019-05-04T03:27:15.0273
Apparently so long as you have studies enabled via Firefox Preferences -> Privacy & Security -> Allow Firefox to install and run studies
in Firefox an update should be rolling out soon: https://discourse.mozilla.org/t/certificate-issue-causing-add-ons-to-be-disabled-or-fail-to-install/39047/13
2The update has rolled out, my Firefox is already fixed for instance. – Robert Longson – 2019-05-04T13:12:11.697
@RobertLongson Are you sure? I haven't seen any update for my Firefox. If there was a fix, it was only partial. – Graham – 2019-05-04T14:07:02.083
1@Graham yes I'm sure, Firefox checks every 6 hours for the update so sometime in the next 5 hours you'll be fixed given that the fix rolled out an hour ago. – Robert Longson – 2019-05-04T14:12:55.960
1Mozilla blog post dedicated to this issue – None – 2019-05-04T16:16:20.093
This works for Debian builds, which the Studies thing doesn't work for. – wizzwizz4 – 2019-05-04T20:48:55.413
That simple was the quick and effective solution for my case. – kokbira – 2019-05-07T19:51:25.513
This also helps on Ubuntu 14.04 which is stuck on Firefox 66.0.3 due to being EOLed. – Ruslan – 2019-06-05T15:15:52.633
12
This issue is due to a mass expiration of add-on certificates. As others have mentioned, a fix is in the works.
To temporarily re-enable add-ons, you can navigate to about:config
and set
xpinstall.signatures.required
to false.
This will re-enable any add-ons installed that have expired certificates, but it is not recommended to keep enabled long-term. I recommend turning it off as soon as the issue is resolved.
9The xpinstall fix only works for devloper or nightly builds. Most users should not do this! – Shawn – 2019-05-04T03:12:51.600
7I'm running release 66.0.3 and it works fine for me. As I mentioned in the answer, it's not recommended for long-term use. – Ulincsys – 2019-05-04T03:13:56.313
3I'm on the same release and it didn't work for me. – Marc.2377 – 2019-05-04T03:28:23.910
3
It seems that this workaround works for release only on linux, see https://news.ycombinator.com/item?id=19823928: "However, if you're running the Stable or Beta version, it will only work under Linux. On Windows and MacOS you'll need to download Nightly or the Developer Edition."
– ks1322 – 2019-05-05T09:15:07.077@ks1322 That makes sense, I use Ubuntu as my main OS, so I haven't even run into this issue on Firefox for Windows. I just assumed that all the flags would work equally on each platform. – Ulincsys – 2019-05-06T05:49:04.023
9
I found another way to get the hotfix. It's the same fix as above, but tinkering with settings trying to get Studies to download failed to get it on my machine. I found a GitHub issue that described yet another way to install the hotfix
Upon doing so my plugins immediately began working again. I don't know if you have to have studies enabled first or not (I had mine enabled). I also don't show it in extensions or the studies window, so just be aware you may not be able to disable it (possibly until Studies updates on its own).
Update: My browser finally pulled the studies feed and the hotfix shows in about:studies
(put it in your URL bar to see all studies), where you can indeed remove it. So all this does is get the fix into Firefox faster, but be sure to enable studies as outlined in Makyen's answer
There's a chance restarting Firefix will show it in the studies list. Either that, or when it downloads automatically it will be shown. – Alexander O'Mara – 2019-05-05T02:42:00.293
I've tinkered with the download timing and restarted half a dozen times. FWIW, this method works immediately – Machavity – 2019-05-05T02:44:11.807
Also, there are people reporting merely having studies enabled doesn't fix the issue. It's unclear if their machines just won't download the file or not
– Machavity – 2019-05-05T02:47:08.527Firefox doesn't appear to allow you to ignore the warning: "Firefox prevented this site from asking you to install software on your computer." – Mast – 2019-05-05T10:36:47.807
3
Although accepted answer mentions before-quantum versions (FF <57), it did not work for me(I'm using firefox ESR-52.9). After some hours of research I managed to fix the issue. Here is how I did:
In abstract, the solution has 3 steps:
of course you should make your profile backup before proceed.
download hotfix from mozilla. https://storage.googleapis.com/moz-fx-normandy-prod-addons/extensions/hotfix-update-xpi-intermediate@mozilla.com-1.0.2-signed.xpi
extract it(.xpi is just .zip), and open {extracted folder}/experiments/skeleton/api.js inside.
from the .js file, copy base64-encoded intermediate cert and paste into new text file. the cert looks like below. just copy double-quoted("") string (the MII... thing)
let intermediate = "MII...
decode base64-encoded cert and save as .der cert.
go to options-advanced-certificates-Authorities and install the cert as CA. trust it to identify software developers.
open your profile page and delete extensions.json, extensions.ini. caution: it will reset your add-ons enable/install status! backup your profile before proceed this step.
restart FF and check if the problem solved.
2
The update to fix this should get pushed automatically. If it doesn't, ensure the option to allow Firefox to install and run studies is enabled.
Copied from https://blog.mozilla.org/addons/2019/05/04/update-regarding-add-ons-in-firefox/
To provide this fix on short notice, we are using the Studies system. This system is enabled by default, and no action is needed unless Studies have been disabled. Firefox users can check if they have Studies enabled by going to:
Firefox Options/Preferences -> Privacy & Security -> Allow Firefox to install and run studies (scroll down to find the setting)
11Mozilla blog post dedicated to this issue – None – 2019-05-04T16:17:17.637
7Firefox Quantum 66.0.3 (64-bit) in Ubuntu 16.04: disabled
xpinstall.signatures.required
inabout:config
. Will give it a couples of days for them to release a fix and then re-enable it. I don't seem to have lost any settings. – Daniel – 2019-05-04T19:58:23.0333This impacts the Tor Browser Bundle too, but not all Firefox-derivatives. PaleMoon seems fine and I see a bunch of people talking about Waterfox. – YetAnotherRandomUser – 2019-05-05T12:26:59.597