SEC_ERROR_INADEQUATE_KEY_USAGE when accessing the webGUI from Firefox



  • @johnpoz , to continue our conversation regarding the webGUI issue I'm having in this post, I'm creating this thread in the correct forum section. Here's my basic setup first:

    pfsense1 <-> openvpn tunnel <-> pfsense2

    Problem statement: I cannot access pfsense1's webGUI when using Firefox with a client machine that is located on the same network as pfsense1. The error is:

    2f8ad38a-ad9b-40d4-9f44-cbaf6515462f-image.png

    When the same client machine is in pfsense2's network, I can access pfsense1's webGUI just fine. I have no problem accessing pfsense2's webGUI from any browser on any client wherever network they are.

    You were asking me about my certs and here was my answer about them. This issue happened just very recently and I'm not really sure what changed because I did not intentionally change anything. What will be my next step?


  • Global Moderator

    Show us details of certificate

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


  • LAYER 8 Global Moderator

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



  • 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.


  • LAYER 8 Global Moderator

    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.



  • 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").


  • LAYER 8 Global Moderator

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

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



  • 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


  • LAYER 8 Global Moderator

    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?



  • 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:

    c328978c-2403-49ab-b484-06a5b1cd41cb-image.png


  • LAYER 8 Global Moderator

    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:
    san.png

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


  • Rebel Alliance Developer Netgate

    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:

    c8ed74e2-1d2b-4142-90b8-d22fce7a6fae-image.png

    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.


  • LAYER 8 Global Moderator

    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.


  • Rebel Alliance Developer Netgate

    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.


  • Rebel Alliance Developer Netgate

    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.


  • LAYER 8 Global Moderator

    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 generateguicert

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

    59245887-d428-4b43-8fb4-f0f82473ebdd-image.png


Log in to reply