SEC_ERROR_INADEQUATE_KEY_USAGE when accessing the webGUI from Firefox
-
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:
-
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.
-
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, 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.
-
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.
-
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.
-
@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.
-
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.
-
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.
-
@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 generateguicertOk, this fixed the issue! Thanks for the help.
-
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" -
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
-
Hi,
Click on
and you see what cert is used by pfSense, what SAN, if the dates are ok, etc.
This :
@jimp said in SEC_ERROR_INADEQUATE_KEY_USAGE when accessing the webGUI from Firefox:
You can make a fresh GUI cert from the console with current best defaults with pfSsh.php playback generateguicert
will generate a new cert.
Firefox won't trust it at first, but you can overreirde this. because you know that "https://192.168.1" or "https://my-pfsense.my-network.tld" IS your pfSese and not some hacked site.You can also use the console access to reset GUI access, so that http://192.168.1.1 is useable, so you can inspect with the GUI what the issue is.
-
@Gertjan said in SEC_ERROR_INADEQUATE_KEY_USAGE when accessing the webGUI from Firefox:
Hi,
Click on
and you see what cert is used by pfSense, what SAN, if the dates are ok, etc.
The Time is set good .. no problem with it
This :
@jimp said in SEC_ERROR_INADEQUATE_KEY_USAGE when accessing the webGUI from Firefox:
You can make a fresh GUI cert from the console with current best defaults with pfSsh.php playback generateguicert
This the point .. How i can generate a new cert and from where
Please can you help mewill generate a new cert.
Firefox won't trust it at first, but you can overreirde this. because you know that "https://192.168.1" or "https://my-pfsense.my-network.tld" IS your pfSese and not some hacked site.You can also use the console access to reset GUI access, so that http://192.168.1.1 is useable, so you can inspect with the GUI what the issue is.
I did this when i could not access since first time .. and it works with http
