Closed Bug 408432 Opened 17 years ago Closed 16 years ago

Add Exception fails for certs with no DNS names (no CN, no SAN)

Categories

(Core :: Security: PSM, defect, P4)

x86
All
defect

Tracking

()

VERIFIED FIXED
mozilla1.9beta3

People

(Reporter: marcia, Assigned: KaiE)

References

()

Details

Attachments

(1 file, 1 obsolete file)

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.
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
Assignee: nobody → kengert
Component: Security → Security: PSM
Product: Firefox → Core
QA Contact: firefox → psm
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.
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.
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)
(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"
Attached patch Patch v1 (obsolete) — Splinter Review
This patch fixes the bug and improves the error message.
Attachment #293237 - Flags: review?(rrelyea)
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.
(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.
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.
[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
Flags: blocking1.9?
(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?

(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.
+'ing with a P4.  A big problem here is that the exception dialog cannot be dismissed.
Flags: blocking1.9? → blocking1.9+
Priority: -- → P4
(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.
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.
> 

(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 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+
^got^to
fixed
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Attachment #293237 - Attachment is obsolete: true
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
Blocks: 423002
No longer blocks: 423002
Depends on: 423002
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
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.