SEC_ERROR_INADEQUATE_KEY_USAGE when accessing the webGUI from Firefox

viktor_g · Sep 9, 2019, 8:32 AM

Show us details of certificate

as solution you can add host to security.tls.insecure_fallback_hosts under about:config page

johnpoz · Sep 9, 2019, 9:23 AM

So can any client using firefox access pfsense1 from the pfsense1 network?

Pascal Craponne · Sep 9, 2019, 9:35 AM

Hi everyone, I experienced the same thing today, when trying to access the webConfiguration, and I suspect this is related to a new Firefox release.
I have the same error, which only occurs on Firefox (Edge and Chrome work), in version 69.0.

johnpoz · Sep 9, 2019, 9:47 AM

I have firefox 69 and not seeing this issue at all.. Then again I use a actual cert signed by a CA I created, vs a selfsigned cert. Where the client trusts the CA.

From the other thread seems like he is using just the built in selfsigned cert for the gui. And he stated he can access it from the same client using the same firefox I would assume when he just puts it on the other end of tunnel?

Is there a proxy in use?? Maybe from site2 he is using a proxy to access site 1?

Scenario I can think of that could present these symptoms.. Client has issue with cert on pfs1, but when in site2 going through say ha proxy doing offload of the ssl. Client has no issues with the offloaded cert, and ha proxy has no issue with cert on pfs1, or he is allowing https and http, and proxy is using http only to connect to pfs1, while presents https to client in site 2..

I would disregard details of accessing it from site2, and focus on why can not access when in the same site. What are the details of the cert, what version of firefox. Try changing the cert from self signed to actual CA created... I can switch to a selfsigned cert and see if I can duplicate with firefox 69.

edit: well I booted my pfsense VM, and accessing it via FF 69, with the self signed cert - and other then the error about the selfsiged, which added an exception for accessing it just fine.

Pascal Craponne · Sep 9, 2019, 1:31 PM

I found a way to fix this: remove the local certificates cache, which appears to be corrupted after upgrade.
For those who have the same problem, there is a fix here: https://support.mozilla.org/en-US/kb/what-does-your-connection-is-not-secure-mean (at the bottom of the page, section "corrupted certificate store").

johnpoz · Sep 9, 2019, 1:34 PM

That is great info... Thanks for posting it.

Have to keep that in mind for other threads where odd cert errors pop up..

woodym · Sep 9, 2019, 1:44 PM

hello,

i have the same issue.
I try the way from pascal, but nothing changed. The doc says to remove the cert9.db file after closing ff. In the folder i found the cert8.db too.
if i remove both (i have renamed) than ff works.

bye woodym

johnpoz · Sep 9, 2019, 1:48 PM

So one thing that a corrupted cert cache doesn't explain is why did it work from your other site? Different profile being used for firefox? Does the other site do a ssl offload or mitm proxy?

Did you cert cache become corrupted after you had tested from site 2, to pfsense1 and you didn't go back to test if still worked from site2?

kevindd992002 · Sep 9, 2019, 3:03 PM

No proxy on either site. In terms of webgui configuration, both sites have the same exact settings. Same profile being used with Firefox and I'm also using v69.0. I've tested this with two clients with the same exact result where as long as they are on site1's network it present this error.

Details of certs as requested:

johnpoz · Sep 9, 2019, 3:13 PM

Those are certs on pfsense.. If it was actually in use it would show it. See the in use "webconfigurator" yoru other freerad cert has ZERO to do with you accessing the webgui.

I don't see a san setting on that cert.. And prob not since its from 2016.. Create a new cert...

see how mine has SAN:

I can tell you for sure that any modern browser is prob going to balk at no san entry.

jimp · Sep 9, 2019, 3:15 PM

We have seen some recent browser updates fail when a non-server cert is used for the GUI. Some non-SAN certs started failing years ago.

You can make a fresh GUI cert from the console with current best defaults with pfSsh.php playback generateguicert

kevindd992002 · Sep 9, 2019, 3:23 PM

Ok, I'll try that route. How can you explain pfsense2's webgui working with no issues though? Here's the cert details:

There's also no SAN for the webConfigurator cert. And yes, I know that the FreeRADIUS server cert has nothing to do with my issue but I just included it in the screenshot anyway.

johnpoz · Sep 9, 2019, 3:25 PM

No clue - but what I can tell you happens alot is users say they do X, when they actually do Y... For all we know your hitting the other pfsense via http vs https. Or something silly like that.

jimp · Sep 9, 2019, 3:28 PM

The Key Usage browser error is almost certainly not SAN-related, but the GUI cert not having the bit set to act as a TLS Web Server (or the browser not seeing it for some reason).

Either way, generating a new proper cert should work around it.

kevindd992002 · Sep 9, 2019, 3:39 PM

@johnpoz said in SEC_ERROR_INADEQUATE_KEY_USAGE when accessing the webGUI from Firefox:

No clue - but what I can tell you happens alot is users say they do X, when they actually do Y... For all we know your hitting the other pfsense via http vs https. Or something silly like that.

I totally get that. And this is why I'm providing all screenshots that you need to prove what I'm claiming is true. I'm trying to be as troubleshooting-minded as possible here. And no, I'm accessing both through https. There'a nothing silly going on here because this is not really my first time handling pfsense but this issue isn't really familiar.

Anyway, I'll juet recreate the cert and be done with it.

jimp · Sep 9, 2019, 3:43 PM

The main reason that's the first step is because that's all we can really do. If the browser doesn't like an old certificate, but it does like a new one, then all you can do is generate a new one. We can't retroactively fix old certs, but when we find out about new/better defaults, we can fix the default cert code to comply for new certs.

The only actionable thing for us would be if a new GUI cert also failed.

johnpoz · Sep 9, 2019, 3:53 PM

That cert is prob from like 2.2.6 of pfsense or even before, since that is the lastest version of pfsense that was released that could of created that cert. Mar 8, 2016

JimP would know how many changes have happened with cert creation since that version and now ;)

Which one of those works and the other doesn't one was in Mar and the other in MAY, so you could have actually quite a bit of difference in pfsense versions that could of created those certs.

2.2.6 latest that could of created the mar one, but 2.3.1 could of been used to create the may one.

kevindd992002 · Sep 10, 2019, 3:02 AM

@jimp said in SEC_ERROR_INADEQUATE_KEY_USAGE when accessing the webGUI from Firefox:

We have seen some recent browser updates fail when a non-server cert is used for the GUI. Some non-SAN certs started failing years ago.

You can make a fresh GUI cert from the console with current best defaults with pfSsh.php playback generateguicert

Ok, this fixed the issue! Thanks for the help.

Jacques · Apr 16, 2020, 12:21 PM

I am using windows + firefox and also Avast . pfsense is in a VM.
I got the same error SEC_ERROR_INADEQUATE_KEY_USAGE
Looking at certificats in firefox in Servers tab I found pfsense...
This entry should be deleted
It was "generated by avast! antivirus for self-signed certificates"

Mohanad · May 15, 2020, 12:00 AM

Hi all
i have same problem .. but in a different way
i have a problem with the ISP and get together and fix it
then i restore the last configuration file .. suddenly i can not access the pfsense gui throw https and the openVPN also
I try to access from a different PC and it works fine ..
Now i can not access to internally or externally .
also i am not a high tech person .. i am just a network engineer and a little bit of security .. so i dont know any thing about SSL , certificates