Closed Bug 406954 Opened 15 years ago Closed 15 years ago

Unable to add exception for server certificates with empty subject names

Categories

(Core Graveyard :: Security: UI, defect, P2)

x86
All
defect

Tracking

(Not tracked)

RESOLVED FIXED
mozilla1.9

People

(Reporter: marc, Assigned: KaiE)

References

()

Details

Attachments

(2 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b2pre) Gecko/2007120404 Minefield/3.0b2pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b2pre) Gecko/2007120404 Minefield/3.0b2pre

On the page showing the following error:

"
Secure Connection Failed
         
x.x.x.x uses an invalid security certificate.

The certificate is not trusted because the issuer certificate is unknown.
The certificate is only valid for remoteip.

(Error code: sec_error_unknown_issuer)

        


        
        


    *   This could be a problem with the server's configuration, or it could be
      someone trying to impersonate the server.

    *   If you have connected to this server successfully in the past, the error may
      be temporary, and you can try again later.




        
        

          Or you can add an exception…
          

You should not add an exception if you are using an internet connection that you do not trust completely or if you are not used to seeing a warning for this server.
"


It is impossible to add the exception as clicking the "confirm security exception" button on the "add security exception" dialog does nothing.  

Once the button is enabled for clicking by initially viewing the certificate, the button lights up but clicking on it produces no results.



Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Actual Results:  
Clicking the "add security exception" button does nothing.  The exception is not being added.
Component: Preferences → Menus
Flags: blocking-firefox3?
Version: unspecified → Trunk
WFM on today's mac nightly.  Please renominate if someone else can confirm.
Flags: blocking-firefox3?
Keywords: qawanted
Component: Menus → Preferences
Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9b2pre) Gecko/2007121017 Minefield/3.0b2pre

Lights up and works after getting the certificate, not even viewing it.

Reporter, do you have that problem with every site?
Every single site.  The button does light up, but clicking on it does absolutely nothing.
Let me rephrase that.  This problem appears with every single site that requires this procedure (every site that has a certificate that doesn't match the host).

You can reproduce this by connecting to an https site by its IP rather than correct hostname, for example.
I think I can confirm this.

With Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9b3pre) Gecko/2007121417 (Gentoo) Minefield/3.0b3pre when I load a https:// site, where in FF2 the warning dialog would show up the above page will be displayed and there is a link at the bottom, with the target "javascript:showSecuritySection();". Clicking on that link shows the warning "You should not add an exception...", but does nothing else. I have to add the warning then manually by going through the preferences dialog.

What I found out, that this doesn't work with my build above, but, it does work with the nightly builds from mozilla's ftp.
So it seems to be, like some other things (saved login dialog) a build problem.
Ok, I think I've got it. 
It used to use Gentoo's xulrunner+minefield build and that one has this problem, I tested it now with minefield standalone and with that one it works.

So it seems to be a xulrunner or xulrunner+minefield problem and that might be the reason, that some people don't have it.

Marc: Do you use xulrunner?
Hi Bernd,

No.  Not using xulrunner.

Also, I use a nightly build taken directly from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk  which I keep updated roughly every day.

The finding you described while may be related, is not the exact issue I'm seeing.

Once I click the link to 'add an exception...' Two buttons show up: 'Get me out of here!' and 'Add an exception'.   I click 'add an exception' and I'm then presented with a dialog titled 'Add security exception'.   Then, in order to enable the 'Confirm security exception' button, I must first click 'Get certificate' button -- I click it, then the 'Confirm security exception' button becomes clickable (ungrayed), clicking it however produces no result, that's the crux of my issue.

To reproduce, simply connect to any https enabled site through is IP address rather than the host name, you will then be presented with the option to 'add a security exception'.   For example:  https://209.85.135.103
Ok, that is a different issue.

That does work here. So mine is a different issue.
I have this problem as well. using 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2) Gecko/2007121120 Firefox/3.0b2

and
the same build for Mac OS X 10.5.1.

I've only had this problem when using out corporate web site, and trying to get into the Outlook Web Access for my corporate email.  This uses a self assigned certificate, NOT from verisign, etc.  is this similar to others with problems?

In contrast, the example given in comment #7 WORKS fine for me.
WORKSFORME

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b3pre) Gecko/2008012104 Minefield/3.0b3pre

Kubuntu 7.10
I can confirm the problem.

Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9b4) Gecko/2008030714 Firefox/3.0b4

It happens with an auto-signed certificate on a local network.
the certificate error is : sec_error_ca_cert_invalid

The button becomes activated once the certificate is fetched, but nothing happens when it is clicked.


Can I do anything to help ?

[sorry for double post]

My problem is exactly the same as the one described in comment #9 (including the fact that example of post #7 works for me).
Just adding a note that I am hitting the same problem on WIN 32 XP SP2 with FF 3.0b4 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9b4) Gecko/2008030714 Firefox/3.0b4)

I am getting the same Secure Connection Failed page (certificate is delievered by a tomcat server for a range of ip addresses for our internal testing of product X):

Clicking Add Exception opens dialog box after which the symptoms are the same as in Comment #11 above.

I would be happy to provide any other information / run tests needed.

Cheers!

Mansoor
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008032204 Minefield/3.0b5pre ID:2008032204

boguh on freenode #firefox has this problem and talked me through reproducing it, so I'm confirming this and renominating.

1. New profile, start firefox
2. Visit https://depend.cs.uni-sb.de/cms/login.php. You get shown the "Secure Connection Failed (Error code: sec_error_unknown_issuer)" error page.
3. Click "Or you can add an exception..."
4. Click "Add exception..."
5. Click "Get Certificate..."
6. Click "Confirm Security Exception"

Expected:
- Dialog disappears and security exception is added

Actual:
- Button is pressed but nothing happens. The only way to dismiss the dialog is with the Cancel button or the window close [x] icon and in both these cases an exception is not added. Website can still not be visited because of the error page "Secure Connection Failed | depend.cs.uni-sb.de uses an invalid security certificate. | The certificate is not trusted because the issuer certificate is unknown. | (Error code: sec_error_unknown_issuer)".
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking-firefox3?
OS: Linux → All
Every time I do step 5 (Click "Get Certificate") the error console reports:

Error: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIXMLHttpRequest.send]
Source file: chrome://pippki/content/exceptionDialog.js
Line: 151

Which looks like bug 408697, so maybe that bug's title is wrong ;)
Johnath, Kaie: any hints?
Assignee: nobody → kengert
Component: Preferences → Security: UI
Flags: blocking-firefox3?
Product: Firefox → Core
QA Contact: preferences → ui
Flags: blocking1.9?
There is some confusion here with people describing different problems, but I believe the original, verified complaint is summed up by comment 14 (thanks stevee!)

I can confirm this on my trunk build for the link provided, even though other links that present the same error page (e.g. https://www.cacert.org/) work fine.

I can further confirm that on a site like the uni-sb.de link above, code execution does enter the addException function here:

http://mxr.mozilla.org/mozilla/source/security/manager/pki/resources/content/exceptionDialog.js#150

But fails on the call to the override service, here:

http://mxr.mozilla.org/mozilla/source/security/manager/pki/resources/content/exceptionDialog.js#343

No exception is logged that I can see, but execution (as confirmed with alert()s sprinkled liberally) doesn't get past that point for this certificate.  For cacert, it does.

Therefore, I suspect there's something broken about the way we handle this certificate.  As an obvious candidate/symptom, opening this certificate in the viewer shows no CN, O, or OU fields, and no certificate chain in the details view.

Over to Kai for why exactly this happens.  A decision about whether or not it blocks is probably dependent on whether we think this is isolated, but given the number of commenters, my sense is that we should at least block pending more investigation.  I don't think we want to ship without at least understanding this problem.
Given comment 17 moving to the blocking list...
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
Additional observation:
Recreated the problem as presented by Comment #14, but in scenario of two FF3b4 windows being opened (meaning a new window after using CTRL+N).

Exception for Expired Certificate (https://depend.cs.uni-sb.de/cms/login.php) can be added from the first (original) FF window, but not from the second. When try to add the exception from the second FF window there is no response to either of the two buttons ('get me out of here', 'add exception').

When I opened a third FF window I can add the exception rule once again. Yet the second window would still not add the exception rule.
append:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9b4)
Gecko/2008030714 Firefox/3.0b4
Attached patch Draft solution (obsolete) — Splinter Review
This is just draft how we may solve this problem with freeze (not with import its self). I had to add new error code/message to handle import failure.

Problem with the certificate of https://depend.cs.uni-sb.de/ is incorrectly formatted or missing DN (certutil says !Invalid AVA! - http://lxr.mozilla.org/mozilla/source/security/nss/cmd/lib/secutil.c#2300). I will take a closer look at this too.

I can't reproduce the problem according to comment 7 (using IP as the server address). However this should be universal fix. I am only curious why there were not any report in the error console.

This patch changes locales.

Still TODO:
- consider if we need more errors to recognize reason of the failure.
- change appropriately the way how the error is reported to the user
Assignee: kengert → honzab
Status: NEW → ASSIGNED
Keywords: late-l10n
Honza we making progress on this?
The patch I provide avoids stuck of the button, but it needs to finish the way how error is reported, probably. I was waiting for some reaction on that patch. I will ask Kaie directly.
Comment on attachment 312893 [details] [diff] [review]
Draft solution

Please read Comment #21 for details on this patch. It is just a draft but simply solves the primary problem.
Attachment #312893 - Flags: review?(kengert)
Problem with the certificate is follows: subject sequence is completely missing (is empty), ASN.1 decoders say: SEQUENCE {} where subject should be present. Other solution to handle this somehow is to extend nsNSSCertificate::defaultServerNickname of lookup also AltNames extension to pick a name for the server cert. Not sure this is correct and if it won't lead to security implications.
(In reply to comment #25)
> Problem with the certificate is follows: subject sequence is completely missing
> (is empty), ASN.1 decoders say: SEQUENCE {} where subject should be present.
> Other solution to handle this somehow is to extend
> nsNSSCertificate::defaultServerNickname of lookup also AltNames extension to
> pick a name for the server cert. Not sure this is correct and if it won't lead
> to security implications.

I think as a last-ditch nickname alternate, it should be just as trustworthy as the other fields in an attested cert.  I think this would solve the problem above without the need for string changes or different error handling code, too.

Kai, what do you think?
Whiteboard: [needs review kai]
I don't understand what the real problem is that prevents the "confirm" button from working. I guess it is the problem that Honza mentions in comment 21?

I don't understand how the attached patch fixes the problem.

All I can see are attempts to improve the error message.
Comment on attachment 312893 [details] [diff] [review]
Draft solution

The only thing this patch does: Instead of silently doing nothing, we'll now show an error message "can not import cert".

I think that's not the solution for this bug.

other problems:
- we can not add new error messages at this point
- the patch mixes NSS and PSM, it does not respect they are separate projects
Attachment #312893 - Flags: review?(kengert) → review-
Whiteboard: [needs review kai]
Changing summary to describe the real bug.
Summary: "Confirm security exception" button on the "Add security exception" dialog is not responsive → Unable to add exception for server certificates that do not have any name fields
So, my first reaction to this bug was, "yes, let's fix nickname creation and have it lookup the data in the SAN".

However, that might become tricky. What if SAN contains no DNS name? Nelson explains to me, that might be valid. And there might be around 10 potential other fields that we might have to look at for nickname creation. This sounds tricky.

Also, Nelson thinks there might be issues when trying to import a cert into the NSS storage if the cert has an empty subject.

So, here is an alternative proposal:

If are unable to derive a nickname with the existing logic (look at fields in subject name), then we will not import the cert into the NSS db.

Yes, it's not absolutely necessary to have the cert stored. It's nice to have it around, so the user can look at it in cert manager, but it's not required for adding an exception.

Adding the exception is based on cert's issuer/serial/hash.
Attached patch Patch v2Splinter Review
This patch works for me.
It skips importing the full cert, but allows to add the exception anyway (based on issuer/serial/hash/hostname/port).
Attachment #312893 - Attachment is obsolete: true
Attachment #317424 - Flags: review?(rrelyea)
Summary: Unable to add exception for server certificates that do not have any name fields → Unable to add exception for server certificates with empty subject names
Comment on attachment 317424 [details] [diff] [review]
Patch v2

r+ rrelyea
Attachment #317424 - Flags: review?(rrelyea) → review+
Attachment #317424 - Flags: approval1.9?
Comment on attachment 317424 [details] [diff] [review]
Patch v2

a=shaver
Attachment #317424 - Flags: approval1.9? → approval1.9+
Assignee: honzab → kengert
Status: ASSIGNED → NEW
checked in, marking fixed
Status: NEW → RESOLVED
Closed: 15 years ago
Keywords: late-l10n, qawanted
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.