430804 - Certificates with multiple CNs are not recognized correctly

Status: RESOLVED DUPLICATE of bug 380656

(Firefox :: Security, defect)

Description

[Itzchak Rehberg]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.13) Gecko/20061201 Firefox/2.0.0.13 (Ubuntu-feisty)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.13) Gecko/20061201 Firefox/2.0.0.13 (Ubuntu-feisty)

Imagine a web server with multiple name based virtual hosts - you can only have one SSL certificate here. This certificate will probably cover multiple CNs (i.e. the virtual hosts), e.g.
0.CN = www.domain1.com
2.CN = www.domain2.net
3.CN = www.domain3.org
If you now go to access https://www.domain2.net/ Firefox pops up an alert saying the certificate is for www.domain1.com and does not match www.domain2.net - though the latter is covered by the second CN (does happen with all Mozilla based browsers only).

Reproducible: Always

Steps to Reproduce:
1. Set up a SSL server with multiple name based virtual hosts, using a shared certificate covering all the involved names, i.e. having multiple CNs
2. Point FF to one of the virtual hosts listed after the first CN
3. Get the popup immediately
Actual Results:  
Pop-Up pointing out the certificate does not match the host name

Expected Results:  
no Pop-Up at all (if certificate signed by trusted CA), or only pop-up informing about the missing trust

Error does not appear e.g. with MSIE. Certificate is valid this way according to the specs, so FF should accept it

Comment 1

[Jan Darmochwal]

Itzchak, this might be a duplicate of bug 380656.

Comment 2

[Itzchak Rehberg]

Jan: After having checked this, I confirm. Although I cannot agree with the closing comment there: The certificate I used contains, as I wrote above, only a couple of CNs - but no subjectAltName. So if I add as a last CN just "*", FF is not complaining any longer - but according to the comment it should take the "most specific" CN. Well - "*" is not that specific...

I played around with a lot of options to figure out. Admitted, I'm not that familiar with creating certificates. But also searching the web gave no concrete answers how to create a valid certificate with multiple CNs which would be accepted also by FF (except using "*" as last resort - which I consider an "ugly work-around").

As I already pointed out, MSIE is not complaining here. Of course I agree if somebody says we cannot take that as the rule :) But said that FF works "as designed and as intended", can somebody point out how to create the "correct" certificate with multiple CNs, so FF would accept it for all domains listed? Looks like I'm not the only one struggling with that - but on the web you only find questions and no answers...

Comment 3

[Jan Darmochwal]

You might find some help on creating certificate with subjectAltName here:
http://wiki.cacert.org/wiki/VhostTaskForce

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

This is definitely a duplicate of bug 380656. 

The term "most specific" has a specific meaning in the context of 
Directory Names (such as the certificate Subject name and Issuer name).
Consider a name of the form
cn=host1,ou=Accounting,o=BigCompany,L=City,ST=Province,C=Country

That is actually a hierarchy of attributes.  It means:
  The host named host1, within
    the Organization Unit named Accounting, within
      the Organization named BigCompany, within
        the Locality named City, within
          the STate named Province, within
            the Country named Country.  

The left-most attribute is the most specific.
The right-most attribute is the most general.

It is possible (but somewhat unusual) to have an attribute within another
attribute of the same type, for example, one might have an Organizational
Unit named "Accounts Receivable" within an Organizational Unit called 
"Accounting" within an organizational unit called "Finance", and this 
would be
   OU=Accounts Receivable,OU=Accounting,OU=Finance,O=BigCompany,...

Now, clearly if there are multiple host names, one name is not within 
another, which is why it's not proper to put multiple CNs acting as host 
names in a Directory name. But CNs were originally not intended to be host
names.  They were intended to be people's names.  So, one can imagine CNs
within CNs as hosts within (under the control of) a person, e.g. 
   CN=host1,CN=Itzchak Rehberg,OU=Finance,O=BigCompany,...
That would be a legitimate example of a directory name with multiple CNs.
Only the (one) most-specific CN can be used as a host name. 

In truth, CNs were never intended to be anything but people's names.
The use of CN as a host name was a non-standard convention started by 
Netscape in the early 1990s to work around the problem that was no 
official place to put host names in certificates at that time.

Today, there IS an official place for host names in a certificate, and it
allows as many host names as you want.  It is part of a Subject Alternative
Names (subjectAltName) extension.  That's where all host names really belong.
And I do mean ALL host names belong there.  Some folks fall into the trap of
putting one host name in the Subject Common Name, and putting the rest in the
Subject Alternative Names (SAN).  But the standard says that the Subject 
Common Name is to be used ONLY when there are no Subject Alternative DNS 
Names. So, if you put any host names in the SAN, you must put them all there.

You MAY ALSO put one host name in the most specific subject Common name just
in case there are some very old browsers that don't understand SANs.  But 
you can only put one there.  That name is likely to appear in two places,
in the Subject Common Name and in the SAN.

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

One more thought.  It is the responsibility of the Certificate Authority 
to ensure that the subject names in the certificates it issues are valid. 
If you bought a certificate from a CA, and the CA didn't tell you that 
CN=host1,CN=host2,CN=host3 wasn't going to work, then IMO, you have a 
complaint against that CA.  If you were that CA yourself, well, now you 
understand a little more about what it means to be an AUTHORITY.  
Authorities have to know all this stuff.

Comment 6

[Itzchak Rehberg]

Nelson: Thank you for your detailed description! Now I at least understand *WHY* it is supposed this way.

Jan: Thank you for the link. I checked that out, and the script provided seems to generate the proper CSR. However, using a self-signed certificate still breaks, since the signing process seems to remove the subjectAltNames again - and I could not figure out how to keep them (copy_extensions=copy, preserve=yes, issuerAltName=issuer:copy and even literally don't seem to do the job - or x509 is using a different config, but if I look at the key with "openssl x509 -in test_crt.pem -noout -text" I cannot see any of the subjectAltNames - while the test_csr.pem shows them.

I finally played around with "openssl ca" instead of "openssl x509", and got it working. So thank you all again for helping me to solve this issue!