Persona is no longer an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 390296 - NSS ignores subject CN even when SAN contains no dNSName
: NSS ignores subject CN even when SAN contains no dNSName
Product: NSS
Classification: Components
Component: Libraries (show other bugs)
: 3.0
: All All
: P2 normal (vote)
: 3.12.1
Assigned To: Nelson Bolyard (seldom reads bugmail)
Depends on:
  Show dependency treegraph
Reported: 2007-07-31 06:39 PDT by Fridtjof Busse
Modified: 2008-05-15 22:14 PDT (History)
6 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---

untested patch v1 (2.32 KB, patch)
2008-03-26 18:11 PDT, Nelson Bolyard (seldom reads bugmail)
wtc: review+
Details | Diff | Splinter Review

Description Fridtjof Busse 2007-07-31 06:39:04 PDT
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20061201 Firefox/ (Ubuntu-feisty)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20061201 Firefox/ (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
2. Accept the unverified certificate
3. Now you get the error about !=

Expected Results:  
The certificate should be accepted, as the hostname matches the CN in the cert.
Comment 1 Dan Weaver 2007-08-07 10:14:15 PDT
Problem also started with newest release of FireFox for our domain's SSL:

SSL is from Network Solutions, and has had no problems with all prior certs over the last 11 years.
Comment 2 Daniel Veditz [:dveditz] 2007-08-07 16:07:28 PDT
Comment 1 is incorrect, older versions of Firefox also have a problem with the current 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 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 2007-08-07 18:13:32 PDT
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 is also in error, and Fridtjof Busse simply needs to also register his intermediate certificates?
Comment 4 Daniel Veditz [:dveditz] 2007-08-07 18:58:36 PDT
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 ( doesn't match the apparently identical site name
Comment 5 Kaspar Brand 2007-08-07 22:31:00 PDT
(In reply to comment #3)
> Does this mean that the original listing of this bug for
> is also in error, and Fridtjof Busse simply needs to also register his
> intermediate certificates?

No - it's a different problem. The certificate for 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 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 2007-08-09 08:31:46 PDT
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) 2008-03-26 15:26:54 PDT
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) 2008-03-26 17:51:32 PDT
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) 2008-03-26 17:54:04 PDT
Medium priority, not a stopper for 3.12
Comment 10 Nelson Bolyard (seldom reads bugmail) 2008-03-26 18:11:19 PDT
Created attachment 311932 [details] [diff] [review]
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) 2008-04-15 17:58:36 PDT
Comment on attachment 311932 [details] [diff] [review]
untested patch v1

Wan-teh, will you review this small patch?
Comment 12 Wan-Teh Chang 2008-04-16 10:54:12 PDT
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

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) 2008-04-16 12:14:28 PDT
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

Does that change your review?
Comment 14 Wan-Teh Chang 2008-04-16 16:43:22 PDT
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) 2008-05-15 20:39:16 PDT
Checking in certdb.c; new revision: 1.92; previous revision: 1.91

Note You need to log in before you can comment on or make changes to this bug.