Note: There are a few cases of duplicates in user autocompletion which are being worked on.

NSS ignores subject CN even when SAN contains no dNSName



10 years ago
9 years ago


(Reporter: Fridtjof Busse, Assigned: Nelson Bolyard (seldom reads bugmail))


Firefox Tracking Flags

(Not tracked)




(1 attachment)



10 years ago
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

10 years ago
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 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.

Assignee: nobody → kengert
Component: Security → Security: PSM
Ever confirmed: true
Product: Firefox → Core
QA Contact: firefox → psm

Comment 3

10 years ago
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?
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
Summary: Weird SSL verification error → Weird SSL verification error: reports CN != host when they appear identical

Comment 5

10 years ago
(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

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

Comment 7

9 years ago
I think is INVALID.

The cert is broken, but it's possible to add an override (in Firefox 3).
Last Resolved: 9 years ago
Resolution: --- → INVALID
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.  
Resolution: INVALID → ---


9 years ago
Assignee: kengert → nobody
Component: Security: PSM → Libraries
OS: Linux → All
Product: Core → NSS
QA Contact: psm → libraries
Hardware: PC → All
Target Milestone: --- → 3.12.1
Version: unspecified → 3.0
Medium priority, not a stopper for 3.12
Priority: -- → P2
Summary: Weird SSL verification error: reports CN != host when they appear identical → NSS ignores subject CN even when SAN contains no dNSName
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. :)
Assignee: nobody → nelson
Attachment #311932 - Flags: review?
Comment on attachment 311932 [details] [diff] [review]
untested patch v1

Wan-teh, will you review this small patch?
Attachment #311932 - Flags: review? → review?(wtc)

Comment 12

9 years ago
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.
Attachment #311932 - Flags: review?(wtc) → review-
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

9 years ago
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.
Attachment #311932 - Flags: review- → review+
Checking in certdb.c; new revision: 1.92; previous revision: 1.91


9 years ago
Last Resolved: 9 years ago9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.