Closed
Bug 369112
Opened 18 years ago
Closed 18 years ago
With HTTPS, the Subject Common Name gets ignored if subjectAltName extension is present.
Categories
(Firefox :: Security, defect)
Firefox
Security
Tracking
()
RESOLVED
INVALID
People
(Reporter: mozilla, Unassigned)
References
Details
Attachments
(1 file)
20.49 KB,
image/png
|
Details |
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.
Reporter | ||
Comment 1•18 years ago
|
||
Comment 2•18 years ago
|
||
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.
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago
Resolution: --- → INVALID
Updated•17 years ago
|
Resolution: INVALID → DUPLICATE
Comment 4•17 years ago
|
||
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•17 years ago
|
||
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•17 years ago
|
||
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.
You need to log in
before you can comment on or make changes to this bug.
Description
•