Closed
Bug 211049
Opened 21 years ago
Closed 21 years ago
"security error: domain name mismatch" when page is opened
Categories
(NSS :: Libraries, defect, P2)
Tracking
(Not tracked)
RESOLVED
FIXED
3.9
People
(Reporter: dedrick, Assigned: nelson)
References
()
Details
(Keywords: regression, Whiteboard: [3.8.2][3.7.8])
Attachments
(1 file)
748 bytes,
patch
|
nelson
:
review+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/4.8 [en] (X11; U; Linux 2.4.2 i386) Build Identifier: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.4) Gecko/20030624 I don't see the domain name mismatch here: You have attempted to extablish a connection with "dsl-146-127.resnet.purdue.edu". However, the security certificate presented belongs to "dsl-146-127.resnet.purdue.edu". It is possible, though unlikely, that someone may be trying to intercept your communication with this web site. Reproducible: Always Steps to Reproduce: 1. Open https://dsl-146-127.resnet.purdue.edu 2. 3. Actual Results: mozilla gives a security error, domain name mismatch Expected Results: Accepted the certificate
Comment 1•21 years ago
|
||
-> PSM
Assignee: mstoltz → ssaux
Component: Security: General → Client Library
Product: Browser → PSM
QA Contact: carosendahl → bmartin
Version: Trunk → unspecified
Comment 2•21 years ago
|
||
I get untrusted because the cert doesn't chain to a trusted root, not because of a name mismatch.
Assignee: ssaux → kaie
Comment 3•21 years ago
|
||
Eric said in a mail message: Yes, the untrusted CA will pop up. Accept the certificate, and then you'll get the domain name mismatch error.
Comment 4•21 years ago
|
||
I can confirm the bug. After the untrusted, I see the mismatch warning, too. (Eric, but note, don't expect this certificate to be usable in real world scenarios. You seem to have generated your own CA cert, which uses the common default "Snake Oil". It is very likely that other people might do the same, and the combination of issuer subject and issued certificate serial number must always be unique.) Anyway, I agree we must have some kind of problem. I believe this is a regression, because I do not see the "mismatch" error with Mozilla 1.3. I believe this must be a NSS bug, I don't realize any change in PSM between 1.3 and 1.4 that could have caused this problem.
Assignee: kaie → wtc
Status: UNCONFIRMED → NEW
Component: Client Library → Libraries
Ever confirmed: true
Keywords: regression
Product: PSM → NSS
QA Contact: bmartin → bishakhabanerjee
Comment 5•21 years ago
|
||
Nelson, could you take a look at this bug?
Assignee: wtc → nelsonb
Version: unspecified → 3.8
Comment 6•21 years ago
|
||
Nelson, this bug looks like a regression of bug 166454 and bug 162979.
Comment 7•21 years ago
|
||
I believe this bug was introduced by the fix for bug 174885 when we changed how an empty sequence is represented in the decoded form. It was a NULL array pointer before; now it is a pointer to an array containing only the terminating NULL pointer. The fix is to treat both a NULL array pointer and a pointer to an array containing only the terminating NULL pointer as an empty sequence.
Updated•21 years ago
|
Attachment #126781 -
Flags: review?(nelsonb)
Assignee | ||
Comment 8•21 years ago
|
||
Several comments: 1. Empty Subject Alt Name extensions are invalid. RFC 3280 requires that Subject Alt Name extensions contain at least one GeneralName, and that every GeneralName must not be an empty string. Certs that contain extensions that violate these rules are questionable, at best. Mozilla is often merciful to the creators of such certs by ignoring the invalid empty extensions. If mozilla were more forceful in its enforcement of the standards, certs with empty subject alt name extesions would always be invalid. So, the fact that mozilla does not alway overlook the invalid extension in every case does not make mozilla "mistaken". But given that mozilla has chosen to be merciful, it should be consistent. 2. I would say that this "bug" was introduced with the fix for bug 166454, but was masked by bug 174885 until the latter was recently fixed. In any case, I believe the patch above is correct. It is how that line of code should have been written in the first place.
Summary: mistaken "security error: domain name mismatch" when page is opened → "security error: domain name mismatch" when page is opened
Assignee | ||
Comment 9•21 years ago
|
||
Comment on attachment 126781 [details] [diff] [review] Proposed patch r=nelsonb
Attachment #126781 -
Flags: review?(nelsonb) → review+
Assignee | ||
Comment 10•21 years ago
|
||
Checked in Wan-Teh's patch. Checking in certdb/xconst.c; new revision: 1.5; previous revision: 1.4
Status: NEW → RESOLVED
Closed: 21 years ago
Priority: -- → P2
Resolution: --- → FIXED
Target Milestone: --- → 3.9
Comment 11•21 years ago
|
||
Would it make sense to land this patch on the NSS_3_8_BRANCH?
Blocks: stable1.4
Comment 12•21 years ago
|
||
I checked in the patch on the NSS_3_8_BRANCH (NSS 3.8.2) and NSS_CLIENT_TAG (Mozilla 1.5a).
Whiteboard: [3.8.2]
Comment 13•21 years ago
|
||
Patch checked into the NSS_3_7_BRANCH (NSS 3.7.8).
Whiteboard: [3.8.2] → [3.8.2][3.7.8]
You need to log in
before you can comment on or make changes to this bug.
Description
•