380656 - Only the first CN (Common Name) in a https SSL certificate containing multiple CNs is recognized

Status: RESOLVED INVALID

(NSS :: Libraries, defect)

Description

[Gene Wood]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3

When browsing to a site which has an ssl certificate containing multiple CN values, firefox only matches on the first in the certificate.

Example :
If www.domain1.com and www.domain2.com are both A records to the same IP, and that webserver serves up a certificate with multiple CN values like this :

openssl x509 -in server.crt -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 63209 (0xf6e9)
        Signature Algorithm: md5WithRSAEncryption
        Issuer: O=Root CA, OU=http://www.cacert.org, CN=CA Cert Signing Authority/emailAddress=[e-mail]
        Validity
            Not Before: Mar  6 03:06:42 2005 GMT
            Not After : Mar  6 03:06:42 2007 GMT
        Subject: CN=www.domain1.com, CN=www.domain2.com

If one browses to that site at https://www.domain1.com the certificate is identified correctly and everything is fine. If one browses to https://www.domain2.com, Firefox complains that the site name doesn't match the certificate.

Here's more information on certificates with multiple CN values :

http://wiki.cacert.org/wiki/VhostTaskForce#head-661e90855b6b4285bbab272390bf7bbd639ed5d9



Reproducible: Always

Steps to Reproduce:
Browse to a site that has a certificate with multiple CN values as any name other than the first CN value. I unfortunately haven't found an example on the internet, and the instance that I reproduce it with is on our intranet. cacert.org used to maintain example hosts with this configuration, but they appear to be unavailable now.

https://host1.way2.vhosts.cacert.org/
https://host2.way2.vhosts.cacert.org/

This can be tested by generating a certificate with 2 CN values, loading it into a test web server and browsing to it using the second CN name.

To do this test you can find instructions here for generating a multiple CN cert :

http://wiki.cacert.org/wiki/VhostTaskForce#head-661e90855b6b4285bbab272390bf7bbd639ed5d9

Actual Results:  
When browsing to the URL of the second CN firefox pops up the certificate warning dialog box asking if I want to trust the certificate from this site because it doesn't match the domain name that I'm going to.

Expected Results:  
It should match on all CNs in the certificate and not present the dialog box.

Comment 2

[Ostap Bender]

Tested against a trunk build a certificate with multiple common names and it only recognizes the last one.

Comment 4

[Tobias Fischer]

As commented in Bug 414824#c1 it seems, that the Product should be changed to "NSS" and Component "Libraries" for this Bug. It was not App-specific. 

With current Trunk-Builds there was something wrong for me to with SSL-Certificates including muliple CN.

CC' Nelson, hope he can take a closer look on this.

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

Assuming that the description above correctly describes what occurred, 
this is not a bug.  This is NSS working EXACTLY as required by RFC 2818.
Quote:
   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.

Note that this says that
a) if the certificate contains the *standard* subject Alt Name extension
containing one (or more) DNS names, then the DNS names in that extension
MUST be used EXCLUSIVELY as the server identity (for name matching purposes).  
(IOW, the common name is NOT to be used in this case.)

b) OTHERWISE (if there is no subject alt name extension present with DNS 
name components), then the older non-standard convention that uses the 
(one and only) MOST SPECIFIC Common Name MAY be used as the identity.
In that case, only one common name, the MOST SPECIFIC one.

This code is working as designed and as intended.  People who want multiple
host names in a cert must do so in accordance with the standards.

Comment 7

[Varga Viktor]

(In reply to comment #5)

Dear Nelson,

I have checked the RFC 2818 and I think, this bug sould not be closed

You have quoted:

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

It's clear, if certificate has SAN extension, that extension should be used only.

It's clear, that the use of CN field is deprecated.

But the qutoed block says, "Otherwise, the (most specific) Common Name
field in the Subject field of the certificate MUST be used."

I have chekcked this case, and if there is multiple CN and there is not SAN field, the Firefox doesnot handles it well.

My opinion regarding the RFC:
if there are only CN fields, and there isn't SAN field, then the the most specific CN field should be used.

Maybe should this bug reopen?

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

I suspect there is confusion about the meaning of the words "most specific".
Please read prior descriptions of them in 
bug 307234 comment 2
bug 305890 comment 9
Being "most specific" basically means "last in the DER encoded form".
Note that by convention, DN attributes are commonly displayed in the opposite
order of the order in which they are found in the DER encoded form, so 
"most specific" also usually means "first in the displayed form".