User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b1) Gecko/2007110904 Firefox/3.0b1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b1) Gecko/2007110904 Firefox/3.0b1 I'm trying to open a page with a self signed certificate. In 3.0 Beta1 firefox don't give opportunity to open the page with error code "The certificate is not trusted because it is self signed" (Error code: sec_error_ca_cert_invalid) Reproducible: Always Steps to Reproduce: 1. 2. 3. Expected Results: open the page ;)
do you have a url, can you post the url to this bug? Can you add a exception for this site ?
Sascha, when you see the error message "ntranet.magicinternet.de uses an invalid security certificate"..... there is down on this error message in blue a text "Or you can add an exception…" Click on this and then on "add exception"...follow this dialog and you can access your site.
Carsten, I don't have this blue text. Posted the Alert Box screenshot as attachment.
hm, do you use different themes ? On a Clean Profile with Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9b1) Gecko/2007110904 Firefox/3.0b1 i get the error message with the add expection button, see screenshot. Can you disable this themes and change to default or try to to start Firefox in a new Profile http://kb.mozillazine.org/Profile_Manager ?
No themes in firefox at all, but in windows I use official microsoft theme "royal noir". With your screenshot, I recognized that you use browser.xul.error_pages.enabled in about:config. I also enabled this feature - and voila I can add the exception for my page. With Alert Boxes for error Messages, this is not possible. So it's really a bug, and we found a workaround right now. Thanks for your help! Regards Sascha
i don`t think its a bug. browser.xul.error_pages.enabled is set to true by default and if you change this you maybe see only this pop up and not the error page. In any case when you want to add a expection manually, you can do this via Options -> Advanced -> Encryption Settings->View Certs->Add server exception Resolving as works for me, since this is also now working for you.
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
Version: unspecified → Trunk
We just had a long discussion about this bug in the MozillaZine forums <http://forums.mozillazine.org/viewtopic.php?t=634651&start=45>. I'm reopening so we can get this bug fixed and avoid more of the same after Firefox 3 is released.
Severity: major → minor
Status: RESOLVED → UNCONFIRMED
Component: General → Security
Resolution: WORKSFORME → ---
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: general → firefox
Summary: Error code: sec_error_ca_cert_invalid, The certificate is not trusted because it is self signed, Page can not be opened → Page with certificate error cannot be opened when browser.xul.error_pages.enabled is false
What's to fix? If you've disabled the nice error pages we've created to walk people through it you get what you get. It's still possible to create the exception through the UI, it's just harder to get there. Why are people ending up with xul error pages disabled, anyway?
I don't know why it's happening, but it is. When it does, users cannot figure out how to access the site by adding the exception manually. For the sake of these users and those who need to support them, why not just add a button to the dialog box to guide users through adding the exception?
> Why are people ending up with xul error pages disabled, anyway? Can't speak for everyone, but as a developer, I always disable the fancy error pages, particularly the 404-type "helper" ones, as I need to see exactly what the server is spitting out. Without the error being hidden behind useless (for me) lipstick and mascara. In practical terms, this bug is forcing different behavior on people who choose to receive problem reports in an unvarnished format. Why provide a link to a walk-through wizard on the XUL error page, but not even hint at the existence of such a wizard (or the manual method) on the non-XUL error popup? At least provide a link that pops up Tools->Options->Advanced->View Certificates->Servers->Add Exception, or mentions how to get there. That would provide for some parity in functionality between the 'pretty' and 'ugly' versions of the error message.
(In reply to comment #13) > Can't speak for everyone, but as a developer, I always disable the fancy error > pages, particularly the 404-type "helper" ones, as I need to see exactly what > the server is spitting out. That's Internet Explorer. Firefox always shows you the server response if there is one, the "fancy" error pages are only shown for connection errors and the like.
(In reply to comment #10) > Why are people ending up with xul error pages disabled, anyway? Because using error pages means you cannot always restore the state properly on the previous page. If I have a web form with all kinds of data in it, attempt to submit, and get a reset connection, why do I want an error page that will not restore my state properly in the web form? If the XUL error pages could preserve state in all cases, I would use them.
As I mentioned in my dup bug (449099), this isn't a logical leap to key off browser.xul.error_pages.expert_bad_cert == true --- just as the error pages UI does. if (browser.xul.error_pages.expert_bad_cert == true) displayAddException(...); else displayAlert(...);
browser.xul.error_pages.enabled has no effect for certificate errors if an SSL Proxy is in use.
Not wanted for 1.9.0.x since this is an edge case.
Flags: wanted1.9.0.x? → wanted1.9.0.x-
Summary: This bug proposes to enhance the usability of the cert errors and the cert error reporting and adding cert error exceptions, when the cert error pages are not used. While this is an edge case scenario for the browser, it fully applies to all non-browser environments, where SSL is being used for loading non-browser content. There is a design proposal how to solve this, using a status bar indicator, where you can find recent bad certs and navigate to adding overrides. Regarding the proposal to simply add a button that goes to the add exception dialog. People have argued we shouldn't do that, because it's a simple click-through, which is frowned upon.
Whiteboard: [psm-cert-errors][summary comment 20]
Summary: Page with certificate error cannot be opened when browser.xul.error_pages.enabled is false → Improve usability of certificate error handling when browser.xul.error_pages.enabled is false
If I select a link to a URI that has a non-existent domain, I do not want "nice error pages". I want an error popup (see attachment "Error popup for bad domain") that I can dismiss and then fix the URI in the address area. In that process, I want the page that contained the bad URI to remain visible without having to use the Back button. It is for that reason I set browser.xul.error_pages.enabled to "false". The problem is that the responses to two unrelated errors are both controlled by the same preference variable.
Instead of Firefox/Security, does this not belong in Core/Security UI?
(In reply to comment #23) > Instead of Firefox/Security, does this not belong in Core/Security UI? That's a clear "No". All handling for preference browser.xul.error_pages.enabled is strictly located in the Firefox product source code directory mozilla/browser. The Core security module (PSM, security/manager), does not deal with this. Instead, it implements a default behaviour (shows an error dialog). The Firefox product overrides this behaviour to show an error page. Error pages is a mechanism that requires a page - and many Mozilla based products do not have the concept of displaying a page or content area as the primary interaction with the user.
Grumble. I should read carefully before commenting. Obviously this bug is about "disabled error pages", so it is about the default implemented by PSM. Based on that, I agree with comment 23.
Component: Security → Security: UI
Product: Firefox → Core
QA Contact: firefox → ui
(In reply to Kai Engert (:kaie) from comment #20) > There is a design proposal how to solve this, using a status bar indicator, > where you can find recent bad certs and navigate to adding overrides. What's the latest regarding this redesign?
(In reply to Elbart from comment #26) > (In reply to Kai Engert (:kaie) from comment #20) > > There is a design proposal how to solve this, using a status bar indicator, > > where you can find recent bad certs and navigate to adding overrides. > > What's the latest regarding this redesign? The status bar is gone in Firefox. Also, after many years of error pages being the default, and certificate errors causing sub-resources to silently not load, which seems to also be the behavior of other browsers, I think we can safely conclude that the default behavior is not significantly problematic. Consequently, I propose we resolve this bug by removing support for browser.xul.error_pages.enabled=false, which will result in anybody that has browser.xul.error_pages.enabled=false getting the cert error page, which is, overall, the better UI.
(In reply to Brian Smith (:briansmith, was :bsmith; NEEDINFO? for response) from comment #27) > Consequently, I propose we resolve this bug by removing support for > browser.xul.error_pages.enabled=false, which will result in anybody that has > browser.xul.error_pages.enabled=false getting the cert error page, which is, > overall, the better UI. Concurred. A Gecko-based app that wants useful certificate UI should use the same error page mechanism Firefox does. Certainly we should treat using this pref in Firefox as non-supported.
Status: NEW → RESOLVED
Closed: 12 years ago → 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.