702364 - 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.

Status: RESOLVED INVALID

(Core :: Security: PSM, defect)

Description

[Nandor Csapko]

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.

Comment 1

[Tim (fmdeveloper)]

What CA is being used to sign the xpi?

Comment 2

[Nandor Csapko]

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

[Tim (fmdeveloper)]

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

Comment 4

[Nandor Csapko]

Sorry, it was a mistake. It is valid to 3/21/2012. I have checked and it still occures with a new profile.

Comment 5

[Nandor Csapko]

Is there any progress? Should I give more info?

Comment 6

[Mike Kaply [:mkaply]]

Are you sure the CA is valid for code signing though?

It's possible the CA has had their code signing bit turned off.

Comment 7

[Nandor Csapko]

Yes it is valid, and as I said the previous versions worked well with the same signed xpi file.

Comment 8

[Mike Kaply [:mkaply]]

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?

Comment 9

[Nandor Csapko]

Yes, I will attach it soon, it takes some hours...

Comment 10

[Nandor Csapko]

Attachment: This xpi file shows the Author in the previous versions of Firefox when installing, but Firefox 8 states that the author is unverified.

Comment 11

[Mike Kaply [:mkaply]]

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.

Comment 12

[Mike Kaply [:mkaply]]

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.

Comment 13

[Wan-Teh Chang]

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.

Comment 14

[Kaspar]

(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.

Comment 15

[Kai Engert (:KaiE:)]

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.