i try ti sign a firefox xpi package.
As i already have a Windows Authenticode SSL certificate / key, i follow
steps describe here :
http://oy-oy.eu/huh/firefox-extension-code-signed-with-spc-pvk/
So i have created a certificate database with certutil.exe, then i import my
windows certificate with pk12util. Import was successful.
when i check for importation in the certificate database, i can see
something like this :
7a7c125c-dcc0-4461-ace9-ed26662444f2 u,u,u
Thawte Code Signing CA - Thawte Consulting cc c,,c
thawte
c,c,
How can i rename this "7a7c125c-dcc0-4461-ace9-ed26662444f2" ??
Finally i use signtool to sign my package :
signtool -d "DB" -K -k "7a7c125c-dcc0-4461-ace9-ed26662444f2" -p
"PASSWORD" -X -Z "PACKAGE.XPI" Dir\
As output, i have :
using certificate directory: DB
Generating Addin\/META-INF/manifest.mf file..
--> [...]
Generating zigbert.sf file..
signtool: PROBLEM signing data (Issuer certificate is invalid)
the tree "Dir\" was NOT SUCCESSFULLY SIGNED
and zigbert.rsa file size = 0
Why ?? What's wrong ???
That is the nickname given to the certificate by Windows while it was
on the Windows system, before you exported it to a pfx (PKCS#12) file.
To change the name, you must change the nickname on the Windows system,
and then export it again to a PKCS#12 file, and then re-import the
PKCS#12 file into an NSS cert DB. On Windows, the "nickname" is known
as the "Friendly Name".
To change the Friendly name, open Windows' Certificate Manager program.
(Right click in the IE icon on your desktop, and click on "Properties".
Select the "Content" tab. Click the Certificates button.) In Cert Manager,
select the "Personal" tab, select the certificate, click the "View" button,
which opens the Certificate Dialog. In that dialog, select the
"Details" tab, click the "Edit Properties" button, which opens the
Certificate Properties Dialog. Select the "General" tab in that dialog,
and enter a Friendly name. The Friendly name should contain only ASCII
characters (no character with Umlauts, Graves, etc.) and must not contain
a colon ":" character. Then Click OK. Back in the Certificate Dialog,
click the "Copy to File" button to start the certificate export wizard.
Then re-export the cert to a PFX file. You'll need to import that PFX
file into NSS's cert DB again, but first you'll need to delete the cert
you previously imported into that DB from that DB. Your best bet is to
start fresh with a new set of cert & key DBs.
> Finally i use signtool to sign my package :
> signtool -d "DB" -K -k "7a7c125c-dcc0-4461-ace9-ed26662444f2" -p
> "PASSWORD" -X -Z "PACKAGE.XPI" Dir\
>
> As output, i have :
>
> using certificate directory: DB
> Generating Addin\/META-INF/manifest.mf file..
> --> [...]
> Generating zigbert.sf file..
> signtool: PROBLEM signing data (Issuer certificate is invalid)
>
> the tree "Dir\" was NOT SUCCESSFULLY SIGNED
>
> and zigbert.rsa file size = 0
>
> Why ?? What's wrong ???
That string, "Issuer certificate is invalid", is NSS error code
SEC_ERROR_CA_CERT_INVALID. It tells you that NSS thinks that the
CA cert for the issuer that issued your code signing cert is not a
valid object signing CA cert at all, e.g. it lacks the extensions
necessary to mark it as a valid object signing CA cert.
You can work around that by setting an override flag in the cert DB,
telling NSS to override that error for that CA cert. However, if
you have to do that, odds are good that whatever software will later
check that signature will also find the same problem.
To override the error, you first must find the nickname of the CA
cert, then modify its trust flags with certutil using a command line
this one:
certutil -d <DBDIR> -n "<nickname>" -M -t ",,c"
(Note, that's a lower case "c".)
It may be necessary to do this for each CA cert in the chain, except
the root CA cert, which should already have a capital "C" trust flag set.
/Nelson
So this error code means it lacks me extentions to mark my certificate as a
valid object signing.
How and where can i found this missing extentions ?
from the sample i have followed :
http://oy-oy.eu:80/huh/firefox-extension-code-signed-with-spc-pvk/
There was differences after i have imported my certificate in my DB
here is the content of my DB :
------------------------------------------------------------------
6a6d3dd2-2a57-42fc-8379-6400fab101bd u,u,u
Thawte Code Signing CA - Thawte Consulting cc c,,c
thawte
c,c,
------------------------------------------------------------------
here is the result of its importation :
-------------------------------------------------------------------
Comodo AAA CS CT,C,C
Comodo SCS c,c,C
Comodo TCS c,c,C
79f01492-e71a-2ce3-ae1b-3ccc4abc5def u,u,u
myTestCert
u,u,Cu
-------------------------------------------------------------------
For me, Thawte have these attributes "c,,c" and "c,c,"
for him, Comodo have these attributes "CT,C,C", "c,c,C", "c,c,C"
What these attributes means ??
Why there are these differences for certificate attributes after importation
?
> You can work around that by setting an override flag in the cert DB,
> telling NSS to override that error for that CA cert. However, if
> you have to do that, odds are good that whatever software will later
> check that signature will also find the same problem.
>
> To override the error, you first must find the nickname of the CA
> cert, then modify its trust flags with certutil using a command line
> this one:
> certutil -d <DBDIR> -n "<nickname>" -M -t ",,c"
> (Note, that's a lower case "c".)
>
> It may be necessary to do this for each CA cert in the chain, except
> the root CA cert, which should already have a capital "C" trust flag set.
you say me this :
"except the root CA cert, which should already have a capital "C" trust flag
set."
So, why my root CA ( "thawte" in my case ) don't have "C" trust flag set ???
what's wrong about it ?
thanks.
>> That string, "Issuer certificate is invalid", is NSS error code
>> SEC_ERROR_CA_CERT_INVALID. It tells you that NSS thinks that the
>> CA cert for the issuer that issued your code signing cert is not a
>> valid object signing CA cert at all, e.g. it lacks the extensions
>> necessary to mark it as a valid object signing CA cert.
>
> So this error code means it lacks me extentions to mark my certificate as a
> valid object signing.
The problem is not with your certificate, but with the certificate of the
CA that issued your certificate.
> How and where can i found this missing extentions ?
You cannot get the CA to add the extensions to their certificate.
> from the sample i have followed :
> http://oy-oy.eu:80/huh/firefox-extension-code-signed-with-spc-pvk/
> There was differences after i have imported my certificate in my DB
[snip]
> For me, Thawte have these attributes "c,,c" and "c,c,"
> for him, Comodo have these attributes "CT,C,C", "c,c,C", "c,c,C"
> What these attributes means ??
> Why there are these differences for certificate attributes after importation
> ?
Many "how to" documents for NSS tools have been written and published on
the web. several of them contain errors. Consequently, the NSS team does
not support any documentation except the docs on *.mozilla.org and
perhaps on sun.com and redhat.com (where many of the NSS developers are
employed). So, if you're getting unexpected results from following the
example on a particular web page, you must ask the author of that page
for support.
> you say me this :
> "except the root CA cert, which should already have a capital "C" trust flag
> set."
>
> So, why my root CA ( "thawte" in my case ) don't have "C" trust flag set ???
> what's wrong about it ?
Is it really a root CA?
Or is it subordinate to another one of Thawte's root CA certs?
/Nelson
signtool sign successfully my package, but when attempting to install it,
the error message : "The signature used in the XPI is not valid -260"
appears.
I don't understand why signing my package whith the same database than
firefox doesn't work and produces this error ?
thanks for your help.
Is that an exact copy of what was displayed on your screen?
I searched the entire mozilla source repository for strings like these:
"The signature used in the XPI is not valid"
"signature used in the XPI"
"the XPI is not valid"
and found nothing.
> I don't understand why signing my package whith the same database than
> firefox doesn't work and produces this error ?
My guess: the certificate is not issued by a trusted issuer.
The rules for signing are less restrictive than the rules for verifying
a signature. You can sign something with a cert from an untrusted
issuer, but you cannot verify a signature with a cert from an untrusted
issuer.
--
Nelson B
On my screen the message is in french,
"Firefox n'as pas pu installer le fichier situé à
file:///D:/sources/Signing%20Tools/NSS%20Tools/Addin/AgentAddinFirefox.xpi
raison : La signature n'a pas pu être vérifiée
-260"
i traduct it approximatively like that :
"Firefox can't install file
file:///D:/sources/Signing%20Tools/NSS%20Tools/Addin/AgentAddinFirefox.xpi
cause : The signature used can't be verified
-260"
I've followed a lot of tutorials with no effect, and i've already the same
message.
> I searched the entire mozilla source repository for strings like these:
> "The signature used in the XPI is not valid"
> "signature used in the XPI"
> "the XPI is not valid"
> and found nothing.
>
>> I don't understand why signing my package whith the same database than
>> firefox doesn't work and produces this error ?
>
> My guess: the certificate is not issued by a trusted issuer.
> The rules for signing are less restrictive than the rules for verifying
> a signature. You can sign something with a cert from an untrusted
> issuer, but you cannot verify a signature with a cert from an untrusted
> issuer.
my certificate come from Thawtee, it is a trusted certificate whitch work
perfectfully as signer object with internet explorer.
here the tutorials, i've followed :
http://www.mercille.org/snippets/xpiSigning.php
here the command i launch and the results :
---------------------------------------------------------------------------------------
D:\sources\Signing Tools\NSS Tools>certutil -L -d CA
Thawte Code Signing CA - Thawte Consulting cc c,c,C
Thawte Server CA CTG,c,C
Thawte Test CA Root - Thawte Certification CT,C,C
thawte Primary Root CA - Thawte Consulting cc CT,C,C
thawte Primary Root CA - Thawte Consulting cc CT,C,C
Thawte SSL Domain CA - Thawte Consulting cc CT,C,C
thawte Extended Validation SSL CA - thawte, Inc. CT,C,C
0d7de953-f681-4250-bece-f7cabfd288c8 u,u,u
Thawte Premium Server CA G,,
Thawte SGC CA - VeriSign, Inc. CT,C,C
---------------------------------------------------------------------------------------
D:\sources\Signing Tools\NSS Tools>signtool -d CA -L
using certificate directory: CA
S Certificates
- ------------
Thawte Code Signing CA - Thawte Consulting cc
Builtin Object Token:Thawte Server CA
Thawte Test CA Root - Thawte Certification
thawte Primary Root CA - Thawte Consulting cc
thawte Primary Root CA - Thawte Consulting cc
Thawte SSL Domain CA - Thawte Consulting cc
thawte Extended Validation SSL CA - thawte, Inc.
* 0d7de953-f681-4250-bece-f7cabfd288c8
Builtin Object Token:Thawte Premium Server CA
Thawte SGC CA - VeriSign, Inc.
Builtin Object Token:Verisign/RSA Secure Server CA
Builtin Object Token:GTE CyberTrust Root CA
Builtin Object Token:GTE CyberTrust Global Root
Builtin Object Token:Thawte Personal Basic CA
Builtin Object Token:Thawte Personal Premium CA
Builtin Object Token:Thawte Personal Freemail CA
Builtin Object Token:Equifax Secure CA
Builtin Object Token:ABAecom (sub., Am. Bankers Assn.) Root CA
Builtin Object Token:Digital Signature Trust Co. Global CA 1
Builtin Object Token:Digital Signature Trust Co. Global CA 3
Builtin Object Token:Digital Signature Trust Co. Global CA 2
Builtin Object Token:Digital Signature Trust Co. Global CA 4
Builtin Object Token:Verisign Class 1 Public Primary Certification
Authority
Builtin Object Token:Verisign Class 2 Public Primary Certification
Authority
Builtin Object Token:Verisign Class 3 Public Primary Certification
Authority
Builtin Object Token:Verisign Class 1 Public Primary Certification
Authority -
G2
Builtin Object Token:Verisign Class 2 Public Primary Certification
Authority -
G2
Builtin Object Token:Verisign Class 3 Public Primary Certification
Authority -
G2
Builtin Object Token:Verisign Class 4 Public Primary Certification
Authority -
G2
Builtin Object Token:GlobalSign Root CA
Builtin Object Token:ValiCert Class 1 VA
Builtin Object Token:ValiCert Class 2 VA
Builtin Object Token:RSA Root Certificate 1
Builtin Object Token:Verisign Class 1 Public Primary Certification
Authority -
G3
Builtin Object Token:Verisign Class 2 Public Primary Certification
Authority -
G3
Builtin Object Token:Verisign Class 3 Public Primary Certification
Authority -
G3
Builtin Object Token:Verisign Class 4 Public Primary Certification
Authority -
G3
Builtin Object Token:Entrust.net Secure Server CA
Builtin Object Token:Entrust.net Secure Personal CA
Builtin Object Token:Entrust.net Premium 2048 Secure Server CA
Builtin Object Token:Baltimore CyberTrust Root
Builtin Object Token:Equifax Secure Global eBusiness CA
Builtin Object Token:Equifax Secure eBusiness CA 1
Builtin Object Token:Equifax Secure eBusiness CA 2
Builtin Object Token:Visa International Global Root 2
Builtin Object Token:beTRUSTed Root CA
Builtin Object Token:AddTrust Low-Value Services Root
Builtin Object Token:AddTrust External Root
Builtin Object Token:AddTrust Public Services Root
Builtin Object Token:AddTrust Qualified Certificates Root
Builtin Object Token:Verisign Class 1 Public Primary OCSP Responder
Builtin Object Token:Verisign Class 2 Public Primary OCSP Responder
Builtin Object Token:Verisign Class 3 Public Primary OCSP Responder
Builtin Object Token:Verisign Secure Server OCSP Responder
Builtin Object Token:Verisign Time Stamping Authority CA
Builtin Object Token:Thawte Time Stamping CA
Builtin Object Token:Entrust.net Global Secure Server CA
Builtin Object Token:Entrust.net Global Secure Personal CA
Builtin Object Token:AOL Time Warner Root Certification Authority 1
Builtin Object Token:AOL Time Warner Root Certification Authority 2
Builtin Object Token:beTRUSTed Root CA-Baltimore Implementation
Builtin Object Token:beTRUSTed Root CA - Entrust Implementation
Builtin Object Token:beTRUSTed Root CA - RSA Implementation
Builtin Object Token:RSA Security 2048 v3
Builtin Object Token:RSA Security 1024 v3
Builtin Object Token:GeoTrust Global CA
Builtin Object Token:GeoTrust Global CA 2
Builtin Object Token:GeoTrust Universal CA
Builtin Object Token:GeoTrust Universal CA 2
Builtin Object Token:UTN-USER First-Network Applications
Builtin Object Token:America Online Root Certification Authority 1
Builtin Object Token:America Online Root Certification Authority 2
Builtin Object Token:Visa eCommerce Root
Builtin Object Token:TC TrustCenter, Germany, Class 2 CA
Builtin Object Token:TC TrustCenter, Germany, Class 3 CA
Builtin Object Token:Certum Root CA
Builtin Object Token:Comodo AAA Services root
Builtin Object Token:Comodo Secure Services root
Builtin Object Token:Comodo Trusted Services root
Builtin Object Token:IPS Chained CAs root
Builtin Object Token:IPS CLASE1 root
Builtin Object Token:IPS CLASE3 root
Builtin Object Token:IPS CLASEA1 root
Builtin Object Token:IPS CLASEA3 root
Builtin Object Token:IPS Servidores root
Builtin Object Token:IPS Timestamping root
Builtin Object Token:QuoVadis Root CA
Builtin Object Token:Security Communication Root CA
Builtin Object Token:Sonera Class 1 Root CA
Builtin Object Token:Sonera Class 2 Root CA
Builtin Object Token:Staat der Nederlanden Root CA
Builtin Object Token:TDC Internet Root CA
Builtin Object Token:TDC OCES Root CA
Builtin Object Token:UTN DATACorp SGC Root CA
Builtin Object Token:UTN USERFirst Email Root CA
Builtin Object Token:UTN USERFirst Hardware Root CA
Builtin Object Token:UTN USERFirst Object Root CA
Builtin Object Token:Camerfirma Chambers of Commerce Root
Builtin Object Token:Camerfirma Global Chambersign Root
Builtin Object Token:NetLock Qualified (Class QA) Root
Builtin Object Token:NetLock Notary (Class A) Root
Builtin Object Token:NetLock Business (Class B) Root
Builtin Object Token:NetLock Express (Class C) Root
Builtin Object Token:XRamp Global CA Root
Builtin Object Token:Go Daddy Class 2 CA
Builtin Object Token:Starfield Class 2 CA
Builtin Object Token:StartCom Ltd.
Builtin Object Token:Taiwan GRCA
Builtin Object Token:Firmaprofesional Root CA
Builtin Object Token:Wells Fargo Root CA
Builtin Object Token:Swisscom Root CA 1
- ------------
Certificates that can be used to sign objects have *'s to their left.
---------------------------------------------------------------------------------------
D:\sources\Signing Tools\NSS Tools>signtool -d CA -k
"0d7de953-f681-4250-bece-f7
cabfd288c8" Addin
using certificate directory: CA
Generating Addin/META-INF/manifest.mf file..
--> components/AgentAddinFirefox.dll
--> components/AgentAddinFirefox.xpt
--> components/mfc71.dll
--> components/msvcp71.dll
--> components/msvcr71.dll
--> install.js
--> install.rdf
Generating zigbert.sf file..
tree "Addin" signed successfully
---------------------------------------------------------------------------------------
D:\sources\Signing Tools\NSS Tools>signtool -d CA -v Addin\extension.xpi
using certificate directory: CA
archive "Addin\extension.xpi" has passed crypto verification.
status path
------------ -------------------
verified components/AgentAddinFirefox.dll
verified components/AgentAddinFirefox.xpt
verified components/mfc71.dll
verified components/msvcp71.dll
verified components/msvcr71.dll
verified install.js
verified install.rdf
---------------------------------------------------------------------------------------
D:\sources\Signing Tools\NSS Tools>signtool -d CA -w Addin\extension.xpi
using certificate directory: CA
Signer information:
nickname: 0d7de953-f681-4250-bece-f7cabfd288c8
subject name: CN=Medialive,OU=SECURE APPLICATION
DEVELOPMENT,O=Medialive,L=Paris
,ST=France,C=FR
issuer name: CN=Thawte Code Signing CA,O=Thawte Consulting (Pty) Ltd.,C=ZA
----------------------------------------------------------------------------------------------------------------------
All seems good, but nothing works and i don't understand why -_-'''
Is that really the complete command line you used to create the signed
extension? How did you create the XPI archive?
I suggest you use "-X -Z myextension.xpi" with signtool, this will
create a correct XPI file (META-INF/zigbert.rsa must be the first file
in the XPI archive, this might be the problem in your case).
> D:\sources\Signing Tools\NSS Tools>signtool -d CA -w Addin\extension.xpi
> using certificate directory: CA
>
> Signer information:
>
> nickname: 0d7de953-f681-4250-bece-f7cabfd288c8
> subject name: CN=Medialive,OU=SECURE APPLICATION
> DEVELOPMENT,O=Medialive,L=Paris
> ,ST=France,C=FR
> issuer name: CN=Thawte Code Signing CA,O=Thawte Consulting (Pty) Ltd.,C=ZA
> ----------------------------------------------------------------------------------------------------------------------
This looks good, Thawte code signing certs should actually work with a
default configuration of the NSS builtin roots.
Kaspar
I have forgetten to specify i am under windows XP.
I zip myself the content of the directory once it has been signed,
zigbert.rsa must be the first file in archive !
I have tried this option unsuccessfull.
using -X -Z option doesn't work ... XPI isn't valid because zigbert.rsa will
not the firt file in archive.
> I suggest you use "-X -Z myextension.xpi" with signtool, this will
> create a correct XPI file (META-INF/zigbert.rsa must be the first file
> in the XPI archive, this might be the problem in your case).
>
>> D:\sources\Signing Tools\NSS Tools>signtool -d CA -w Addin\extension.xpi
>> using certificate directory: CA
>>
>> Signer information:
>>
>> nickname: 0d7de953-f681-4250-bece-f7cabfd288c8
>> subject name: CN=Medialive,OU=SECURE APPLICATION
>> DEVELOPMENT,O=Medialive,L=Paris
>> ,ST=France,C=FR
>> issuer name: CN=Thawte Code Signing CA,O=Thawte Consulting (Pty)
>> Ltd.,C=ZA
>> ----------------------------------------------------------------------------------------------------------------------
>
> This looks good, Thawte code signing certs should actually work with a
> default configuration of the NSS builtin roots.
That's why i understand nothing ...
> I have forgetten to specify i am under windows XP.
> I zip myself the content of the directory once it has been signed,
> zigbert.rsa must be the first file in archive !
>
> I have tried this option unsuccessfull.
> using -X -Z option doesn't work ... XPI isn't valid because zigbert.rsa will
> not the firt file in archive.
I seem to recall that -X either
a) is used instead of -Z (e.g. just "-X myextension.xpi"), or
b) must come after -Z (e.g. "-Z myextension.xpi -X")
The whole purpose of -X is to create an XPI file with the files in the
required order. And it does work.
--
Nelson B
signtool is sometimes somewhat picky about the argument ordering, that's
true. However,
signtool -d mycertdbdir -k mynick -p mypass -X -Z myext.xpi mysrcdir
*will* work, provided that signtool is v3.10 or later. After all,
signtool's usage says:
-X Create XPI Compatible Archive
(used in conjunction with the -Z)
-z omit signing time from signature
-Z "jarfile" create JAR file with the given name.
(Default compression level is 6.)
> The whole purpose of -X is to create an XPI file with the files in the
> required order. And it does work.
Yes, it does ;-) (https://bugzilla.mozilla.org/show_bug.cgi?id=248751
*did* fix the problem, indeed.)
Ahryman40k wrote:
> I have forgetten to specify i am under windows XP.
> I zip myself the content of the directory once it has been signed,
> zigbert.rsa must be the first file in archive !
I'd bet you forgot to add META-INF/manifest.mf and
META-INF/zigbert.sf... what does "unzip -l extension.xpi" give as
output? ("jar tvf" also does the trick, if you have a JDK on your box)
Kaspar
You're right, this option create a valid XPI file !!
I think during my last try, i must have forgotten the password ...
So thanks a lot, now the package is correctly installed !
But i have another problem when trying to use my component from a web page
:s
I think it is a security issue because javascript can use it when executed
from local with a security alert, but nothing works when executed from web.
At the beginning, i was thinked that signing my package will correct this,
but the problem is still present.
Do you have an idea ??
here , you can find my javascript sample :
---------------------------------------------------------------------------------------------------
function run ()
{
try
{
alert( "Demarrage du test" );
netscape.security.PrivilegeManager.enablePrivilege("UniversalXPConnect");
var interface = Components.interfaces.IMedialiveAgent;
alert( "On recupere l'objet par contrat");
var cppClass = Components.classes["@medialive.com/MedialiveAgent;1"];
alert( "on instancie le composant" );
var cppComponent = cppClass.createInstance(interface);
alert("on recupere l'interface");
cppComponent = cppComponent.QueryInterface(interface);
TestAgent( component );
document.write("<p><font color='green'>Test reussi</font></p>");
}
catch( e )
{
document.write("<p><font color='red'>Une exception est survenue dans le
run !</font></p>");
}
}
</script>
</head>
<body onLoad="run();">
</body>
</html>
----------------------------------------------------------------------------------------
In local web page, method TestAgent will be successfully called.
From web site page, i think code fail at this line "var interface =
Components.interfaces.IMedialiveAgent;"
So how must i use my component ?
The signature of an XPI file is just checked at installation time -
later on, Firefox completely ignores the files in the META-INF/
subdirectory... so signing an XPI doesn't really "improve" the security
of an extension after its initial install.
> Do you have an idea ??
I suggest you try mozilla.dev.tech.xpcom (or mozilla.dev.extensions,
possibly) for this kind of questions. dev.tech.crypto isn't really the
right place for that.
Kaspar