Closed
Bug 702364
Opened 13 years ago
Closed 12 years ago
The new Firefox 8.0 can't verify the author of a signed extension .xpi, the same .xpi file can be verified in the previous version of Firefox, e.g. 7.0.1.
Categories
(Core :: Security: PSM, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: csapko.nandor, Assigned: wtc)
Details
(Keywords: regression)
Attachments
(1 file)
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20100101 Firefox/8.0 Build ID: 20111104165243 Steps to reproduce: I'm installing an extension which is signed. All the previous releases of Firefox can verify its author, but the new 8.0 is unable to verify it. Actual results: The Firefox 8.0 pops up the Software Installation dialog which states that the 'Author not verified'. Expected results: I tried the previous versions 6.0 and 7.0. These versions of Firefox are still able to verify the author and the Installation Dialog shows the Author of the signed extension.
Reporter | ||
Updated•13 years ago
|
Summary: The new Firefox 8.0 can't verify the author of a signed extension .xpi, the same .xpi file can verify it in the previous version of Firefox 7.0.1. → The new Firefox 8.0 can't verify the author of a signed extension .xpi, the same .xpi file can be verified in the previous version of Firefox, e.g. 7.0.1.
Comment 1•13 years ago
|
||
What CA is being used to sign the xpi?
Reporter | ||
Comment 2•13 years ago
|
||
The CA which issued the certificate is a Hungarian Certificate Authority. The URL of the CA is http://www.netlock.net/, the English version: http://www.netlock.hu/USEREN/ The Certificate Information: The certificate is intended for the following purpose(s): - Ensures software came from software publisher - Protects software from alteration after publication - 1.3.6.1.4.1.3555.1.15.20080206 Issued to: HEXAGON CONSULTING Kft.(*) Issued by: NetLock Minositett Kozjegyzoi (Class QA) Tanusitvanykiado Valid from 3/22/2011 to 3/21/2011
Comment 3•13 years ago
|
||
Typo? Valid from 3/22/2011 to 3/21/2011 If not, the certificate isn't valid. I do still see that CA in the latest nightly, so that doesn't appear to be the issue. Does the issue still occur with a new, empty profile? http://support.mozilla.com/en-US/kb/Basic%20Troubleshooting#w_8-make-a-new-profile
Reporter | ||
Comment 4•13 years ago
|
||
Sorry, it was a mistake. It is valid to 3/21/2012. I have checked and it still occures with a new profile.
Reporter | ||
Comment 5•13 years ago
|
||
Is there any progress? Should I give more info?
Comment 6•13 years ago
|
||
Are you sure the CA is valid for code signing though? It's possible the CA has had their code signing bit turned off.
Reporter | ||
Comment 7•13 years ago
|
||
Yes it is valid, and as I said the previous versions worked well with the same signed xpi file.
Comment 8•13 years ago
|
||
Is it possible to attach the XPI? Or create a new empty XPI (just install.rdf) and sign it and attach it to the bug?
Reporter | ||
Comment 9•13 years ago
|
||
Yes, I will attach it soon, it takes some hours...
Reporter | ||
Comment 10•13 years ago
|
||
Comment 11•13 years ago
|
||
The error in the console is: Signature Verification Error: the signature on this .jar archive is invalid because the digital signature (*.RSA) file is not a valid signature of the signature instruction file (*.SF). And I have verified that it worked in 3.6 and fails in 8 (I'll be trying 7 and others in a bit). I'll see if I can track down a regression range.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 12•13 years ago
|
||
Definitely a regression. Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=be090ee1747a&tochan ge=b422fd99fe0d This changeset included upgrades to NSPR and NSS: d0c53c6ed070 Kai Engert — Bug 673382, Upgrade to NSPR 4.8.9, landing beta 5, r=wtc b4fb6f334a4f Kai Engert — Bug 673382, Upgrade to NSS 3.12.11, landing beta 3, r=wtc Copying Kai.
Updated•13 years ago
|
Keywords: regression
Assignee | ||
Comment 13•13 years ago
|
||
The NSS 3.12.11 Beta 3 update is this changeset: http://hg.mozilla.org/mozilla-central/rev/b4fb6f334a4f The changeset consists of three changes: - Bug 668397: remove Fortezza key support. This accounts for most of the diffs. - Bug 662557: a libpkix change. This should be unrelated. - Bug 217721: change the certUsageObjectSigner case back to KU_DIGITAL_SIGNATURE because RFC 5280 says code signing needs digitalSignature, as opposed to "digitalSignature and/or nonRepudiation". r=rrelyea. The last change should explain this bug. The last change follows the following guidance in RFC 5280 Section 4.2.1.12. Extended Key Usage: The following key usage purposes are defined: ... id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 } -- TLS WWW server authentication -- Key usage bits that may be consistent: digitalSignature, -- keyEncipherment or keyAgreement id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 } -- TLS WWW client authentication -- Key usage bits that may be consistent: digitalSignature -- and/or keyAgreement id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 } -- Signing of downloadable executable code -- Key usage bits that may be consistent: digitalSignature id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 } -- Email protection -- Key usage bits that may be consistent: digitalSignature, -- nonRepudiation, and/or (keyEncipherment or keyAgreement) Note that for id-kp-codeSigning, only digitalSignature is listed. I suspect that the code signing certificate does not have the digitalSignature key usage bit.
Assignee: nobody → wtc
Status: NEW → ASSIGNED
Comment 14•13 years ago
|
||
(In reply to Wan-Teh Chang from comment #13) > I suspect that the code signing certificate does not have the > digitalSignature key usage bit. Correct, it has nonRepudation only. It has a rather weird mix of extensions - and purports to be a "qualified certificate" (there's a Netscape comment extension to this effect, and it also features qcStatements). Frankly, I don't think NSS needs to support QCs for code signing purposes.
Component: General → Security: PSM
OS: Windows 7 → All
Product: Firefox → Core
QA Contact: general → psm
Hardware: x86_64 → All
Comment 15•12 years ago
|
||
Thanks to Wan-Teh for the analysis. In my understanding, the behaviour is expected and this bug is invalid. I apologize for the trouble, but please get a new signing certificate.
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•