Certificate and password for web GUI for login? Basic instructions…Argggg

  • I read the Hangout video on User management(very cool video!), googled(even Duckduckgo'ed) trying to find out how to set up login to the WebGUI via password AND a certificate only. Even started to dabble with FreeRadius3…

    Anybody willing to explain how to do this set-by-step'ish?

    I know there are books on Certificates but hoping I could get help with this need...

    I want to do this via my LAN(not ssh).


  • LAYER 8 Global Moderator

    For someone that doesn't understand certs and or vlans… This seems like way quick path to lockout of the webgui for your own access to me.

    Why not just limit gui access to your management vlan, who would be on your management vlan and also know your what should be a good password, not just pfsense ;)

    I will check out this hangout and post up some step by step pics though if you really want.

    edit:  Ok just went through the slides in that hangout - there is no mention of cert auth of users to the gui..  You mean you want to auth your users to your wifi with eap-tls?

    Are you wanting to setup 2FA, that you could do with freerad and say google authenticator or authy..  Are you wanting to just setup 802.1x auth for your wired network?  What I think is happening with all of your recent posts is you hear some buzz word and want to do that but not really understanding how these buzz words function??

    Pretty sure that smart dlink switch (DGS1100) you have doesn't support 802.1x

    When you state cert auth to a webserver - what comes to mind would be https://en.wikipedia.org/wiki/Mutual_authentication this is where the client has a cert and auths to the web server with that cert.. If you could maybe lay out the scenario your wanting to setup be happy to help.

  • Would not be the first time I was locked out!!! :o

    Thanks John…really appreciate the help. Here is my understanding and what I am trying to accomplish(correct I do have a Dlink 1100 and Unifi AP...not sure this will handle what I am trying to accomplish):

    My GUI access is setup to be accessed on my wired Native VLAN only(connected thru my DLink1100)I have disabled my antilockout rule and created a rule just for web GUI, I have my web GUI limited to my newly created management vlan(aka Native, aka untagged VLAN, aka LAN IP)...big thanks to NogBadTheBad! What I wanted to do was set up a certificate to further secure this access. I was originally thinking as you stated where a "client has a cert and auths to the web server with that cert.." as the solution but a 2 step using google authenticator would be better as the authenticator would be on a seperate device and likely easier to manage. I think Radius can handle this now with webGUI? If not a certificate would be my goal for additional web GUI authentication.

    I managed to setup 2FA(Google authenticator) with a test user on pfSense/FreeRadius3 following this tutorial(https://blog.vonhewitt.com/2017/08/pfsense-openvpn-setup-with-freeradius3p2/), the only difference was I had to change the protocol setting to PAP(vs MS-CHAPv4??) in system->User Manager->Authentication Servers->Edit in order for it to work(When I say work, I got a confirmation when I tested the user in Diagnostics->Authentication), I have not implemented this to WebGUI access yet...other considerations? Will this work?

    Awesome Hangout video this month and the February 2015 that discuss "User Management and Priveledges"...just looking to implement the best practices. Gold membership was the best $99 I spent on security...thanks pfSense!

    However I think my plunge into certificate management is inevitable for the following additional things I am trying to accomplish(probably a seperate post):

    1. Nice little green lock when I log into my pfSense GUI. I followed this tutorial(https://www.ceos3c.com/2017/03/24/pfsense-generate-ssl-certificate-https-pfsense/) about creating a self signed CA...worked well in that I was able to see my CA in the lock but unfortunately could not fully get the "Nice little green lock". I belive my issue has more to do with loading the CA in my OS(step 6) then a pfSense question. I can see my cert but not quite sure how to verify the SHA-256 and SHA1 fingerprint. From what I have read the "Nice little green lock" is not needed to have encryption but it would be nice to verify the Fingerprints. I can see the key on my browser cert but just need to verify the fingerprint numbers in the pfSense CAs.

    2. 2FA or cert authorisation on my VLANs ssid being broadcast on my UnifiAP...agin not sure my Dlink switch can handle this.

    Thank you again for any help!

  • LAYER 8 Global Moderator

    I have posted multiple times on how to get the pretty green lock.. Is as simple has having your browser trusting your CA.. It really is click click… let me dig up a few of those past posts.  I also have my sg300 switches using these certs my unifi controller, and actually the web interfaces to openvpn as running on some vps out on the net, etc.

    Sure make sure you setup the freerad to listen on localhost, setup auth server for localhost..

    I use eap-tls on my wifi.. I am pretty sure have posted how to do this before multiple times..  If not or its dated I can do that again for sure..

    Here is link about the switches and the webgui for unifi

    Here one of the many links going over the webgui cert

    I have a bunch of pictures in that one going over exactly doing it.

    Why would you need to verify the fingerprint of cert you just download from your pfsense webgui on your own local network??  Really??  Overthinking this a bit much ;)

    I am curious who exactly is on your network that your using for your management vlan that would be able to access your pfsense webgui??  I am all for extra security when warranted...  But your talking a secure private network - where the only person that should have access to the webgui would be you and your devices on your home network.. 2FA in this case is over the top pointless... And pretty much only thing it will most likely accomplish is you locking yourself out.

  • Thanks John…this is definitely good stuff! I am using Firefox Quantum and can't seem to get the "Nice little green lock" to come on but I am OK just using my own cert. in the short term and watch for changes in cert. requests when I login. I am still encrypted from what I have read. It seems pretty straight forward and while your instructions are geared around Chrome(and excellant...you are awesome!) it seems easiy translatable to Firefox but I can't get it to work. I am not sure this actually gives me any better protection anyway, besides the "Nice little green lock". I think this is new and unique to Firefox Quantum: https://support.mozilla.org/en-US/questions/1175296. From what I gather it requires an additional cert in the OS. The solution with Firefox seems like you get the "Nice little green lock" but loose the additional Firefox security.

    I will definitely start implementing additional encryption and authorization on my switch(if it can handle it), AP and wireless. This is great thank you again.

    My biggest concern still lies with additional access to the web GUI(Front door), I dug into FreeRadius more and I don't think 2FA is possible yet with Google Authenticator for the webGUI(I think?).

    Protecting my Native VLAN seems key to protecting my whole network...I have lived thru fake certs and a compromised network and it is bad!!!! Spoofed emails, money stolen, identity theft...

    I am OK with that fine line of being locked out...I have my back-ups. What I am trying to accomplish is security above a password for my GUI, I think your link is what I am looking for(https://en.wikipedia.org/wiki/Mutual_authentication). I would keep this "key" or "cert" in my dedicated admin browser/computer and with this key I would be authenticated into my pfSense box(anything else would be denied).

    Thanks again...my tinfoil hat is tight!!!

  • LAYER 8 Global Moderator

    I use firefox and on the latest 58.01, it trusts my pfsense cert just fine with green lock.  And even can it via IP and be trusted since I setup the san that way.  The green lock doesn't get you any extra security.. Just a visual indication that cert your using is signed by CA that you trust vs some sort of selfsigned thing or something wrong with the cert like your hitting via name that doesn't match, etc.

    The only reason that was prob using chrome - is the guy that asked for it was using chrome, etc.

    As to using 2FA on the webgui, if you set your auth server to be freerad, and you seutp 2FA it should work… I will give it a little test run to see... Will post my finding in this thread.

    As for gui to auth the client cert, nginx supports it.. So yeah it should be possible - just not something that is currently listed in the gui..  You could for sure prob post up a bounty for someone to add it..

    "Protecting my Native VLAN seems key to protecting my whole network"  Agree - but how exactly these bad guys going to access your lan?  Are they in your house?  If so they have physical access and your 2fa or client side cert auth get thrown out the window with physical access..  So while your tin foil hat might be tight, it doesn't make any sense and your adding layers of security that just make your own access difficult for no actual added security.

    If something gains access to your PC remotely - what would even be the point of accessing pfsense.  They can just get what they want from your PC.. Or ransomware it, etc. etc.  Even if they are on your PC... Where are they getting the gui password, are you saying their is an exploit to the web gui, that your 2FA or client cert auth mitigates?  That its a bit far fetched..

    2FA doesn't really mitigate exploit of the code on the interface.. What it does is prevent someone that either guesses or knows the password from using said info to gain access because they also need the 2nd factor which should be something other than your PC, etc.  So if you get your client tls auth working - you going to store the cert on a usb you carry with you or lock up or something.  Wow that is going to be a real PITA ;)

  • @johnpoz:

    I use firefox and on the latest 58.01, it trusts my pfsense cert just fine with green lock.  ….

    I always kept that self-signed, local cert around in my cert list, generated way, way back, when I first installed pfSense. It was still good up until 2021, so I activated it.

    When I hit my pfSense box again using the URL I normally use https://pfsense.mynetwork.tld, using my 58.01 FF, FF was upset and complaining, and no way to introduce an exception (the 'name'  pfsense.mynetwork.tld was not found in the certificate, etc).
    So I hit it using the and now I had the possibility to add an exception. FF is happy now, and I have the green lock.

  • LAYER 8 Global Moderator

    You sure do not have a green lock with an exception…

    That would have to be signed by a CA you trust and what you are hitting has to be listed as CN or SAN, etc. be it a fqdn or IP..

    As to the 2FA auth - took only a few minutes to setup.. And sure you can use it to login to the webgui..  But here is the thing it will default back to the local database if fails on freerad.. So you can login with just what the password is not having to know the pin and OTP..

    Guess you could make your password for the localdatabase something like 64 character long random, while the 2fa would end up being your 8 character pin you created and the OTP generated by google auth or authy...

    You could prob prevent all access to webgui unless your vpn in... Then you would have to vpn in from the lan side.. You could lock this vpn connection down to having to have the cert and OTP even... Then login to your webgui with username and password no 2fa..  But WOW that would be a PITA for no point at all.. Since only your devices are able to even get to the web gui from your private network...

    if you could set webgui auth to not fall back to local database then you could for sure enforce the 2fa with google authenticator..

  • @johnpoz:

    You sure do not have a green lock with an exception…

    Well, nearly - see image.

  • LAYER 8 Global Moderator

    And what does it say for your CA and the exclamation?

    Firefox must of changed how they present an exception before they use to show a slash through it or it was grey - my guess is they got a lot of users thinking it meant not secure even though they had added an exception to the self-signed or misconfigured https site..  I just looked at older firefox and shows the grey lock on a site with exception.

    When you highlight the icon what does it say?  You notice mine doesn't have such a little exclamation mark.. And says verified by home - the name I called my CA..

    I will have to go through the firefox release notes to when they changed that.

    edit:  Seems FF changed it now that it grey if padlock if there are http stuff on the page.. Green with ! if exception but no http code under, etc.  Like the pfsense forum page.. Shows grey with ! and states part of this page is not secure.

  • @johnpoz:

    And what does it say for your CA and the exclamation?

    When you highlight the icon what does it say?  You notice mine doesn't have such a little exclamation mark.. And says verified by home - the name I called my CA..

    The original cert from pfSense, generated by pfSense years ago, is very old.
    Everything is 'wrong' in it (SAN, whatever) only the dates are still ok.


    edit:  Seems FF changed it now that it grey if padlock if there are http stuff on the page.. Green with ! if exception but no http code under, etc.  Like the pfsense forum page.. Shows grey with ! and states part of this page is not secure.

    This is easy to 'repair'  ;)
    Visit Profile -> Forum profile. Then "Modify profile" -> "Look and Layout" Check "Don't show users' avatars." (and know you understand why the green pas is black/grey ? with the exclamation sign) and the pas stays green  :)

  • LAYER 8 Global Moderator

    "Everything is 'wrong' in it (SAN, whatever) only the dates are still ok."

    And you can not trust a selfsigned, there is no CA to trust.. You can only make an exception for it.. You would need to create a CA, create cert for your web interface and then trust the CA to get full green without the ! on it..

  • I know.
    But I was lazy, installed jimp's latest miracle, had a small hard time setting it up, and clicked ones on "Issue/renew".
    I'm using certs from Letsenscrypt now. Major overkill, but it works.

  • LAYER 8 Global Moderator

    And forces you to use public domain, and can not access via rfc1918.. Yeah really no reason to be honest..  When you can just create a cert with whatever domain you want - I use local.lan, and could put in multiple names and or rfc1918 address on your different interfaces you might be hitting the webgui from.

    Takes all of 30 seconds to do - once.. Since you can set the cert to be good for 10 years ;)

  • Thanks John(and Gertjan) for the thoughts…

    I did manage to get the "Nice little green lock"...your previous instructions were good to make this work on Firefox quantum.

    Step 1: Create CA Authority
    Step 2: Create internal cert(using the new CA)
    Step 3: Upload the CA created in the CA tab to your browser. In my case Firefox (Preferences->Privacy & Security -> View Certificates -> "Authorities" Tab - Import)

    John your details here are clear even with the new Firefox:

    What was tripping me up before was "Common name" field and the "Alternative Names". What got it to work for me with my config. was I chose the "IP address" from the dropdown field in "Alternative field" and added my webGUI IP address and it worked(I access my webGUI via IP only)...yay nice "little green box".

    In terms of a cert. and password for the webGUI the threat I am trying to mitigate against is exactly what you say, someone gets remote access to my admin PC(email attachment likely...i.e. BEC or Business email compromise).

    I can limit the webGUI access:

    • via a firewall rule(no access to this port by any other interface)
    • No access to to this dedicated admin LAN by any other VLANs or interfaces via rules
    • Phisycally protect the box and lock it up in a cage
    • disable default admin user
    • Dedicated "airgapped" PC(although a dedicated VM might be a slight less secure but good alternative)

    Regarding the added authentication, my initial thought following the Hangout from January (and 2015 archive on the same topic) was to disable the default "admin" and create a hardened limited access user (2 step, cert or other hardened authentication) thereby protection my pfSense box. In terms of a second step I was thinking a seperate VM with a cert, YubiKey, maybe thumb drive, google authenticator, etc...but agree it needs to NOT be a PIA but simple.

    Today the only way I know to authenticate the admin device is with a fixed IP and a Mac address for authentication both I believe easily spoofed.

    I'll check out nginx...I also keep digging into FreeRadius3.

    Just out of curiosity after you disable the default admin, the only way to get it back is via the console on the box directly? Depending on the access I give to the new admin user this might be good enough...I can at least protect against an attacker savy in pfSense from deleting logs, writing commands, etc...

    Thanks again...pfSense rocks!


  • @V3lcr0 : good !! (and sorry for the thread hi-jacking)

    @johnpoz :
    I know  ;) Good things are not always for free : I needed a domain name, let's call it "this-is-my-business.net".

    But I guess I had no alternative, because I'm also using the pfSense's captive portal on a public site.
    I wanted the login to happen on a "https://captiveportal.this-is-my-business.net.net"** and in this case the company was good for the couple of $ a year for the domain name
    A public portal with a self signed cert is a no-go.

    ** I actually don't know why I preferred "https" captive portal login above http login, but it works great for everybody (read : my clients) so they are happy, which makes me happy.
    Maybe because wifi networks placed in front of a captive portal are not (should not) WPS or EAS encoded - the radio connection is "open" - everybody can join right away.
    And, everything is https these days, right ?  ;)

    And because I was using the acme package for this cert, I also added "pfsense.captiveportal.this-is-my-business.net", and some more, for free ^^

  • LAYER 8 Global Moderator

    Dude if your box has been compromised and remoted.. What is 2FA going to do for your password to your firewall?  And how would they know your password? You storing it in clear text on your machine..

    I think your tin foil hat is a bit too tight really…  But as stated if you want to really lock it down - only allow vpn in.. to hit your gui, and use OTP for that...

Log in to reply