Getting sick of Firefox now

as a second check: Have there been any changes to about:config?

(this is a nasty are so be careful)

@jon I do not fiddle in the about:config area, so no, there have been no changes, none that I have made.

Did you try to add an exception at this point ?

@tphz Yes, I have already done that, thank you.

I also just want to add, in case the question pops up, I even deleted and created a whole new Firefox profile.

1 Like

Hi, maybe I’m repeating myself but in the past the same thing happened to me, and the problem was the certificate
in my case, the PC and the web server had different times than the browser, but it does the same thing if it is expired or not valid for the domain
I would look in this direction

@tratru Time of IPFire and PC is the same, so no issue there.
REgarding certificate, I created certificate using the instructions in the IPFire documentation here: www.ipfire.org - Generate an SSL-Certificate manually
The certificate validity is as follows:
Not Before Fri, 07 Jun 2024 10:13:29 GMT
Not After Fri, 04 May 4762 10:13:29 GMT

So no issue there either, I don’t think.

OK, so just an update, I removed Firefox completely using Revo Uninstaller, deleted all profiles and reinstalled Firefox from scratch and all is working as it should now. Must have been some corruption or something somewhere.
Anyway, thank you to all that assisted.

3 Likes

@dontknow Um, OK? I am not actually sure what you are trying to say here?

If you on windows maschine even check the certificates in the manager, there more old ducks as you will maybe thought :smiley:

Mark, I totally feel you! I’m also sick of Firefox not letting me handle my internal hosts with self-signed or even expired self-signed certificates the way I like. So every now and then, when I need to connect to an old OpenWrt AP with an appearently expired certificate, I’m f*d and need to do a lot of work to get in again (ssh, openssl, scp yadadiyadada).
As for this behavior in connection with the IPfire WUI, yes… after each update IPFire overwrites your certificates and you need to instantly edit

/etc/httpd/conf/vhosts.d/ipfire-interface-ssl.conf

to point to the right certificates or overwrite the files in

/etc/httpd/server-ecdsa.*

with your own versions.

Well, this doesn’t help you much right now, I assume. But it can all be done with an SSH connection, if you have made it permanently in the WUI before, that is…

If you’re using Linux, install and try connecting with lynx(1). It’s a character-based browser from the good old days. :slight_smile: First, create the file ~/.lynxrc with only this content:

ENABLE_LYNXRC:force_ssl_prompt:ON

Then you can connect to IPFire like

lynx https://192.168.x.x:444/

If lynx is complaining about invalid certificates, it allows you to accept the connection by pressing the y key (or j). That way you can enable permantent SSH listening on port 222 via the URL https://192.168.x.x:444/cgi-bin/remote.cgi

Firefox

Lynx

Hope it helps!

1 Like

Its a site origin error. Because ipfire should be connecting to a local domain instead of a FQDN.

Because the Ifire machine should be a .local or some other private domain name and the hosted domain should only be in ipfire’s DNS. as a host entry.

Other browsers like chrome do not have a site origin check and that is what is failing. Next time you go to the site and see the web page with the wildcard SSL it will be back since that will override the self signed stored.. Unless you install the wildcard on the ipfire machine which might cause other issues if you host another domain.

1 Like

@dr_techno Yes, that was my thought as well, as that is my domain, so I may get a proper SSL certificate for my IPFire box at some stage. For now I have completely abandoned Firefox and am using Chrome.

I run my own local CA on my network.Maily because of ease. I have a lot of devices with certs. But a self signed is not that big of a deal either. I wouldn’t add a public cert to an edge device like IPFire though.. Because you don’t want the edge device to be indexed by the DNS system as a brows-able object, just the one you hosting on the other side.. Even on that level, DNSSEC has no security impact and that is why you will come across web hosting companies that don’t use dnssec. Because the SSL is going to encrypt the same thing.

One thing I noticed is cloudflare wanting a bot check when clicking through a google search regardless of browser. Which the header part of the click through could be logged..

1 Like