"Nelson Bolyard" <[EMAIL PROTECTED]> a écrit dans le message de news: [EMAIL PROTECTED] > Ahryman40k wrote: >> hi, >> >> 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" ?? > > 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 ? 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.
_______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
