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)

1.0 Branch
x86
Linux
defect

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.
I cannot reproduce the error. moz 2002081508
Confirming on 8/19 Win2000 trunk build.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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
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
I believe Nelson has implemented the correct way of finding the host name in a cert. This may be related.
Assignee: ssaux → kaie
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.
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
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.
Marking fixed, since the bugs this depends on are fixed.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Verified.
Status: RESOLVED → VERIFIED
Product: PSM → Core
Version: psm2.4 → 1.0 Branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.