Closed
Bug 238142
Opened 21 years ago
Closed 17 years ago
server mismatch dialog doesn't show subject alt names (displays two identical domains as mismatched)
Categories
(Core Graveyard :: Security: UI, defect, P1)
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 398718
mozilla1.9alpha1
People
(Reporter: jgmyers, Assigned: KaiE)
References
()
Details
(Whiteboard: [kerh-coa])
Attachments
(1 obsolete file)
The certificate for www.e-trust.be has a common name of "www.e-trust.be" but a
subject alt name extension of "www.e-trust.belgacom.be". NSS is throwing a name
mismatch error--I believe correctly.
The dialog box that PSM displays, however, says that the certificate is for
"www.e-trust.be", 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?
Comment 1•20 years ago
|
||
*** Bug 243933 has been marked as a duplicate of this bug. ***
Comment 2•20 years ago
|
||
Primary SSL hostname? What's that?
Reporter | ||
Comment 3•20 years ago
|
||
I would define that as the first-listed host name.
Comment 4•20 years ago
|
||
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?
Comment 5•19 years ago
|
||
This bug also occurs when opening "www.rc-ulm-neuulm.de".
Recipe:
go to "https://www.rc-ulm-neuulm.de" (There is no problem, the certificate is
accepted)
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
Comment 6•19 years ago
|
||
An update:
The server mismatch dialog with identical names occurs when the image is
referenced as
<img src="https://rc-ulm-neuulm.de/images/corner_2.gif" 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 "https://www.rc-ulm-neuulm.de"
Othmar Marti
Comment 7•19 years ago
|
||
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.
www.rc-ulm-neuulm.de is not the same as rc-ulm-neuulm.de
Summary: Confusing dialog on server mismatch → server mismatch dialog doesn't show subject alt names.
Updated•19 years ago
|
Attachment #192730 -
Attachment description: Screenshot of bug → Screenshot of cert name mismatch unrelated to subject alt names.
Attachment #192730 -
Attachment is obsolete: true
Assignee | ||
Updated•19 years ago
|
Whiteboard: [kerh-coz]
Comment 8•19 years ago
|
||
Kai,
Please add this bug to the list of PSM error messages bugs that seriously
need attention.
Assignee | ||
Updated•19 years ago
|
Whiteboard: [kerh-coz] → [kerh-coa]
Updated•18 years ago
|
Priority: -- → P1
Target Milestone: --- → mozilla1.9alpha
Updated•18 years ago
|
Updated•18 years ago
|
QA Contact: ui
Updated•17 years ago
|
Blocks: CVE-2008-2809
Updated•17 years ago
|
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)
Comment 14•17 years ago
|
||
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. "www.mozilla.org" matches "subjectAltName:dNSName=*"), see bug #159483.
This is a security issue, and it should be solved.
Assignee | ||
Comment 15•17 years ago
|
||
This was fixed with the patch for bug 398718, we not display an error message that lists all allowed names.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•