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
> 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" ??
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.
>> 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" ??
> 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.
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 ?
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 ?
Ahryman40k wrote: > "Nelson Bolyard" <NOnelsonS...@NObolyardSPAM.com> a écrit >> 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.
> 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?
i have sign my xpi package with signtool and the .db files ( cert8.db, key3.db, secmod.db ) coming from Firefox profile directory. In this profile, my certificate data was loaded successfully and i can find it in the certificate database.
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 ?
Ahryman40k wrote: > i have sign my xpi package with signtool > and the .db files ( cert8.db, key3.db, secmod.db ) coming from Firefox > profile directory. > In this profile, my certificate data was loaded successfully and i can find > it in the certificate database.
> 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.
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" <NOnelsonS...@NObolyardSPAM.com> a écrit dans le message de news: ZtGdnYMRXtq_P_DbnZ2dnUVZ_judn...@mozilla.org...
> Ahryman40k wrote: >> i have sign my xpi package with signtool >> and the .db files ( cert8.db, key3.db, secmod.db ) coming from Firefox >> profile directory. >> In this profile, my certificate data was loaded successfully and i can >> find >> it in the certificate database.
>> 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.
> Is that an exact copy of what was displayed on your screen?
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.
--------------------------------------------------------------------------- ------------ 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.
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
> Is that really the complete command line you used to create the signed > extension? How did you create the XPI archive?
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
Ahryman40k wrote: > "Kaspar Brand" <m...@velox.ch> a écrit >> 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). > 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 wrote: > 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")
signtool is sometimes somewhat picky about the argument ordering, that's true. However,
*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.
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)
> Nelson B wrote: >> 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")
> signtool is sometimes somewhat picky about the argument ordering, that's > true. However,
> *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.
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;"
> 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)
Ahryman40k wrote: > 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.
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.
