933969 - Regression: certificate chain no longer displayed correctly

Status: RESOLVED INVALID

(Core :: Security: PSM, defect)

Description

[Uwe Geuder]

Attachment: certviewer-chromium.png

User Agent: Mozilla/5.0 (X11; Linux i686; rv:26.0) Gecko/20100101 Firefox/26.0 (Beta/Release)
Build ID: 20131028225529

Steps to reproduce:

1. visit https://www.mozilla.org
2. click the padlock icon
3. in the popup click "More information"
4. In the Page information click "View certificate"
5. In the certificate viewer click the "details" tab

The problem can be reproduced on many (all?) https sites.



Actual results:

A chain of 3 certificates is displayed. (numbering by lines)

1. GeoTrust Primary
2. GeoTrust Extended
3. www.mozilla.org

The issuer of GeoTrust Primary is displayed as GeoTrust Primary (self signed)

See attachment certviewer-firefox.png


Expected results:

Chromium and openssl command line client show that the chain really contains 4 certificates (numbering by lines in chromium certviewer)

1. Equifax
2. GeoTrust Primary
3. GeoTrust Extended
4. www.mozilla.org

The issuer of GeoTrust Primary is really Equifax, so it is not self-signed but intermediate.

See attachments certviewer-chromium.png and openssl.txt (numbering is the other way round and 0 based)

Comment 1

[Uwe Geuder]

Attachment: certviewer-firefox.png

Comment 2

[Uwe Geuder]

Attachment: openssl.txt

Comment 3

[Uwe Geuder]

A similar sounding bug exists in https://bugzilla.mozilla.org/show_bug.cgi?id=769513

However, if I interpret it correctly, the reporter complains that Firefox does not behave according to the chain displayed (it does not complain about an untrusted certificate). However that is not the problem here. Firefox behaves correctly, it trusts the correct chain. But it displays an incorrect one, which indeed would not be trustworthy if it reflected the truth.

Comment 4

[Uwe Geuder]

Attachment: about:support

Haven't had time to compare different versions. Attached about:config from the my current 26.0 Beta 1 where this problem is observed.

Comment 5

[Uwe Geuder]

This is a regression: The bug is present in at least beta (26.0) and aurora (27.0a2). I happened to have a 20.0 in some corner of the disk. There the bug is NOT present, 4 certificates displayed correctly.

Comment 6

[Loic]

I'm not sure if it's a valid regression or by design, but here is the regression range:
good=2013-04-30
bad=2013-05-01
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=dd0c611a0a27&tochange=02aa81c59df6

Suspected bug maybe:
Brian Smith — Bug 813418 - Centralize certificate validation into CertVerifier part1(cviecco) r=bsmith

Brian, any idea?

Comment 7

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

The GeoTrust Primary Certification Authority is a root certificate trusted by Firefox, and thus it exists as a self-signed certificate in Firefox's certificate store. While the server may send other intermediate certificates (in particular, it appears it sends that same certificate as signed by Equifax), when verifying certificates, Firefox uses any valid certificate at its disposal to find a path to a trusted root. While before it may have found the path terminating with Equifax, Firefox now appears to find an equally valid valid path terminating with GeoTrust. So, while the behavior has changed, it is still valid.
I'm resolving this as "invalid" which is an unfortunately harsh way of saying we appreciate you taking the time to file this issue, but it's not actually a bug.
(As an addendum, the confusion may be over the fact that the certificate viewer doesn't display the certificate chain sent by the server, but rather a trusted chain Firefox calculates on the fly.)