559550 - UCC certificate CN value ignored

Status: RESOLVED INVALID

(Core :: Security: Process Sandboxing, defect)

Description

[freaky]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.3) Gecko/20100409 Gentoo Firefox/3.6.3
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.3) Gecko/20100409 Gentoo Firefox/3.6.3

We created a UCC (a multi domain certificate) ourselves using openssl. It is signed by our CA, whose public part is imported in firefox.

Firefox seems to ignore the CN value (ie the *main* domainname). When using the main domainname (thus the one in the CN value) it says the certificate is invalid for this website and then happily lists the domainnames it would be valid for. The domainnames it lists are *only* the subject alternative names.

Maybe I'm screwing up by not putting the main domainname in the alternative section, but the word 'alternative' is very clear to me, meaning not the common one, but an 'alternative'. IE works fine with these certificates, and so does firefox if I just use one of the alternative names (one in the alternative subject names thus in which case it nicely trusts the certificate as one would expect).

Reproducible: Always

Actual Results:  
Error that the certificate is invalid for the domain.

Expected Results:  
Accepting the certificate as the CN value matches the domainname and the CA being trusted.

The website is open to the internet. I don't like publishing it here, but if anyone actually doing the troubleshooting wants to have it I can provide public parts of both the CA and website certificate and it's URL through private communication.

Comment 1

[Kevin Brosnan]

User gave me the site address on irc. If you need it ping kbrosnan on moznet or freenode.

Comment 2

[:Cykesiopka]

According to https://tools.ietf.org/html/rfc6125#section-6.4.4:
> As noted, a client MUST NOT seek a match for a reference identifier
> of CN-ID if the presented identifiers include a DNS-ID, SRV-ID,
> URI-ID, or any application-specific identifier types supported by the
> client.
... or basically "don't check CN if any appropriate SAN entries are present".

This may or may not have been true in the past, but since Bug 1063281 was fixed, Firefox follows RFC6125 rules. The solution is to put what is in the CN in an appropriate SAN entry as well.