SSL/HTTPS on local pfSense w/o public accessible domain
-
I have followed a guide to install an external certificate authority and certificate from StartSSL on pfSense.
After I was done I came to realize that this would never work because I do not own a public domain and this is not possible for me to do.
My question being:
How do I configure SSL/HTTPS for (WebConfigurator, Captive Portal, Squid) without having a security warning on modern chrome browser?I did try using the command to generate a new internal certificate from the internal CA it still displays the chrome security warning.
Thank you in advance ;)
-
I did try using the command to generate a new internal certificate from the internal CA it still displays the chrome security warning.
Add this CA to your browser.
-
I have followed a guide to install an external certificate authority and certificate from StartSSL on pfSense.
After I was done I came to realize that this would never work because I do not own a public domain and this is not possible for me to do.
My question being:
How do I configure SSL/HTTPS for (WebConfigurator, Captive Portal, Squid) without having a security warning on modern chrome browser?I did try using the command to generate a new internal certificate from the internal CA it still displays the chrome security warning.
Thank you in advance ;)
@AndrewZ is correct. That should fix it. Also note that this is generally normal behavior and doesn't affect the security itself. Pretty much all devices (Cisco, NetGear, etc.) connect via HTTPS now and use self-signed certificates. As long as the security is still good and you are using modern ciphers and whatnot then it's just a warning that your browser doesn't know to trust the CA. It doesn't mean anything is less safe. I only say this because I've had people try to convince me that routers weren't secure because they get that warning when they go to https and not http.
-
I have followed a guide to install an external certificate authority and certificate from StartSSL on pfSense.
After I was done I came to realize that this would never work because I do not own a public domain and this is not possible for me to do.
My question being:
How do I configure SSL/HTTPS for (WebConfigurator, Captive Portal, Squid) without having a security warning on modern chrome browser?I did try using the command to generate a new internal certificate from the internal CA it still displays the chrome security warning.
Thank you in advance ;)
@AndrewZ is correct. That should fix it. Also note that this is generally normal behavior and doesn't affect the security itself. Pretty much all devices (Cisco, NetGear, etc.) connect via HTTPS now and use self-signed certificates. As long as the security is still good and you are using modern ciphers and whatnot then it's just a warning that your browser doesn't know to trust the CA. It doesn't mean anything is less safe. I only say this because I've had people try to convince me that routers weren't secure because they get that warning when they go to https and not http.
Is there a way without having to add certificates on clients ?
-
You can not intercept ssl without installing certs on clients, that btw is a can of worms and you are going to have a miserable time doing as Android and apple now have hard coded certs and do not accept added certs
-
If you only want to eliminate the error for the GUI and captive portal, then you are going to need a certificate from a trusted root CA or intermediate. The least expensive path there is buying a domain name and using Let's Encrypt.
You do not have to expose your domain to the public, it only has to exist in a way that can be used to validate its identity. There are a bunch of DNS providers supported by the ACME package, so using DNS-based validation is easy and widely supported. I believe at least some of those options are free as well. So for example, buy a cheap domain somewhere, sign up with Hurricane Electric's Free DNS service, point the DNS for your new domain at HE, install the ACME package and set it to use the DNS-Hurricane Electric type, etc. With the right registrar and TLD or sale, the cost to you is less than a cup of coffee (especially if that coffee is Starbucks).
Squid is a completely different animal. You can't use that kind of cert for SSL/TLS interception, you have to install a CA on clients. Some browsers do key pinning but I read recently where that is being phased out in some cases but you still can't rely on that being completely workable for all clients.
-
"Is there a way without having to add certificates on clients ?"
For the admin gui, not sure how this would be a concern… How many possible clients do you have access your web gui to admin pfsense? Just trust the CA of pfsense in the browser you use to admin pfsense and then you get a nice green icon..
The only time you should have to worry about browsers trusting cert of the box is when clients outside your control would be accessing it.. Captive portal ok, but the admin gui of your firewall - the amount of people accessing this should be quite a short list ;)
As to doing SSL interception - that is a whole can of worms I would not suggest you open.. And you sure are not going to be able to do such a thing with a lets encrypt ssl..
-
For the admin gui, not sure how this would be a concern… How many possible clients do you have access your web gui to admin pfsense? Just trust the CA of pfsense in the browser you use to admin pfsense and then you get a nice green icon..
I do it because I have to access dozens of them in lab testing and having to click through security warnings is annoying, as is trying to maintain a central CA for all the GUI certs, or importing them all… I have the infrastructure setup already, I just make a new key and paste it in a new ACME entry and bam, trusted cert.
I could see it for HTTPS captive portal, it is very useful there. With HTTPS captive portal enabled and with a valid cert, browsers detect the presence of the portal and nicely handle the login procedure.
-
"click through security warnings is annoying"
Completely agree.. I setup certs on all my equipment that I control.. Normally just use CA on pfsense.. But if you have lots of equipment and they all support ACME - then sure that could be a time saver for sure..
But I like to use a local domain, which rules out ACME anyway. Unless there is a way to use DNS to allow for AMCE certs on domains that are not public.. like local.lan - but I thought that ACME had to be a public facing domain, etc.
And yup agree that captive portal is the one place it for sure makes sense to use a cert that browser would trust out of the box.
-
But I like to use a local domain, which rules out ACME anyway. Unless there is a way to use DNS to allow for AMCE certs on domains that are not public.. like local.lan - but I thought that ACME had to be a public facing domain, etc.
It has to be public, can't be a private/local domain. I don't really have any attachment to a local domain though, and domains are cheap now so I just have a few I use for various things internal and external and try to carefully manage the DNS entries so things only work where I want them to work.
-
true not like they are expensive I own quite a few of them, just to play with here and there.. I picked up one just a few weeks ago for 88cents for first year.. Haven't done anything with it as yet.. But yes I agree domains can be cheap.. But never as cheap as free like local.lan ;) And very descriptive to me, etc. etc. Don't have to worry about anyone using it or grabbing a name I like and forcing me to use a different tld, etc..
But I doubt this OP has multiple pfsense boxes he is trying to manage ;)
