390296 - NSS ignores subject CN even when SAN contains no dNSName

Status: RESOLVED FIXED

(NSS :: Libraries, defect, P2)

Description

[Fridtjof Busse]

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

Although the CN in the certificate matches the hostname, Firefox complains that the certificate belongs to a different host, although the names match *exactly*. Neither Konqueror nor Opera complain about this, so the certificate doesn't seem to be (entirely) broken.

Reproducible: Always

Steps to Reproduce:
1. Go to https://mail.probusiness.de/
2. Accept the unverified certificate
3. Now you get the error about mail.probusiness.de != mail.probusiness.de


Expected Results:  
The certificate should be accepted, as the hostname matches the CN in the cert.

Comment 1

[Dan Weaver]

Problem also started with newest release of FireFox for our domain's SSL:
https://www.spamlion.com

SSL is from Network Solutions, and has had no problems with all prior certs over the last 11 years.

Comment 2

[Daniel Veditz [:dveditz]]

Comment 1 is incorrect, older versions of Firefox also have a problem with the current https://www.spamlion.com server. you need to configure your server to serve the intermediate certificates that chain to a root. This is a completely different problem from the first issue in this bug, and you should see support from your CA.

I can confirm the original problem. It is not "new", Firefox 1.5.0.7 and FF 1.0.7 exhibits the same behavior. The cert CN does appear to match the address in the location bar, perhaps it is misreporting the actual detected error.

Comment 3

[Dan Weaver]

Sorry, my mistake - added the root and intermediate certificates that came with the regular SSL cert, and it works just like you said.

"MY PROBLEM" is that for the last 11 years I've not had to do this (also register the intermediate certificates), as it's new within the last year or so?  Always something new... 

THANKS for the correction of my error.

Does this mean that the original listing of this bug for mail.probusiness.de is also in error, and Fridtjof Busse simply needs to also register his intermediate certificates?

Comment 4

[Daniel Veditz [:dveditz]]

I am unfamiliar with CA-Hannover and who they might chain to; it's possible intermediates would help with the initial recognition (probably not, IE doesn't recognize it either and Mr. Busse didn't complain about that part). The bug is about the fact that Firefox complains that the name in the cert (mail.probusiness.de) doesn't match the apparently identical site name mail.probusiness.de

Comment 5

[Kaspar]

(In reply to comment #3)
> Does this mean that the original listing of this bug for mail.probusiness.de
> is also in error, and Fridtjof Busse simply needs to also register his
> intermediate certificates?

No - it's a different problem. The certificate for mail.probusiness.de has a bogus subjectAltName extension, as shown by this output from pp:

>             Name: Certificate Subject Alt Name
>             Error: Parsing extension: security library: improperly formatted  DER-encoded message.
>             Data:
>                 41
>                 A

And derdump shows:

>             30 C-Sequence  08 (8)
>                06 Object Identifier  03 (3)
>                   2 5 29 17 (Certificate Subject Alt Name)
>                   55 1d 11
>                04 Octet String  01 (1)
>                   41

In contrast to most other implementations, NSS will *only* use the subjectAltName extension for host name checking, if it is present (it will ignore the CN from the subject in this case). This is the reason for the pretty strange error message you get with Firefox.

The simplest solution for the mail.probusiness.de site is to reissue a certificate with either 1) a correct subjectAltName extension or 2) no such extension at all.

See also bug 159483 comment 6 (item a)) for additional background.

Comment 6

[Fridtjof Busse]

I agree that the certificate is somewhat broken. 
However, other browsers can handle this and the error displayed is definitly very misleading.

Comment 7

[Kai Engert (:KaiE:)]

I think is INVALID.

The cert is broken, but it's possible to add an override (in Firefox 3).

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

This bug shows that NSS is not working as intended, so I'm opening it 
and changing it into an NSS bug.

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.

The key phrase here is "of type dNSName".  

NSS intends to implement the rules quoted above exactly.  The intent is 
that when a cert contains a SAN extension of type dNSName, NSS will use
the DNS Names contained in that extension EXCLUSIVELY, and will not also
honor the most specific Common Name field.  

But NSS actually just checks to see of the extension is present at all, 
and if so, it skips the CN test, even if the SAN contains no dNSName.
That's a bug.  

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

Medium priority, not a stopper for 3.12

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

Attachment: untested patch v1

I think this patch should do it.  
Basically, if we have any problems decoding the cert, we report 
extension_not_found, which causes the (only) caller to behave as 
if the extension was not found, and hence honor the subject CN.

Kai or Kaspar, feel free to review. :)

Comment 11

[Nelson Bolyard (seldom reads bugmail)]

Comment on attachment 311932 [details] [diff] [review]
untested patch v1

Wan-teh, will you review this small patch?

Comment 12

[Wan-Teh Chang]

Comment on attachment 311932 [details] [diff] [review]
untested patch v1

Two of the "goto finish" statements you changed should remain "goto finish".
If PORT_NewArena or PORT_ArenaAlloc fails and we goto fail, we will lose
the more correct  SEC_ERROR_NO_MEMORY error code.

If CERT_FindCertExtension fails, the error code should already be the
desired SEC_ERROR_EXTENSION_NOT_FOUND.

So it seems that the only necessary change is the goto after the failure of
CERT_DecodeAltNameExtension.  There we probably should also
filter the SEC_ERROR_NO_MEMORY error.

Comment 13

[Nelson Bolyard (seldom reads bugmail)]

Wan-Teh, the fact that this patch causes SEC_ERROR_NO_MEMORY to be changed
to SEC_ERROR_EXTENSION_NOT_FOUND in some cases is deliberate.  It is to 
get the caller of this function to take the path of execution that it takes
only when the error code is SEC_ERROR_EXTENSION_NOT_FOUND.

If CERT_DecodeAltNameExtension fails, SEC_ERROR_EXTENSION_NOT_FOUND is ONE
of the possible errors it may return, but there are also other error codes
it could return.  In all cases where the result is that the code is unable to find and process a DNS name or IP address alt name, regardless of the cause, 
I want the caller of this function to behave as if no SAN extension bearing 
DNS names (or IP address) was found.  see
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/certdb/certdb.c&rev=1.91#1844

Does that change your review?

Comment 14

[Wan-Teh Chang]

Comment on attachment 311932 [details] [diff] [review]
untested patch v1

Nelson, do you really want  different certificate verification results,
depending on whether we run out of memory or not?

If you're willing to use the CN in the Subject when you run out of
memory, why don't you use it when there is memory?

Since the out-of-memory condition is exceptional, I won't dwell on
this issue.

Comment 15

[Nelson Bolyard (seldom reads bugmail)]

Checking in certdb.c; new revision: 1.92; previous revision: 1.91