Closed
Bug 408432
Opened 16 years ago
Closed 15 years ago
Add Exception fails for certs with no DNS names (no CN, no SAN)
Categories
(Core :: Security: PSM, defect, P4)
Tracking
()
VERIFIED
FIXED
mozilla1.9beta3
People
(Reporter: marcia, Assigned: KaiE)
References
()
Details
Attachments
(1 file, 1 obsolete file)
9.24 KB,
patch
|
Details | Diff | Splinter Review |
Seen while testing Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b2) Gecko/2007121014 Firefox/3.0b2. Reported via hendrix. STR: 1. Visit the URL above and try to add an exception. Expected: I would be able to add an exception and access the site. Actual: Clicking "Confirm Exception" does not dismiss dialog.
Comment 1•16 years ago
|
||
the JS Error Message is Error: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIXMLHttpRequest.send]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://pippki/content/exceptionDialog.js :: checkCert :: line 151" data: no] Source File: chrome://pippki/content/exceptionDialog.js Line: 157
Summary: Unable to add a security exception to this page → Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIXMLHttpRequest.send] - Unable to add a security exception to this page
Updated•16 years ago
|
Assignee: nobody → kengert
Component: Security → Security: PSM
Product: Firefox → Core
QA Contact: firefox → psm
Assignee | ||
Comment 2•16 years ago
|
||
The error page for this URL (in the browser window) says "Only valid for ." Note there is no name shown. This makes me believe the code that tries to find the valid names if failing.
Assignee | ||
Comment 3•16 years ago
|
||
Ok, there is no error in find the names contained in that cert. There are no names :-) Certificate is missing the CN field (common name), and it does not have a subjectAltName extension either.
Assignee | ||
Comment 4•16 years ago
|
||
This is a weird edge case. Because this server cert has neither CN nor SAN, PSM's code to produce a nickname fails. PSM currently fails if CERT_GetCommonName returns NULL. The server cert can never work without an exception, because the domain match test will always fail. But given that we support exception for bad certs, should we allow that? I guess PSM should implement a fallback strategy for the scenario that CERT_GetCommonName returns NULL.
Summary: Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIXMLHttpRequest.send] - Unable to add a security exception to this page → Add Exception fails for certs with no DNS names (no CN, no SAN)
Assignee | ||
Comment 5•16 years ago
|
||
(In reply to comment #2) > The error page for this URL (in the browser window) says "Only valid for ." Should we introduce a new separate error string like this? "This certificate is not valid for any server names"
Assignee | ||
Comment 6•16 years ago
|
||
This patch fixes the bug and improves the error message.
Attachment #293237 -
Flags: review?(rrelyea)
Comment 7•16 years ago
|
||
Comment on attachment 293237 [details] [diff] [review] Patch v1 >+ // Certs without nicknames are strange, but they do exist... >+ // Let's try to use another string for the nickname >+ servername = CERT_GetOrgUnitName(&cert->subject); >+ if (!servername) { >+ servername = CERT_GetOrgName(&cert->subject); >+ if (!servername) { >+ servername = CERT_GetLocalityName(&cert->subject); >+ if (!servername) { >+ servername = CERT_GetStateName(&cert->subject); >+ if (!servername) { >+ servername = CERT_GetCountryName(&cert->subject); I think it is never valid to consider that a any of those names (OU, O, L, S, C) could be a server name. The CAs do not expect those values to be used as server names, and therefore are under no obligation to ensure that the strings in those names are domain names that belong to the subject. We may or may not wish to allow certs with no server names to be used as SSL server certs in exceptions, but the presence or absence of (OU, O, L, S, C) names should have no effect on that decision.
Assignee | ||
Comment 8•16 years ago
|
||
(In reply to comment #7) > I think it is never valid to consider that a any of those names > (OU, O, L, S, C) could be a server name. Sure. This code is nothing but an attempt to find a nickname string that could be used when importing the cert into NSS' database. A string that's better than a random string. > We may or may not wish to allow certs with no server names to be used > as SSL server certs in exceptions, but the presence or absence of (OU, > O, L, S, C) names should have no effect on that decision. Does that mean, certs with an empty subject name are allowed? If empty subject names are not allowed, what is the full set of subject name components we could check, to ensure, we'll find at least one valid string? (to find something for the nickname). Alternatively, if the above leads to complicated research, we might just use a random string... Maybe involving the serial number string... Ideas welcome.
Comment 9•16 years ago
|
||
ok, so I was slightly mislead by the name of the variable "servername".
Perhaps it should be "nickname" or "potentialNickName" or "nicknameCandidate".
> Does that mean, certs with an empty subject name are allowed?
Yes, they are allowed, although I have never seen one in practice.
A cert may have a non-empty SAN and an empty Subject Name.
Subject Alt Names can take many forms. So, one could have a certificate
with no subject name and an SAN that consists only of an IP address,
in theory. But again, I've never seen a live cert with no subject name.
Comment 10•16 years ago
|
||
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b3pre) Gecko/2007121602 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4) Confirming bug with SeaMonkey and Windows. (In reply to comment #1) > the JS Error Message is Error: [Exception... "Component returned failure code: > 0x80004005 (NS_ERROR_FAILURE) [nsIXMLHttpRequest.send]" nsresult: "0x80004005 > (NS_ERROR_FAILURE)" location: "JS frame :: > chrome://pippki/content/exceptionDialog.js :: checkCert :: line 151" data: no] > Source File: chrome://pippki/content/exceptionDialog.js > Line: 157 Same exception with <https://gmail.com/>, which has a CN value. Should that be filed as a separate bug ?
OS: Mac OS X → All
Updated•16 years ago
|
Flags: blocking1.9?
Comment 11•16 years ago
|
||
(In reply to comment #10) > [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b3pre) Gecko/2007121602 > SeaMonkey/2.0a1pre] (nightly) (W2Ksp4) > > Confirming bug with SeaMonkey and Windows. > > (In reply to comment #1) > > the JS Error Message is Error: [Exception... "Component returned failure code: > > 0x80004005 (NS_ERROR_FAILURE) [nsIXMLHttpRequest.send]" nsresult: "0x80004005 > > (NS_ERROR_FAILURE)" location: "JS frame :: > > chrome://pippki/content/exceptionDialog.js :: checkCert :: line 151" data: no] > > Source File: chrome://pippki/content/exceptionDialog.js > > Line: 157 > > Same exception with <https://gmail.com/>, which has a CN value. > > Should that be filed as a separate bug ? The exception is behaving as-designed (strange as that may seem). See here: http://mxr.mozilla.org/mozilla/source/security/manager/pki/resources/content/exceptionDialog.js#157 The bug about the exception dialog also failing to add exceptions/dismiss properly is valid, and fixing it in PSM should fix Seamonkey as well, but seeing the exception logged for, e.g., gmail.com is behaviour as expected. Though, if you found it really confusing, you might file a bug on improving the log message there, to say something about it being expected - or maybe logging it differently altogether?
Comment 12•16 years ago
|
||
(In reply to comment #11) > The bug about the exception dialog also failing to add exceptions/dismiss > properly is valid, and fixing it in PSM should fix Seamonkey as well, but (Yes.) > seeing the exception logged for, e.g., gmail.com is behaviour as expected. > Though, if you found it really confusing, you might file a bug on improving the > log message there, to say something about it being expected - or maybe logging > it differently altogether? Filed bug 408697.
Comment 13•16 years ago
|
||
+'ing with a P4. A big problem here is that the exception dialog cannot be dismissed.
Flags: blocking1.9? → blocking1.9+
Priority: -- → P4
Assignee | ||
Comment 14•16 years ago
|
||
(In reply to comment #13) > +'ing with a P4. A big problem here is that the exception dialog cannot be > dismissed. I am able to use cancel in that dialog. And you? Only "confirm" is broken for me.
Reporter | ||
Comment 15•16 years ago
|
||
Kai: I am able to cancel out of that dialog on Mac. (In reply to comment #14) > (In reply to comment #13) > > +'ing with a P4. A big problem here is that the exception dialog cannot be > > dismissed. > > I am able to use cancel in that dialog. And you? > > Only "confirm" is broken for me. >
Comment 16•16 years ago
|
||
(In reply to comment #14) > I am able to use cancel in that dialog. And you? [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b3pre) Gecko/2007121802 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4) Yes, the 'Cancel' button works; but the 'Confirm ...' button does not, which is why I asked for 'blocking1.9'.
Comment 17•15 years ago
|
||
Comment on attachment 293237 [details] [diff] [review] Patch v1 r+ but please fix the following comment: > // Certs without nicknames are strange, but they do exist... > // Let's try to use another string for the nickname Change 'nickname' got 'common name' in each case here. bob
Attachment #293237 -
Flags: review?(rrelyea) → review+
Comment 18•15 years ago
|
||
^got^to
Assignee | ||
Comment 19•15 years ago
|
||
Assignee | ||
Comment 20•15 years ago
|
||
fixed
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Updated•15 years ago
|
Attachment #293237 -
Attachment is obsolete: true
Reporter | ||
Comment 21•15 years ago
|
||
verified fixed using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b3pre) Gecko/2008012504 Minefield/3.0b3pre - I now get this error when I try to add an exception - "The certificate is not trusted because the issuer certificate is unknown. The certificate is not valid for any server names." I am able to add an exception for that site as well.
Status: RESOLVED → VERIFIED
Comment 22•15 years ago
|
||
Groovy
Updated•15 years ago
|
Comment 23•15 years ago
|
||
FTR, <https://webmail.ug.bilkent.edu.tr/bcc/src/login.php> certificate has been fixed on 07/02/2008: it has a CN = "*.bilkent.edu.tr" now. Then, instead of "The certificate is not valid for any server names.", we get "The certificate is not trusted because the issuer certificate is unknown. / sec_error_unknown_issuer" (in the XUL error page) now. Only to say that we can't use it to testcase this bug anymore :-|
Target Milestone: --- → mozilla1.9beta3
Comment 24•15 years ago
|
||
In the last few weeks, at least one commercial CA trusted by Mozilla has reported that he believes it is "common practice" to issue certs with OU names that have not been verified IN ANY WAY. At least one other CA has confirmed that they, too, do not verify OU names. Consequently, I think it would be good for Mozilla products to NOT display OU contents to users for use as certificate identifiers, or for use in dialogs or pages that may ask the user to make a security relevant decision. I add this comment to this bug because this bug has just recently added code that attempts to choose a name to display to the user, and OU is the first name that it tries for that purpose.
You need to log in
before you can comment on or make changes to this bug.
Description
•