Creating entry in HKLM\...Firefox\Extensions is not installing the addon in Firefox 43, giving unverified error though addon contains the META-INF signature dir

Add-ons
#1

We have an unlisted plugin which we install through the msi installer, it creates the registry entry [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Mozilla\Firefox\Extensions] "abc@def.com"=“C:\n\mozilla” (Ref: https://developer.mozilla.org/en/docs/Adding_Extensions_using_the_Windows_Registry)

this folder contains the unzipped xpi, and on starting Firefox, it prompts to install the extension and it works.

With Firefox 43, even though we signed the xpi and registry points to the unzipped xpi with META-INF signature folder, Firefox still gives the unverified/sign error and extension is disabled. How can we force to install the signed extension in Firefox 43?

Installing the xpi directly works, though we had distributed the extension through our installer and now installer is not able to trigger the extension to be updated in Firefox.

On setting the xpinstall.signatures.required to false, it allows to enable the addon, doesn’t prompt for installation, still gives addon is unverified message.

It seems installing the xpi allows signature to be recognized but installing it through the given registry method doesn’t

xpinstall.signatures.required preference would be discontinued post Firefox 44, we need a method to install the signed addon without user manually doing it.

1 Like
#2

This is an NPAPI plugin. This is reported by others too

https://discourse.mozilla-community.org/t/firefox-fails-to-detect-updates-for-unpacked-extension-installed-through-windows-registry/5988/3

https://discourse.mozilla-community.org/t/installing-via-registry-in-firefox-64-bit/6064

#3

The Firefox Win64 version is “whitelisted” for only the Flash and SIlverlight Plugins, no others will work.

#4

We are experiencing the exact same scenario. After spending a day on this I’m happy to see someone else have the exact same issue.

#5

What is the add-on ID? We need to check that it has the right signature first.

#6

CIFWebProgressListener@ciceroinc.com

#7

In your case, you don’t have the right signature. Please go to this page and click on the Request Full Review link. That should sign your latest version again with the right signature, so you need to download it again.

There’s an explanation about this here.

#8

Jorge,

Part of the issue might be that we tried using jpm sign to sign our XPI file so we could ship/distribute & install an initial version that does not show up as “disabled” otherwise how will Firefox every query AMO?

So in the scenario discussed above I’m trying to install our self signed XPI and can’t as original poster noted.

  • Scott
#9

It’s not self-signed, it uses the AMO API to sign it, which defaults to the signature that doesn’t require side-loading. We know it’s confusing :expressionless:

#10

So given that, it’s that copy and signature that’s coming up as “disabled”. The AMO is not even in play yet.

#11

If it’s the same exact scenario as the opening post, which is that you’re trying to install it via Registry, my initial instruction about Full Review is necessary.

#12

We are having the very similar issue to this. The signed add-on id we are using is plugin@okta.com. We are able to install the add-on manually in firefox by installing the add-on using a file.

If we install via the registry we get a warning the the add-on is not signed.

#13

having the same issue. trying load CentrifyBrowserExtension@centrify.com which is signed and can be installed without issue by opening the file in firefox.

side-loading the extension via the mozilla.cfg methods or via the registry entries marks it as untrusted. exact same file but different behavior depending on how its injected.

#14

Both of you are exactly in the same situation. You need to go to your add-on management page, Request Full Review and upload a new version.

#15

I’m not the extension maker, simply an IT person looking to deploy the extension to the user base I support. Like i said the same file will show as signed/trusted when installed via the File > Open menu in FireFox. Literally the exact same file will show as unsigned/trusted when loaded automatically via mozilla.cfg and the registry methods.

Just verified the issue is there with the 43.0.4 release which appears to be the latest.

#16

The developer needs to get the extension signed with the correct certificate so that installation method works. There’s nothing you can do short of forking the add-on with a new ID and submitting it for signing yourself.

#17

Since we started having this issue, OKTA has deployed three versions of the software. All three versions can be installed manually and show up as signed and work properly. Once we try to deploy via the registry, the extension show up as unsigned.

Is there a step in the process that the vendor is not taking when they submit the extension for signing, that will cause the extension to be unsigned when deployed via the registry?

#18

Yes, at the moment Firefox checks the cert and will only accept the registry install method for one type of cert. There’s more information about this here.

I should note, though, that we’re in the process of removing that restriction, and eventually any signed filed will be installable using any available method.