Fork me on GitHub

Signing an XPI using a VeriSign Code Signing certificate

I recently had to sign a Mozilla Firefox extension using a VeriSign Code Signing certificate. The process to receive the cert is pretty straightforward - you apply for the certificate on VeriSign's page where you input your company details and payment information. By the way, you can use "THEDEAL99" promo code to get $400 off $499 for a Microsoft© Authenticode© certificate to make the price somewhat reasonable. After your application is submitted they verify the validity of your company and the information you put in and issue you the certificate that you can use for code signing.

I exported the certificate and the private key out of the browser into a pfx file. In Internet Explorer this can be achieved by going to Tools -> Internet Options -> Content -> Certificates -> Personal tab, and clicking export, which takes you to a wizard to guide you through the export process. I was able to successfully sign and test executables using Microsoft's signing tool using the command below:

signtool.exe sign /f cert.pfx executable.exe

For XPI though, things weren't as easy. I followed this guide from Mozilla to sign the XPI using the latest compiled version of Network Security Services (NSS). The latest binaries that I found were for version 3.12.4 here. After successfully importing all the certificates and the private key into a new NSS database, I was able to sign my Mozilla extension by using the following command:

signtool.exe -d . -k {CERT_NAME} -p {CERT_PASSWORD} {XPI_DIRECTORY}

After repackaging the signed XPI it was displayed as untrusted by Firefox with a default configuration. Firefox displayed a generic "Signing could not be verified" error message with an error code of -260 as can be seen below:

Firefox Certificate Error

I also tried XPISigner, an application that simplified XPI code signing process written in Java, but got the same results. Instructions for XPISigner are here. XPISigner just needs your certificate pfx file and will take care of repackaging for you.

After investigating thoroughly, I found that the certificate signing chain looked as follows:

  • VeriSign Class 3 Public Primary Certification Authority - G5
    • VeriSign Class 3 Code Signing 2010 CA
      • (our cert)

And that the "VeriSign Class 3 Public Primary Certification Authority - G5" certificate is not trusted to "identify software makers" as can be seen in the image below:

Firefox G5 CA settings

Checking that checkbox resulted in Firefox trusting the signed XPI as expected, however we couldn't require our users to manually alter their browser configuration just to install the XPI.

After a few emails with VeriSign support, I discovered that the "VeriSign Class 3 Public Primary Certification Authority - G5" certificate is not supposed to be the root Certificate Authority, but an intermediate one. It is supposed to be signed by VeriSign's "Class 3 Public Primary Certification Authority" even though it is considered to be a root CA by all browsers including Firefox as can be seen here. The certificate chain is supposed to look like:

  • VeriSign Class 3 Public Primary Certification Authority
    • VeriSign Class 3 Public Primary Certification Authority - G5
      • VeriSign Class 3 Code Signing 2010 CA
        • (our cert)

So, now the problem was getting NSS to view the G5 certificate as an intermediate CA rather than root. For this I needed to remove the builtin G5 CA and add it as an intermediate manually. NSS does not provide any easy way to remove a builtin CA, the only documentation I found was here, requiring to manually recompile NS.

But it looked like I didn't have any other options at this point as all my other tries resulted in the signed XPI not containing the right certificate chain. I could see the list of certificates present in the XPI by getting openssl and running:

openssl pkcs7 -print_certs -inform der -in zigbert.rsa

where "zigbert.rsa" is generated by the signing tool. That list is supposed to contain all the certificates in the signing chain except for the root CA (total of 3 in my case), and I couldn't force the signing tool to do that as it never included the G5 certificate thinking that it was root.

So I got the latest version of the source of NSS (3.12.8 at the time) from here and followed the instructions to remove the builtin CA, recompile everything, and install replacing the old binaries. The guide I used for compilation is here. I did all this on a Linux box as I didn't want to deal with Cygwin on Windows, but it should definitely be possible through Cygwin as well.

Sure enough, after getting NSS compiled with the removed root CA, I was able to successfully sign the XPI and it was trusted by Firefox out of the box. Since I needed to do all of my code signing on Windows, I also exported the certificate from the modified NSS database into a pfx file and just fed it to XPISigner, which worked perfectly now!

I hope that my findings will benefit other people out there with similar problems as I spent quite a bit of time on this problem. I would also recommend Mozilla to enable the code signing bit for the "VeriSign Class 3 Public Primary Certification Authority - G5" certificate by default to eliminate these problems. I assume if the certificate is used for code signing it should have that bit set! I think VeriSign have to actually submit the request for that though.

Posted Tue 16 November 2010 by Ivan Dyedov in Linux (Cryptography, XPI, code signing, verisign, Linux)


  • Avatar
    Mihai Danila 2012-06-13T07:56:43

    Strangely enough, after importing the intermediate version of G5 into the keystore, my signing starts working even with my old signtool. This must mean that my compiled signtool does not have G5 in it; a search for G5 in nssckbi.dll seems to confirm this (other cert names are listed in clear text in this file, but not G5).

    At least recompiling NSS was fun. :)

  • Avatar
    Mihai Danila 2012-06-13T07:53:04

    The problem is due indeed to the fact that I was using the self-signed version of the G5 certificate. After importing the one signed by the root authority instead (available at the URL linked in the second comment on this page), I was able to include it in the signature, and Firefox's "author not verified" issue went away.

    Thanks for the tip!

  • Avatar
    Mihai Danila 2012-06-13T07:14:19

    In my case, G5 seems to be self-signed. I wonder if that has something to do with it. It should be signed by VeriSign Class 3 Public Primary Certification Authority.

    Here's what I get:

    Version: 3 (0x2)
    Serial Number:
    Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
    Issuer: "CN=VeriSign Class 3 Public Primary Certification Authority -
    G5,OU="(c) 2006 VeriSign, Inc. - For authorized use only",OU=Ver
    iSign Trust Network,O="VeriSign, Inc.",C=US"
    Not Before: Wed Nov 08 00:00:00 2006
    Not After : Wed Jul 16 23:59:59 2036
    Subject: "CN=VeriSign Class 3 Public Primary Certification Authority
    - G5,OU="(c) 2006 VeriSign, Inc. - For authorized use only",OU=Ve
    riSign Trust Network,O="VeriSign, Inc.",C=US"
    Subject Public Key Info:
    Public Key Algorithm: PKCS #1 RSA Encryption
    RSA Public Key:
    Exponent: 65537 (0x10001)
    Signed Extensions:
    Name: Certificate Basic Constraints
    Critical: True
    Data: Is a CA with no maximum path length.

    Name: Certificate Key Usage
    Critical: True
    Usages: Certificate Signing
    CRL Signing

    Name: OID.
    Data: Sequence {
    [1]: {
    [0]: {
    Sequence {
    Sequence {
    Sequence {
    Sequence {
    Sequence {
    Sequence {
    Sequence {

    Name: Certificate Subject Key ID

    Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
    Fingerprint (MD5):
    Fingerprint (SHA1):

    Certificate Trust Flags:
    SSL Flags:
    Valid CA
    Email Flags:
    Valid CA
    Object Signing Flags:
    Valid CA

  • Avatar
    Mihai Danila 2012-06-13T06:28:56

    I recompiled NSS (make clean, rd /s /q mozilla dist, make nss_build_all) after stripping the G5 certificate from the relevant text file. I manually imported G5 into the store, and my signing still doesn't include it. I tried with trust flags C,C,C and c,c,c (other flags don't seem to stick), using certutil -M.

    Any ideas? Perhaps I'm not really issuing a clean make here?

    Certificate Nickname Trust Attributes

    my_cert u,u,u
    VeriSign Class 3 Code Signing 2010 CA C,C,C
    VeriSign Class 3 Public Primary Certification Authority - G5 c,c,c

  • Avatar
    Khachatur 2012-05-03T23:15:36

    I'm having this same issue with signing my xpi with verisign Code signing certificate. After spending a week I finally got from another company and it worked.

  • Avatar
    Tim 2012-01-12T21:57:48

    Thanks for the article. I'm running into this exact problem. The odd part is for me it works fine on 8+, just not version 3.6.

    • Avatar
      Ivan Dyedov 2012-02-23T07:38:47

      They may have finally added the intermediate verisign certificate to Firefox in the latest versions.

  • Avatar
    Idan 2011-06-13T11:13:13

    You can obtain the intermediate certificates here:

    see also:

  • Avatar
    Ivan Dyedov 2010-12-07T09:09:46

    seems like LogMeIn is having similar issues with their VeriSign certificate as I received the same error trying to install their FireFox XPI. I had to enable the "identify software makers" bit for "Verisign Class 3 Public Primary Certification Authority" to get it to work