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):
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
The 'wheel' on the tab is 'spinning', but nothing appears to happen. Not even
after waiting for 10 or so minutes.
Presumably exception would be added and I should be taken to the expected web
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
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
It is a pulldown menu with also has "Cybertrust Educational CA" and "GTE
CyberTrust Global Root" as options
Common Name: <FQD of machine I try to connect to>
Rest is just address
Common Name: Cybertrust Educational CA
Organizational Unit: Educational CA
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.
(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.
(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:
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)
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.
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.
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
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.
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
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]
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?
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:
This bug is known, still unresolved, and being tracked upstream.