Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/5.0 (compatible; Konqueror/4.0; Linux) KHTML/4.0.5 (like Gecko) Fedora/4.0.5-2.fc9 Description of problem: When pointing firefox 3b5 to a server with an unofficial ssl certificate we get " Secure Connection Failed <server>:<port> uses an invalid security certificate. The certificate is not valid for any server names. (Error code: ssl_error_bad_cert_domain) * 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… " When clicking on 'Or you can add an exception...' I am presented with the options 'Get me out of here!' and 'Add Exception...' Clicking on either yields no response. Not even after waiting about 10 minutes. Version-Release number of selected component (if applicable): firefox-3.0-0.60.beta5.fc9.i386 How reproducible: Always Steps to Reproduce: 1. start firefox 2. try to connect to server:port on server with 'local security certificate", one that isn't official in some way. 3. when firefox complains about secure connection failing, try to add exception Actual Results: Nothing, basically. The 'wheel' on the tab is 'spinning', but nothing appears to happen. Not even after waiting for 10 or so minutes. Expected Results: Presumably exception would be added and I should be taken to the expected web page. Additional info:
Could we get particular URL, where it happens? I certainly cannot reproduce this on many sites, where everything works as expected.
This particular server is not accessible from the Internet, unfortunatly. I do not remember the details right now, but it has something to do with the way it's ssl certificate either was generated or installed. I can connect to the server if I use fully qualified domain name, but the sertificate fails to get recognized if I connect using only the short name of the server. (Maybe this gives you some clues?) I believe that certificate was either bought from a non-widely used entity, or also possibly internally. In any case, I can try to dig up some more info about it over the weekend.
Do so, please. As much information related to this issue as possible would be helpful.
What I have been able find out about the certificate is the following; (this is what konqueror is able to tell me about the certificate btw) Encryption: RC4, using 128 bits of a 128 bit key Details: AUTH = RSA, Kx = RSA, MAC = SHA-1 SSL Version: SSLv3 Certificate Chain: <fully qualified domain name of the machine I try to connect> It is a pulldown menu with also has "Cybertrust Educational CA" and "GTE CyberTrust Global Root" as options Tab 'Subject' Common Name: <FQD of machine I try to connect to> Rest is just address Tab 'Issuer' Common Name: Cybertrust Educational CA Organization: Cybertrust Organizational Unit: Educational CA Country: BE State: <blank> City: <blank> below that; Trusted: TODO Validity period: 2007-02-26 12:52 to 2010-02-26 13:52 Serial Number: <blank> MD5 Digest: <mostly irrelevant?> ------------- I hope this might help in some way. -- Karl Magnus
(In reply to comment #2) > I can connect to the server if I use fully qualified domain name, but the > sertificate fails to get recognized if I connect using only the short name of > the server. (Maybe this gives you some clues?) Yes, one clue is that you just shouldn't do it. There are many security reasons why Firefox won't expand to FQDN and checking of certificate will (and should) fail. Do you have the same problem (no way how to exception) with FQDN as well?
(note, it doesn't meant that there is no problem -- we shouldn't just timeout, but tell you something meaningful)
BTW, for your pleaseure, this https://bugzilla.mozilla.org/show_bug.cgi?id=134402#c11 I found quite enlightening.
I agree that firefox shouldn't try to expand to FQDN by itself, but this server is local to me, so I should be able to use the shortname for it. Firefox 2 on fedora 8 protested too, but let me continue with a warning. If I use FQDN to the server in question it works without question and protests (also did on fedora 8). When I try to connect, I get the error page fairly quickly. And it is fairly meaningful (see my initial post for the whole error page text). The real problem here is that that error page tells me I can add an exception, but when I click that link (last line in the paste of that page is a link) the two buttons that appears does nothing. One is labled "Get me out of here!" the other "Add Exception..." Pressing either of them nothing happens. I have tried clicked 'Add Exception..." and left it for about half an hour. Nothing. Thanks.
(In reply to comment #8) > I agree that firefox shouldn't try to expand to FQDN by itself, but this > server is local to me, so I should be able to use the shortname for it. > Firefox 2 on fedora 8 protested too, but let me continue with a warning. The fact FF3 cannot continue with warning is considered from the security point of view as The Right Thing™ (see for example http://www.cs.auckland.ac.nz/~pgut001/pubs/phishing.pdf), but of course adding exceptions should work. If you need to get access to the local server by the short name, you should be able to ask your CA to add short name to the certificate of the server (it is possible to have more than one name in the cert). > The real problem here is that that error page tells me I can add an exception, > but when I click that link (last line in the paste of that page is a link) the > two buttons that appears does nothing. Yes, this is a bug. I am not sure whether it should be dealt with here or upstream, but I will investigate. Do you by chance get something interesting on the stderr when running firefox from xterm/rxvt/gnome-terminal/konsole?
We agree on the first part then. Starting firefox from a terminal I get stdout/stderr messages at all. Getting it fixed would be a good thing, preferrably upstream I would guess.
It was supposed to be; "Starting firefox from a terminal I get NO stdout/stderr messages at all."
Are you connecting in the form: (a) https://hostname/ or (b) https://hostname:portnumber/ ? If (b), what is the portnumber?
is IPv6 enabled on your machine? Is maybe one hostname getting resolved as ipv4 and the other one at ipv6? (Just making wild guesses)
Hi, Option (b). Not that I can see the particular relevance, but port is 8888 I believe it is. Ifconfig tells me I have an inet6 addr. But that should not really matter. That setup is identical to what we have on fedora 8. And it works there (firefox 2 though) I was about to test one thing regarding search domain in resolv.conf, but now firefox 3b5 doesn't take enter in the address bar. I have seen that problem before, but it went away yesterday. But now it seems to be back. I am able to type text in the address bar, but it doesn't take enter. Kind of strange, really. (yes, I have tested with several keyboards)
OK, I am persuaded that there is a bug here. ASSIGNing.
We did investigate a bit further and have found out the following; This is also tested on Firefox 3.0 proper! We see exactly the same problems there as in 3.0b5. If we move the .mozilla directory from the home-dir (CIFS mounted samba filesystem) to a local filesystem (typically ln -s .mozilla) All the problems we have been seeing seems gone. Both the buttons that didn't work and the "enter in the address bar doesn't work" problem mentioned above just seems to just disappeared. This type of solution does not scale very well above a couple of machines and users though (we have users in the thousands and machines in the hundreds), so I hope it is still possible to resolve it. Thanks -- Karl Magnus
Karl Magnus, thanks for letting us know you've found a workaround. Could you please try to reproduce the problem again, and check whether the error console shows any interesting messages, and paste them here? If possible, please clear the error console before you attempt the failing operation, then paste any messages the failing operation produced. Or you could simply attach a file with all the messages from the console. Thanks CC'ing Andrew as this bug is suspected to be related to the firefox profile being stored on a samba/cifs share.
I've reported this issue upstream at https://bugzilla.mozilla.org/show_bug.cgi?id=449316
What is the version of Samba on the server, what is the Linux Kernel version on the client?
Samba server is samba-3.0.28-0.4.3 as provided through SLES 10 SP1. We have seen the problem with all versions of the linux kernel provided with FC9, all of which have been 2.6.25-based. -BT
Sorry for keeping you waiting (vacation). Repeating the operation, the error console doesn't give any new messages at all. There where, however, two messages when the browser is started. I'm unsure if they're relevant, so I paste them here just in case; (browser version 3.0.1 by the way) " Error: [Exception... "Component returned failure code: 0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE) [nsIJSCID.getService]" nsresult: "0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)" location: "JS frame :: file:///usr/lib/firefox-3.0.1/components/nsBrowserGlue.js :: bg__initPlaces :: line 358" data: no] Source File: file:///usr/lib/firefox-3.0.1/components/nsBrowserGlue.js Line: 358 " and " Error: uncaught exception: [Exception... "Component returned failure code: 0x8007000e (NS_ERROR_OUT_OF_MEMORY) [nsIDocShellHistory.useGlobalHistory]" nsresult: "0x8007000e (NS_ERROR_OUT_OF_MEMORY)" location: "JS frame :: chrome://browser/content/browser.js :: prepareForStartup :: line 763" data: no] " Thanks -- Karl Magnus
I did an strace, and even though I'm not so good at reading them, I did notice that several files where dropped in my .mozilla/firefox/<string>.default/ directory. All where named places.sqlite-<number>.corrupt. All where 0 byte files by the way. Maybe that is relevant? Thanks -- Karl Magnus
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This bug is known, still unresolved, and being tracked upstream. https://bugzilla.mozilla.org/show_bug.cgi?id=462287