369112 - With HTTPS, the Subject Common Name gets ignored if subjectAltName extension is present.

Status: RESOLVED INVALID

(Firefox :: Security, defect)

Description

[Lars Eilebrecht]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.8) Gecko/20061118 ((Linux)) Galeon/2.0.1
Build Identifier: Firefox 2.0.0.1

[Tested with Firefox 1.5.0.9 and 2.0.0.1]

If the server's SSL certificate contains the subjectAltName extension,
the regular Common Name (CN) listed in the subject field gets ignored
and a wrong security warning is displayed.
(see attached screenshot).

Adding the CN to the subjectAltName field "solves" the issue, but
according to RFC 3280 this should not be necessary.

Excerpt from RFC 3280:

   4.2.1.7  Subject Alternative Name

   The subject alternative names extension allows *additional* identities
   to be bound to the subject of the certificate.

Only if the subjectAltName extension is marked as a "critical" extension
*and* the Subject field is empty, the subject field itself can be
ignored by the application.


Reproducible: Always

Steps to Reproduce:
1. Create a server SSL certificate that contains "node.example.com" as its Common Name, and contains a subjectAltName with a DNS attribute for "othernode.example.com".

2. Accessing the Web site with the name "node.example.com" results in a wrong security warning (similar to the screenshot I've attached)

Actual Results:  
Firefox shows a security warning that the name of the Web site does
not match the name in the certificate, even though the CN is correctly
set in the Subject field of the certificate.

Expected Results:  
The Subject Common Name (if set) must always be checked/used by Firefox
even if the subjectAltName extension field is present.

Comment 1

[Lars Eilebrecht]

Attachment: screenshot

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

RFC 2818 says:

   If a subjectAltName extension of type dNSName is present, that MUST
   be used as the identity. Otherwise, the (most specific) Common Name
   field in the Subject field of the certificate MUST be used. Although
   the use of the Common Name is existing practice, it is deprecated and
   Certification Authorities are encouraged to use the dNSName instead.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

Jesse, This bug does not complain about a cert display.
It complains that the product ignores the Common Name when the 
Subject Alt Name is present.  That behavior, ignoring the Common Name
when the Subject Alt Name is present, is precisely what RFC 2818 dictates.
So, this bug is invalid.  

The complaint about the display is a separate issue.

Comment 5

[Jesse Ruderman]

Both this bug (including the screenshot in this bug) and bug 238142 are complaining about a dialog appearing saying the same bogus thing (foo.com doesn't match foo.com).  Are you saying that this bug and bug 238142 happen for different reasons?

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

Jesse, the subject of this bug is not a bad cert dialog.

The subject makes a specific assertion about processing of names in the 
certificates for https.  The subject plainly asserts that the behavior which 
ignores the DNS names in a cert's Subject Common Name, when a Subject Alt 
Name is present, is incorrect.  That is NSS behavior.  This bug is, in 
effect, an NSS bug.  

This bug cites the goofy display (the subject of bug 238142) as an EFFECT 
of the cert processing that it claims is incorrect.  But the subject of 
the bug is plainly the cert processing (done in NSS), and not the display.

The bug does not call for the dialog to be changed, but rather calls for 
the cert's subject common name to be honored, even when the Subject Alt Name
is present.  However, RFC 2818 defines the correct behavior, and NSS follows
it.  

Therefore, the change for which this bug calls would cause us to not follow 
the RFC, and on that basis, it is invalid.

Comment 7

[Jesse Ruderman]

Ahh, ok.