User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:184.108.40.206) Gecko/20061201 Firefox/220.127.116.11 (Ubuntu-feisty) Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:18.104.22.168) Gecko/20061201 Firefox/22.214.171.124 (Ubuntu-feisty) Although the CN in the certificate matches the hostname, Firefox complains that the certificate belongs to a different host, although the names match *exactly*. Neither Konqueror nor Opera complain about this, so the certificate doesn't seem to be (entirely) broken. Reproducible: Always Steps to Reproduce: 1. Go to https://mail.probusiness.de/ 2. Accept the unverified certificate 3. Now you get the error about mail.probusiness.de != mail.probusiness.de Expected Results: The certificate should be accepted, as the hostname matches the CN in the cert.
Problem also started with newest release of FireFox for our domain's SSL: https://www.spamlion.com SSL is from Network Solutions, and has had no problems with all prior certs over the last 11 years.
Comment 1 is incorrect, older versions of Firefox also have a problem with the current https://www.spamlion.com server. you need to configure your server to serve the intermediate certificates that chain to a root. This is a completely different problem from the first issue in this bug, and you should see support from your CA. I can confirm the original problem. It is not "new", Firefox 126.96.36.199 and FF 1.0.7 exhibits the same behavior. The cert CN does appear to match the address in the location bar, perhaps it is misreporting the actual detected error.
Sorry, my mistake - added the root and intermediate certificates that came with the regular SSL cert, and it works just like you said. "MY PROBLEM" is that for the last 11 years I've not had to do this (also register the intermediate certificates), as it's new within the last year or so? Always something new... THANKS for the correction of my error. Does this mean that the original listing of this bug for mail.probusiness.de is also in error, and Fridtjof Busse simply needs to also register his intermediate certificates?
I am unfamiliar with CA-Hannover and who they might chain to; it's possible intermediates would help with the initial recognition (probably not, IE doesn't recognize it either and Mr. Busse didn't complain about that part). The bug is about the fact that Firefox complains that the name in the cert (mail.probusiness.de) doesn't match the apparently identical site name mail.probusiness.de
(In reply to comment #3) > Does this mean that the original listing of this bug for mail.probusiness.de > is also in error, and Fridtjof Busse simply needs to also register his > intermediate certificates? No - it's a different problem. The certificate for mail.probusiness.de has a bogus subjectAltName extension, as shown by this output from pp: > Name: Certificate Subject Alt Name > Error: Parsing extension: security library: improperly formatted DER-encoded message. > Data: > 41 > A And derdump shows: > 30 C-Sequence 08 (8) > 06 Object Identifier 03 (3) > 2 5 29 17 (Certificate Subject Alt Name) > 55 1d 11 > 04 Octet String 01 (1) > 41 In contrast to most other implementations, NSS will *only* use the subjectAltName extension for host name checking, if it is present (it will ignore the CN from the subject in this case). This is the reason for the pretty strange error message you get with Firefox. The simplest solution for the mail.probusiness.de site is to reissue a certificate with either 1) a correct subjectAltName extension or 2) no such extension at all. See also bug 159483 comment 6 (item a)) for additional background.
I agree that the certificate is somewhat broken. However, other browsers can handle this and the error displayed is definitly very misleading.
I think is INVALID. The cert is broken, but it's possible to add an override (in Firefox 3).
This bug shows that NSS is not working as intended, so I'm opening it and changing it into an NSS bug. RFC 2818 says: 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. The key phrase here is "of type dNSName". NSS intends to implement the rules quoted above exactly. The intent is that when a cert contains a SAN extension of type dNSName, NSS will use the DNS Names contained in that extension EXCLUSIVELY, and will not also honor the most specific Common Name field. But NSS actually just checks to see of the extension is present at all, and if so, it skips the CN test, even if the SAN contains no dNSName. That's a bug.
Medium priority, not a stopper for 3.12
Created attachment 311932 [details] [diff] [review] untested patch v1 I think this patch should do it. Basically, if we have any problems decoding the cert, we report extension_not_found, which causes the (only) caller to behave as if the extension was not found, and hence honor the subject CN. Kai or Kaspar, feel free to review. :)
Comment on attachment 311932 [details] [diff] [review] untested patch v1 Wan-teh, will you review this small patch?
Comment on attachment 311932 [details] [diff] [review] untested patch v1 Two of the "goto finish" statements you changed should remain "goto finish". If PORT_NewArena or PORT_ArenaAlloc fails and we goto fail, we will lose the more correct SEC_ERROR_NO_MEMORY error code. If CERT_FindCertExtension fails, the error code should already be the desired SEC_ERROR_EXTENSION_NOT_FOUND. So it seems that the only necessary change is the goto after the failure of CERT_DecodeAltNameExtension. There we probably should also filter the SEC_ERROR_NO_MEMORY error.
Wan-Teh, the fact that this patch causes SEC_ERROR_NO_MEMORY to be changed to SEC_ERROR_EXTENSION_NOT_FOUND in some cases is deliberate. It is to get the caller of this function to take the path of execution that it takes only when the error code is SEC_ERROR_EXTENSION_NOT_FOUND. If CERT_DecodeAltNameExtension fails, SEC_ERROR_EXTENSION_NOT_FOUND is ONE of the possible errors it may return, but there are also other error codes it could return. In all cases where the result is that the code is unable to find and process a DNS name or IP address alt name, regardless of the cause, I want the caller of this function to behave as if no SAN extension bearing DNS names (or IP address) was found. see http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/certdb/certdb.c&rev=1.91#1844 Does that change your review?
Comment on attachment 311932 [details] [diff] [review] untested patch v1 Nelson, do you really want different certificate verification results, depending on whether we run out of memory or not? If you're willing to use the CN in the Subject when you run out of memory, why don't you use it when there is memory? Since the out-of-memory condition is exceptional, I won't dwell on this issue.
Checking in certdb.c; new revision: 1.92; previous revision: 1.91