Closed
Bug 162979
Opened 23 years ago
Closed 22 years ago
"Domain Name Mismatch" pop-up with no apparent mismatch
Categories
(Core Graveyard :: Security: UI, defect, P3)
Tracking
(Not tracked)
VERIFIED
FIXED
psm2.4
People
(Reporter: dkindred+mozilla, Assigned: KaiE)
References
()
Details
(Keywords: regression)
BuildID: 2002081418
In some circumstances, the "domain name mismatch" alert appears, but the two
domain names given appear to be identical.
To reproduce:
1. visit https://zarchive.srv.cs.cmu.edu/
2. get "Website Certified by an Unknown Authority" pop-up, click Continue
3. get "Security Error: Domain Name Mismatch" pop-up
(There's an extra space before "Mismatch" as reported in Bug 100129.)
The message in the pop-up starts,
You have attempted to establish a connection with
"zarchive.srv.cs.cmu.edu". However, the security certificate
presented belongs to "zarchive.srv.cs.cmu.edu". [...]
Note that the two domain names given are identical.
Comment 1•23 years ago
|
||
I cannot reproduce the error. moz 2002081508
Comment 2•22 years ago
|
||
Confirming on 8/19 Win2000 trunk build.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 3•22 years ago
|
||
This is not happening with the 8/21 Win2000 branch build. The issuer's CN and
OU are the same, if that is a clue (ZIMBS CA)
Priority: -- → P3
Target Milestone: --- → 2.4
Version: unspecified → 2.4
Assignee | ||
Comment 4•22 years ago
|
||
Julien, could you please have a look?
This looks like a regression caused by broken or new unexpected behaviour of NSS?
We call:
CERT_VerifyCertName
=> cert_VerifySubjectAltName
=> CERT_DecodeAltNameExtension
calls:
=> SEC_ASN1DecodeItem
=> SEC_ASN1Decode
but nothing gets filled into the encodeContext
looks like the item contains "0"
Next it calls
=> cert_DecodeGeneralNames
which fails because of a null paramter
with PR_INVALID_ARGUMENT_ERROR
Back in PSM, we assume any error returned from NSS
means a domain mismatch error and display the message.
Keywords: regression
Comment 5•22 years ago
|
||
I believe Nelson has implemented the correct way of finding the host name in a
cert. This may be related.
Assignee: ssaux → kaie
Comment 6•22 years ago
|
||
Several comments.
1. The "0" character marks the beginning of an ASN.1 SEQUENCE.
2. This certificate contains a Subject Alternative Name extension that is
empty; that is, the ASN.1 SEQUENCE of GeneralName is empty. The
SubjectAltName extension contains NO GeneralName. This violates RFC 3280's
requirements for SubjectAlternativeName extensions, which says (page 35):
If the subjectAltName extension is present, the sequence MUST contain
at least one entry.
and
SubjectAltName ::= GeneralNames
GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
3. The NSS functions CERT_DecodeAltNameExtension and cert_DecodeGeneralNames
do not set any error code when the decoded GeneralNames sequence is empty.
They return NULL, which indicates either that (a) an error occurred while
decoding the extension, such as out of memory or invalid DER encoding, or
(b) no error occurred but the extension was empty. If an error occured,
then an error code is set, but if the extension was empty, no error code
is set, and consequently, whatever old error code was last set remains set.
Kai reported that cert_DecodeGeneralNames fails because of a null parameter
with PR_INVALID_ARGUMENT_ERROR. But it appears to me that it fails without
setting any error code. So that error code must have been set before this
function was called. I think it _should_ set that error code.
4. RFC 2818 says (page 5)
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.
This suggests that if a subjectAltName extension is present, but it
contains NO dnsName, then the CommonName field should be used. NSS
does exactly that when the subjectAltName extension contains at least
one GeneralName, but not when subjectAltName contains NO GeneralName.
5. IE 5.5 reports that the certificate name matches, but is issued by
an unrecognized issuer.
Despite the requirement in RFC 3280 that these extensions must not be
empty, I think NSS should treat empty subjectAltName extensions as
absent subjectAltName extensions. To effect this policy, changes must
be made to several functions, including
CERT_DecodeAltNameExtension
CERT_GetCertificateNames
and perhaps
CERT_GetCertificateEmailAddress
So, I propose to change CERT_DecodeAltNameExtension to check for an empty
sequence (NULL value in encodedContext.encodedGenName) and set the error
code SEC_ERROR_EXTENSION_NOT_FOUND if it is empty.
I also propose to change CERT_GetCertificateNames to return DN, rather
than NULL, when CERT_DecodeAltNameExtension returns NULL.
I will file a separate NSS bug about these issues.
Assignee | ||
Comment 7•22 years ago
|
||
If I understand correctly, Nelson fixed this problem with his checkins to NSS.
As we are not yet using the fixed version of NSS, I'm making this bug dependent
on the "switch to NSS 3.6" bug.
Depends on: nssclienttag36
Comment 8•22 years ago
|
||
The bug was reported 8/15/02, but as of 9/12/02,
https://zarchive.srv.cs.cmu.edu/ has a new server cert, so I cannot reproduce
the bug.
Comment 9•22 years ago
|
||
Marking fixed, since the bugs this depends on are fixed.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
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
•