Closed Bug 238142 Opened 19 years ago Closed 15 years ago

server mismatch dialog doesn't show subject alt names (displays two identical domains as mismatched)


(Core Graveyard :: Security: UI, defect, P1)

Other Branch


(Not tracked)



(Reporter: jgmyers, Assigned: KaiE)




(Whiteboard: [kerh-coa])


(1 obsolete file)

The certificate for has a common name of "" but a
subject alt name extension of "".  NSS is throwing a name
mismatch error--I believe correctly.

The dialog box that PSM displays, however, says that the certificate is for
"", claiming a mismatch between what are clearly the same host
names.  PSM is getting this value from the cert's common name, which isn't
correct for this case.

Nelson, what function should PSM be calling in order to get a cert's primary SSL
host name?
*** Bug 243933 has been marked as a duplicate of this bug. ***
Primary SSL hostname?  What's that?
I would define that as the first-listed host name.
certs don't have "primary" SSL host names.
They may have a host name in the subject name's "Common Name" (CN) attribute, 
and they may have a list of "alternative" names.  
If the list of "alternative names" contains one or more DNS names, then that
entire set of DNS names takes exclusive precedence over the Subject Common Name.  
So, the dialog should probably show the list of alternative DNS names, when 
there are any, and the subject common name when there are not. 

The question then is: Is there a way to ask NSS for the subject alt names
that are DNS names?
Product: PSM → Core
This bug also occurs when opening "". 
go to "" (There is no problem, the certificate is
click on "Veranstaltungen" on the left sidebar (this is on the same server, it
loads the righthand frame).
The error of a domain mismatch occurs. As can be seen from the screenshot, the
name of the two domains with a mismatch are identical. This is confusing.

I expect firefox either to accept the certificate, or if there are good
reasons, to show me one piece of differing evidence.

Othmar Marti
An update:

The server mismatch dialog with identical names occurs when the image is 
referenced as
<img src="" alt="aktuell" 
width="28" height="32">

It does not occur when the tag reads
<img src="/images/corner_2.gif" alt="aktuell" width="28" height="32">

I presume that there is a problem in the parser. The base URL 
is ""

Othmar Marti
Comment 5 and comment 6 are not related to subject alt names. 
The error dialog shown in the screet shot clearly states the problem with
that cert, which is not related to subject alt names. is not the same as
Summary: Confusing dialog on server mismatch → server mismatch dialog doesn't show subject alt names.
Attachment #192730 - Attachment description: Screenshot of bug → Screenshot of cert name mismatch unrelated to subject alt names.
Attachment #192730 - Attachment is obsolete: true
Whiteboard: [kerh-coz]
Please add this bug to the list of PSM error messages bugs that seriously 
need attention.
Whiteboard: [kerh-coz] → [kerh-coa]
Priority: -- → P1
Target Milestone: --- → mozilla1.9alpha
Assignee: jgmyers → kengert
Blocks: 107491
QA Contact: bmartin
QA Contact: ui
Duplicate of this bug: 377337
Duplicate of this bug: 381609
Summary: server mismatch dialog doesn't show subject alt names. → server mismatch dialog doesn't show subject alt names (displays two identical domains as mismatched)
Duplicate of this bug: 399173
Duplicate of this bug: 369112
Duplicate of this bug: 338419
In compliance to RFC 2818, "subjectAltName:dNSName" replaces the subject's "CN" as domain name identifier if present. Mozilla respects that. Unfortunately, the CN is NOT replaced in messages, warnings or the standard certificate "View" dialog box. 

This is not only a problem of **** self-contradicting warnings: There is a reason why the domain name identifier of a certificate should be shown to the user in all certificate related messages. It is the informational base on which the user decides if to accept a certificate.

This is even more important since mozilla based browsers match greedy wildcards (eg. "" matches "subjectAltName:dNSName=*"), see bug #159483.

This is a security issue, and it should be solved.
This was fixed with the patch for bug 398718, we not display an error message that lists all allowed names.
Closed: 15 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 398718
Blocks: 411246
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.