280345 - Certificate chain display is wrong

Status: RESOLVED INVALID

(NSS :: Libraries, defect)

Description

[Jochen Schwarze]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.5) Gecko/20041122 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.5) Gecko/20041122 Firefox/1.0

I own an email certificate issued by "TC TrustCenter Class 1 CA". The authority
store by default contains two "TC TrustCenter Class 1 CA" certificates, one
valid until 2005, and one valid until 2011. My certificate was issued with TC's
2011 certificate. When I view the certificate chain of my certificate, however,
Firefox wrongly displays the TC 2005 certificate as the root of the certificate
chain instead of the correct TC 2011 certificate.


Reproducible: Always

Steps to Reproduce:




Please contact me for screenshots and certificate details if you need more
information. 

To create a TC certificate for testing, visit
http://www.trustcenter.de/products/express/en/en.htm

I'm not sure if this problem is display-only or if it affects certificate chain
validation and has further security implication.

Comment 1

[Daniel Veditz [:dveditz]]

Use thunderbird or mozilla to send a test mail signed by your cert to
[e-mail], or attach one to this bug.

If this is an e-mail cert where are you seeing it in Firefox to check its cert
chain?

Changing product to PSM

Comment 2

[Jochen Schwarze]

Attachment: Certificate for reproducing the bug

The attached *.der file is an email certificate valid until 2006-01-25 and
issued with a CA certificate valid until 2011-01-01. (You can double-click the
*.der file on Windows XP to see details for the issusing certificate.)

To reproduce the bug described in this report, proceed like this:

1. In the Firefox certificate management dialog, go to the Authority tab and
verify that for  "TC TrustCenter for Security in Data Networks GmbH" only these
two Builtin Object Tokens and no other certificates are listed:

TC TrustCenter, Germany, Class 3 CA
TC TrustCenter, Germany, Class 2 CA

(This should be the default as distributed with Firefox 1.0.)

2. On the tab for other people's certificates, try to import the attached *.der
file (which is my personal certificate).

Bug #1: That import will silently fail.

3. Visit the following link to import a *different* CA certificate of the same
authority, valid only until 2005-12-31:

http://www.trustcenter.de/certservices/cacerts/TC_RootServer_DER_Class1.der

Activate the checkbox that indicates trusting that CA for email certificates.

Note that this is *not* the certificate that was used to issue the attached
*.der file.

4. Import the attached *.der file again. That import will work.

5. View the imported certificate. Goto to the details tab and select "TC
TrustCenter Class 1 CA - TC TrustCenter for Security in Data Networks GmbH"
from the certificate hierarchy. From the layout tree, select "Certificate /
Validity / Not until". Notice that the value will show "31.12.2005 13:56:33
GMT". This is 

Bug #2: Firefox shows a CA certificate here which is not the true issuer of the
 attached certificate.

Hope this helps. Please contact me if you need more information.

-Jochen

Comment 3

[Daniel Veditz [:dveditz]]

I can't reproduce bug #1 in comment 2 (presumably I did step 3 at some point
since I've got other TC user certs), but I can verify Firefox/Mozilla report a
different root cert than Windows does. Something's wrong, over to the crypto guys.

I don't know that this represents an exploit but I'll leave the confidential
flag for now in the off chance this knowledge could be used to craft a bogus cert.

Comment 4

[Robert Relyea]

You are describing correct behavior in NSS.

If the two certificates have the same subject and the same key, and both
certificates are valid, both chains are correct. If the certs have different
keys, then they should have different authority key ID's.

NSS is supposed to favor the chain that will most likely be validated.

If NSS has a valid, trusted certificate in it's database, it will prefer that
certificate over one that isn't trusted when validating a chain. NOTE that your
2005 cert is just as much a valid issue as the 2011 cert. Both have the same
keys, so there is no bug. This feature is important to handle certificate roll
over. You can import your 2011 certificate now and set the trust. When the 2005
cert expires NSS will switch the validation to the 2011 cert and everything
keeps working. 

NSS will not randomly import an invalid email chain.

bob

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

I don't think this bug qualifies as "security sensitive".
The question here is about the cert *display* by PSM.
I don't believe that's exploitable in any way. 
So, I think the "security sensitive" flag can be removed,
but I thank whoever set it for being cautious!

Submittor, could you please attach to this bug both of the two 
intermediate (?) CA certs (2005 and 2001) ?  

If it is true, as Bob Relyea has suggested and as I suspect, that 
both certs have in them the same public key, same subject name, 
and same issuer, and do not have separate subjectKeyID extensions
Then mozilla has behaved correctly here.  In that case, the mere
fact that the cert validation was not done with the cert you 
expected is not incorrect, not an error, and this bug can be 
resolved invalid.

Comment 6

[Jochen Schwarze]

Attachment: CA certificate valid 2005-12-31, as requested in comment #5

Comment 7

[Jochen Schwarze]

Attachment: CA certificate valid 2011-01-01, as requested in comment #5

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

Here's what I see in the 3 attachments:
1) an EE cert with no AKID extension, issued by a certain issuer name.
2) a root CA cert, self-issued, serial number 2, no AKID or SKID,
   valid from 1998-03-09  to 2005-12-31
3) a second root CA cert, self issued, serial number 1001, no AKID or SKID,
   with the same issuer name, subject name, and public key as the CA above,
   valid from 1998-03-09  to 2011-01-01

Given that both roots are in their validity period, that both certs have
the same public key, that no AKIDs or SKIDs exist, and that both certs are 
valid for the same purposes, any relying party may correctly rely on either 
one. There is no sense in which one is more correct than another, while 
both remain valid.  

Marking this bug invalid.