Signing XPI
Adriano Bonat
I'm trying to sign a Firefox extension (XPI) using a code signing
certificate bought from GoDaddy, but Firefox is rejecting the XPI file
saying "signing could not be verified. -260".
I already tried to sign the XPI using a certificate issued by GoDaddy,
and with another issued by Starfield.
Here are the steps that I'm following to sign the file:
1. Tried to install the GoDaddy/Starfield intermediate certificate but
browser says that it is already installed;
2. I install the code signing certificate, it shows OK in the "Your
certificates" tab in Firefox' preferences;
3. I'm using Mac OS X 10.6.1, and installed package "nss" from
MacPorts, so using nss-certutil on my Firefox 3.5 profile dir:
$ nss-certutil -d . -L
Certificate Nickname Trust
Attributes
SSL,S/
MIME,JAR/XPI
VeriSign Class 3 Extended Validation SSL CA ,,
Thawte SGC CA ,,
UTN-USERFirst-Hardware ,,
VeriSign Class 3 Secure Server CA - G2 ,,
Akamai Subordinate CA 3 ,,
Entrust Certification Authority - L1B ,,
Google Internet Authority ,,
VeriSign Class 3 Secure Server CA ,,
PositiveSSL CA ,,
Go Daddy Secure Certification Authority ,,
DigiCert Global CA ,,
COMPANYNAME LLC's Starfield Technologies, Inc. ID u,u,u
GlobalSign Extended Validation CA ,,
VeriSign Class 3 Extended Validation SSL SGC CA ,,
VeriSign, Inc. ,,
Microsoft Internet Authority ,,
Starfield Secure Certification Authority ,,
RSA Public Root CA v1 ,,
Sun Microsystems Inc SSL CA ,,
DigiCert High Assurance EV CA-1 ,,
GlobalSign ,,
UTN - DATACorp SGC ,,
Microsoft Secure Server Authority ,,
UniCERT Certificadora ,,
Why all certificates (except the one that I installed) don't have
trust attributes? This lead me to a problem when signing the file:
$ nss-signtool -d . -l
Object signing certificates
---------------------------------------
COMPANYNAME LLC's Starfield Technologies, Inc. ID
Issued by: Starfield Secure Certification Authority
Expires: Mon Sep 19, 2011
++ Error ++ THIS CERTIFICATE IS NOT VALID (Certificate Authority
certificate invalid)
---------------------------------------
For a list including CA's, use "signtool -L"
To get the file signed, I'm "cheating" and changing the trust
attributes of the GoDaddy/Starfield Secure Certification Authority to
",,C".
Anybody has an idea what is the problem here?
Thanks.
- Adriano Bonat
Nelson B Bolyard
> Hi guys,
>
> I'm trying to sign a Firefox extension (XPI) using a code signing
> certificate bought from GoDaddy, but Firefox is rejecting the XPI file
> saying "signing could not be verified. -260".
It said -260? That's not an NSS or NSPR error number.
> Here are the steps that I'm following to sign the file:
> 1. Tried to install the GoDaddy/Starfield intermediate certificate but
> browser says that it is already installed;
> 2. I install the code signing certificate, it shows OK in the "Your
> certificates" tab in Firefox' preferences;
> 3. I'm using Mac OS X 10.6.1, and installed package "nss" from
> MacPorts, so using nss-certutil on my Firefox 3.5 profile dir:
What is the version of NSS that you got from MacPorts?
Is it 3.11.4? 3.12.0 ? 3.12.3 ? Other?
> $ nss-certutil -d . -L
Try it again with an additional parameter, which is -h all
You'll get about 150 more lines of output, with a lot more trust flags,
I expect.
> Certificate Nickname Trust Attributes
> SSL,S/MIME,JAR/XPI
Because they're almost all intermediate CA certificates, not root CA
certificates, or they _should_ be. As a general rule, trust flags are
only put on roots, not on intermediates. however, there are some exceptions.
> $ nss-signtool -d . -l
>
> Object signing certificates
> ---------------------------------------
> COMPANYNAME LLC's Starfield Technologies, Inc. ID
> Issued by: Starfield Secure Certification Authority
> Expires: Mon Sep 19, 2011
> ++ Error ++ THIS CERTIFICATE IS NOT VALID (Certificate Authority
> certificate invalid)
> ---------------------------------------
> For a list including CA's, use "signtool -L"
This is why I asked what version of NSS you're using. There were some
gross bugs in signtool versions before 3.12.3
>
> To get the file signed, I'm "cheating" and changing the trust
> attributes of the GoDaddy/Starfield Secure Certification Authority to
> ",,C".
Try ",,c", that's lower case c, instead.
And don't be so sure that's cheating. :)
> Anybody has an idea what is the problem here?
Finally, what command line options are you using in your signing attempt?
You will want both -X and -Z to make a signed XPI file.
> Thanks.
> - Adriano Bonat
/Nelson
Adriano Bonat
On Sep 25, 2:53 am, Nelson B Bolyard <nel...@bolyard.me> wrote:
> On 2009-09-24 21:07 PDT, Adriano Bonat wrote:
>
> > Hi guys,
>
> > I'm trying to sign a Firefox extension (XPI) using a code signing
> > certificate bought from GoDaddy, but Firefox is rejecting the XPI file
> > saying "signing could not be verified. -260".
>
> It said -260? That's not an NSS or NSPR error number.
Understand, here is a screenshot: http://img201.yfrog.com/i/screenshot20090923at115.png/
> > Here are the steps that I'm following to sign the file:
> > 1. Tried to install the GoDaddy/Starfield intermediate certificate but
> > browser says that it is already installed;
> > 2. I install the code signing certificate, it shows OK in the "Your
> > certificates" tab in Firefox' preferences;
> > 3. I'm using Mac OS X 10.6.1, and installed package "nss" from
> > MacPorts, so using nss-certutil on my Firefox 3.5 profile dir:
>
> What is the version of NSS that you got from MacPorts?
> Is it 3.11.4? 3.12.0 ? 3.12.3 ? Other?
$ port info nss
nss @3.12.3 (net)
> > $ nss-certutil -d . -L
>
> Try it again with an additional parameter, which is -h all
> You'll get about 150 more lines of output, with a lot more trust flags,
> I expect.
>
$ nss-certutil -d . -L -h all
this gave me the same result as without it.
BUT, I tried it on a Ubuntu machine with Signing Tool 3.12.3.1, and
then it lists also the builtin modules...
Later I was checking other things, and I found the following:
$ nss-modutil -dbdir . -list
Listing of PKCS #11 Modules
-----------------------------------------------------------
1. NSS Internal PKCS #11 Module
slots: 2 slots attached
status: loaded
slot: NSS Internal Cryptographic Services
token: NSS Generic Crypto Services
slot: NSS User Private Key and Certificate Services
token: NSS Certificate DB
-----------------------------------------------------------
Isn't missing here the "Mozilla Root Certs" that points to
"libnssckbi.so" ? I found this information here:
http://article.gmane.org/gmane.comp.mozilla.crypto/11137
Testing on the Ubuntu machine confirmed this, there the "Root certs"
are pointing to that library, so thats where the builtin certificates
came from.
I see, but I find it strange, on the manual page when they list the
certificates they all have trust attributes:
http://www.mozilla.org/projects/security/pki/nss/tools/certutil.html
> > $ nss-signtool -d . -l
>
> > Object signing certificates
> > ---------------------------------------
> > COMPANYNAME LLC's Starfield Technologies, Inc. ID
> > Issued by: Starfield Secure Certification Authority
> > Expires: Mon Sep 19, 2011
> > ++ Error ++ THIS CERTIFICATE IS NOT VALID (Certificate Authority
> > certificate invalid)
> > ---------------------------------------
> > For a list including CA's, use "signtool -L"
>
> This is why I asked what version of NSS you're using. There were some
> gross bugs in signtool versions before 3.12.3
>
Maybe they are still there? :)
>
> > To get the file signed, I'm "cheating" and changing the trust
> > attributes of the GoDaddy/Starfield Secure Certification Authority to
> > ",,C".
>
> Try ",,c", that's lower case c, instead.
> And don't be so sure that's cheating. :)
>
> > Anybody has an idea what is the problem here?
>
> Finally, what command line options are you using in your signing attempt?
> You will want both -X and -Z to make a signed XPI file.
I'm using:
$ nss-signtool -d . -k "COMPANYNAME LLC's Starfield Technologies, Inc.
ID" -X -Z file.xpi XPI/
Thanks again.
-Adriano Bonat
Adriano Bonat
the root and intermediate certificates from Starfield (...), but no
success yet, Firefox still says "signing could not be verified. -260".
Here are the steps that I followed:
adriano@planck:~/Tmp$ mkdir empty_db
adriano@planck:~/Tmp$ cd empty_db/
adriano@planck:~/Tmp/empty_db$ nss-certutil -N -d .
Enter a password which will be used to encrypt your keys.
The password should be at least 8 characters long,
and should contain at least one non-alphabetic character.
Enter new password:
Re-enter password:
adriano@planck:~/Tmp/empty_db$ ls
cert8.db key3.db secmod.db
adriano@planck:~/Tmp/empty_db$ nss-certutil -A -n "Starfield Class 2
Root" -i ~/Downloads/sf-class2-root.crt -d . -t "CT,CT,CT"
adriano@planck:~/Tmp/empty_db$ nss-certutil -A -n "Starfield
intermediate" -i ~/Downloads/sf_intermediate.crt -d . -t ",,c"
adriano@planck:~/Tmp/empty_db$ nss-certutil -d . -L
Certificate Nickname Trust
Attributes
SSL,S/
MIME,JAR/XPI
Starfield Class 2 Root CT,C,C
Starfield intermediate ,,c
adriano@planck:~/Tmp/empty_db$
adriano@planck:~/Tmp/empty_db$ nss-pk12util -i ~/Downloads/
COMPANY_code_signing_starfield.p12 -d .
Enter Password or Pin for "NSS Certificate DB":
Enter password for PKCS12 file:
nss-pk12util: PKCS12 IMPORT SUCCESSFUL
adriano@planck:~/Tmp/empty_db$
adriano@planck:~/Tmp/empty_db$ nss-certutil -d . -L
Certificate Nickname Trust
Attributes
SSL,S/
MIME,JAR/XPI
Starfield Class 2 Root CT,C,C
COMPANY LLC's Starfield Technologies, Inc. ID u,u,u
Starfield intermediate ,,c
adriano@planck:~/Tmp/empty_db$
adriano@planck:~/Tmp/empty_db$
adriano@planck:~/Tmp/empty_db$ nss-signtool -d . -l
Object signing certificates
---------------------------------------
COMPANY LLC's Starfield Technologies, Inc. ID
Issued by: Starfield intermediate
Expires: Mon Sep 19, 2011
---------------------------------------
For a list including CA's, use "signtool -L"
adriano@planck:~/Tmp/empty_db$
adriano@planck:~/Tmp/empty_db$ nss-certutil -V -n "COMPANY LLC's
Starfield Technologies, Inc. ID" -u O -d .
nss-certutil: certificate is invalid: Certificate type not approved
for application.
adriano@planck:~/Tmp/empty_db$
adriano@planck:~/Tmp/empty_db$ nss-certutil -O -n "COMPANY LLC's
Starfield Technologies, Inc. ID" -d .
"Starfield Class 2 Root" [OU=Starfield Class 2 Certification
Authority,O="Starfield Technologies, Inc.",C=US]
"Starfield intermediate" [serialNumber=10688435,CN=Starfield Secure
Certification Authority,OU=http://certificates.starfieldtech.com/
repository,O="Starfield Technologies,
Inc.",L=Scottsdale,ST=Arizona,C=US]
"COMPANY LLC's Starfield Technologies, Inc. ID" [CN=COMPANY
LLC,O=COMPANY LLC,L=Remsenburg,ST=NY,C=US]
adriano@planck:~/Tmp/empty_db$
adriano@planck:~/Tmp/empty_db$ mkdir XPI
adriano@planck:~/Tmp/empty_db$ unzip -d XPI ~/COMPANY.xpi
adriano@planck:~/Tmp/empty_db$ nss-signtool -d . -k "COMPANY LLC's
Starfield Technologies, Inc. ID" -X -Z COMPANY.xpi XPI
Generating XPI/META-INF/manifest.mf file..
[snip...]
Generating zigbert.sf file..
Enter Password or Pin for "NSS Certificate DB":
Creating XPI Compatible Archive
adding XPI/META-INF/zigbert.rsa to COMPANY.xpi...(deflated 34%)
[snip...]
Am I doing something wrong?
Thanks.
Adriano Bonat
https://certs.starfieldtech.com/anonymous/repository.seam
Kaspar Brand
> adriano@planck:~/Tmp/empty_db$ nss-signtool -d . -l
>
> Object signing certificates
> ---------------------------------------
> COMPANY LLC's Starfield Technologies, Inc. ID
> Issued by: Starfield intermediate
> Expires: Mon Sep 19, 2011
> ---------------------------------------
This looks good, actually - the trust settings in this (newly created)
cert DB meet signtool's expectations.
> adriano@planck:~/Tmp/empty_db$ nss-certutil -V -n "COMPANY LLC's
> Starfield Technologies, Inc. ID" -u O -d .
> nss-certutil: certificate is invalid: Certificate type not approved
> for application.
You should use "-u J" when verifying an object signing cert ("O" is for
OCSP status responder), so this error message is just a red herring.
> Am I doing something wrong?
I don't think so, but it's quite possible that you're running into the
issue reported in
https://bugzilla.mozilla.org/show_bug.cgi?id=321156
because the intermediate CA cert (available from
http://certificates.starfieldtech.com/repository/sf_intermediate.crt)
does not have an EKU nor a netscape-cert-type extension.
When you list the certificates in your Firefox DB with certutil (make
sure you're shutting down Firefox first), I assume that the line with
"Starfield Secure Certification Authority" does not show ",,c", is that
correct?
Kaspar
Adriano Bonat
On Sep 25, 3:07 pm, Kaspar Brand <m...@velox.ch> wrote:
> Adriano Bonat wrote:
> > adriano@planck:~/Tmp/empty_db$ nss-signtool -d . -l
>
> > Object signing certificates
> > ---------------------------------------
> > COMPANY LLC's Starfield Technologies, Inc. ID
> > Issued by: Starfield intermediate
> > Expires: Mon Sep 19, 2011
> > ---------------------------------------
>
> This looks good, actually - the trust settings in this (newly created)
> cert DB meet signtool's expectations.
>
> > adriano@planck:~/Tmp/empty_db$ nss-certutil -V -n "COMPANY LLC's
> > Starfield Technologies, Inc. ID" -u O -d .
> > nss-certutil: certificate is invalid: Certificate type not approved
> > for application.
>
> You should use "-u J" when verifying an object signing cert ("O" is for
> OCSP status responder), so this error message is just a red herring.
uh... my mistake, thanks for pointing it :)
> > Am I doing something wrong?
>
> I don't think so, but it's quite possible that you're running into the
> issue reported in
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=321156
>
> because the intermediate CA cert (available fromhttp://certificates.starfieldtech.com/repository/sf_intermediate.crt)
> does not have an EKU nor a netscape-cert-type extension.
I understand, do you think that GoDaddy can do something about that?
In case no, if I want to sign my extension I will have to buy a code
signing certificate from another company like Verisign and Thawte, any
cheaper one that simply works?
> When you list the certificates in your Firefox DB with certutil (make
> sure you're shutting down Firefox first), I assume that the line with
> "Starfield Secure Certification Authority" does not show ",,c", is that
> correct?
Yes, that's correct. I did set the value ",,c" using certutil.
Thanks again.
-Adriano Bonat
Nelson Bolyard
> $ nss-certutil -d . -L -h all
>
> this gave me the same result as without it.
This is because you libnssckbi.so is not being loaded, as you have
already noted. Let's fix that.
> BUT, I tried it on a Ubuntu machine with Signing Tool 3.12.3.1, and
> then it lists also the builtin modules...
So, there's some difference between those machines. Did the MacPort
include nssckbi?
> Later I was checking other things, and I found the following:
>
> $ nss-modutil -dbdir . -list
>
> Listing of PKCS #11 Modules
> -----------------------------------------------------------
> 1. NSS Internal PKCS #11 Module
> slots: 2 slots attached
> status: loaded
>
> slot: NSS Internal Cryptographic Services
> token: NSS Generic Crypto Services
>
> slot: NSS User Private Key and Certificate Services
> token: NSS Certificate DB
> -----------------------------------------------------------
>
>
> Isn't missing here the "Mozilla Root Certs" that points to
> "libnssckbi.so" ?
Yes, exactly. Do you have such a lib among the NSS libs from the MacPort?
If so, copy it into the "." directory (the directory specified as the
argument to the -d option of signtool, or the -dbdir option of modutil)
and then repeat your efforts. PSM (part of Firefox) does some of this
magic for you.
> I found this information here:
> http://article.gmane.org/gmane.comp.mozilla.crypto/11137
>
> Testing on the Ubuntu machine confirmed this, there the "Root certs"
> are pointing to that library, so thats where the builtin certificates
> came from.
yes.
>>> Why all certificates (except the one that I installed) don't have
>>> trust attributes? This lead me to a problem when signing the file:
>>
>> Because they're almost all intermediate CA certificates, not root CA
>> certificates, or they _should_ be. As a general rule, trust flags are
>> only put on roots, not on intermediates. however, there are some
>> exceptions.
>
> I see, but I find it strange, on the manual page when they list the
> certificates they all have trust attributes:
> http://www.mozilla.org/projects/security/pki/nss/tools/certutil.html
Yes, there was formerly a bug in the browser that routinely set certain
trust flags on all certs that were manually imported by a user. I think
that's fixed now (not 100% positive though). The old examples reflect
that old bug.
>>> $ nss-signtool -d . -l
>>
>>> Object signing certificates
>>> ---------------------------------------
>>> COMPANYNAME LLC's Starfield Technologies, Inc. ID
>>> Issued by: Starfield Secure Certification Authority
>>> Expires: Mon Sep 19, 2011
>>> ++ Error ++ THIS CERTIFICATE IS NOT VALID (Certificate Authority
>>> certificate invalid)
>>> ---------------------------------------
>>> For a list including CA's, use "signtool -L"
>>
>> This is why I asked what version of NSS you're using. There were some
>> gross bugs in signtool versions before 3.12.3
>>
>
> Maybe they are still there? :)
Let's see if that persists after you get nssckbi in place.
> Thanks again.
> -Adriano Bonat
Adriano Bonat
Did you see the message from Kaspar? I guess he is right and I'm
another victim of that "bug", so there is nothing I can do to fix it :
(
Thanks again.
-Adriano Bonat
Nelson B Bolyard
> Hi Nelson,
>
> Did you see the message from Kaspar? I guess he is right and I'm
> another victim of that "bug", so there is nothing I can do to fix it
Adriano,
The ",,c" clue I gave you works around that bug in NSS 3.12.3+.
But let's look at the bigger picture here.
Why are you trying to sign your XPI?
Does signing your XPI help you in any way?
There was a time, years ago, when a signed XPI could get certain
execution privileges that an unsigned XPI could not get.
But I believe the Mozilla browser people put an end to that long ago.
Today, as far as I know, signed XPIs get no special privileges.
I honestly know of no particularly good incentive for XPI writers to
sign their XPIs at this time. As far as I know, the only benefit that
a signed XPI gets, over an unsigned XPI, is that in one particular
dialogue, the word "unsigned" does not appear when the XPI is signed
and does appear when it is not signed. But most users click through
that dialog so fast that they never even notice it.
And, as you've probably discovered, if you DO sign your XPI and the
browser has trouble with the signature, then it will not load the XPI,
which is a pain for both users and developers. So, users get no sense
of added security value from signatures (because the browser does not
bestow any value on them), and both users and developers see signatures
as a cause of extra grief. Note that this is not inherent in the
technology of signed code. It's just the result of an attitude towards
certificates and CAs held by a certain segment of Mozilla's developers.
Now, tell me again why you want to sign your XPI?
Eddy Nigg
> Now, tell me again why you want to sign your XPI?
>
Nelson, I'm highly surprised about your comments here - completly
unacceptable and not helpful. Instead of getting signing addons done
correctly on all levels which should be welcomed, you are actually
discouraging this user from properly signing his program? Sorry, but I
didn't expected that from somebody like yourself.
:-(
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Adriano Bonat
> On 2009-09-26 12:52 PDT, Adriano Bonat wrote:
>
> > Hi Nelson,
>
> > Did you see the message from Kaspar? I guess he is right and I'm
> > another victim of that "bug", so there is nothing I can do to fix it
>
> Adriano,
> The ",,c" clue I gave you works around that bug in NSS 3.12.3+.
I don't think so, because the problem is when the browser verifies the
file, it's not signtool's fault.
> But let's look at the bigger picture here.
> Why are you trying to sign your XPI?
> Does signing your XPI help you in any way?
There are some reasons:
1. My client asks for that;
2. We get rid of the "Author not verified" that appears in the install
XPI popup for some secs;
3. It garantees that the software was released by us, and that others
didn't tampered it.
Here is a blog post that explains it a little more from another
extension developer:
http://adblockplus.org/blog/trying-to-get-rid-of-author-not-verified-or-signing-extensions-with-sitecom-certificate
> There was a time, years ago, when a signed XPI could get certain
> execution privileges that an unsigned XPI could not get.
> But I believe the Mozilla browser people put an end to that long ago.
> Today, as far as I know, signed XPIs get no special privileges.
>
> I honestly know of no particularly good incentive for XPI writers to
> sign their XPIs at this time. As far as I know, the only benefit that
> a signed XPI gets, over an unsigned XPI, is that in one particular
> dialogue, the word "unsigned" does not appear when the XPI is signed
> and does appear when it is not signed. But most users click through
> that dialog so fast that they never even notice it.
>
> And, as you've probably discovered, if you DO sign your XPI and the
> browser has trouble with the signature, then it will not load the XPI,
> which is a pain for both users and developers. So, users get no sense
> of added security value from signatures (because the browser does not
> bestow any value on them), and both users and developers see signatures
> as a cause of extra grief. Note that this is not inherent in the
> technology of signed code. It's just the result of an attitude towards
> certificates and CAs held by a certain segment of Mozilla's developers.
>
> Now, tell me again why you want to sign your XPI?
I guess you already understood my reasons and I also see your point,
somebody can enter Google's servers and touch their code and release a
signed version of their software, but the signing tells us that the
software came from that company, and we just hope that they do their
homework well.
Sorry, that's too much philosophical, I just wanted those bugs fixed,
my extension signed and my client happy. Am I asking too much? :)
Best regards.
-Adriano Bonat