Comodo SSL for pfsense webgui
-
Hello,
I am using local cert created in pfsense. I want to buy and use Comodo ssl for pfsense (https in green). Do anyone knows how to do it?
-
Why... Just have your browser trust the CA that creates the cert you use in pfsense.
Or use the acme client - there would be ZERO reason to buy a cert..
-
Using Comodo or another ssl certificate is not recommended?
Which certificate will acme client use? Lets Encrypt? Is there a tutorial I can read how to use that?
Why I want to use Comodo ssl, because I want to setup squid. And if one of the users at our company access blocked websites it will give a certificate error. I don't want to trust that self-signed ssl in each computer. -
That cert has ZERO to do with your webgui cert..
-
You can use a comodo certificate for the web gui if you want to
Use the certificate manager to create a CSR
Submit the CSR to Comodo
Import the certificate when you receive it
Tell the webgui to use the certificate.But yeah, you can't use a "real" certificate for SSL MITM. You don't have the private key so you can't generate the spoofed certs on-the-fly. You have to deploy your own CA to all of your clients to do what you want to do.
Moving thread to Packages > cache/proxy.
-
@Derelict Awesome, I was looking for this in my own search, and this post helped me out. Thanks.
-
@emammadov said in Comodo SSL for pfsense webgui:
I am using local cert created in pfsense. I want to buy and use Comodo ssl for pfsense (https in green). Do anyone knows how to do it?
Also as browsers won't recognize EV certs any more (for all of those loving green bars with your company name on it) - don't spend money on unnecessary certs anymore :)
-
Never underestimate the fools need to be parted with their money ;)
-
@JeGr said in Comodo SSL for pfsense webgui:
Also as browsers won't recognize EV certs any more (for all of those lo
But if I were to use the built in cert-manager, how would I actually tell my client machines on my network to trust it?
-
Active Directory GPO.
-Rico
-
By installing the CA into your browser that certs signed by this CA are trusted.. Just how it works now for every other CA on the planet..
Simple export, and then import into trusted publishers.
This really should at most be a handful of machines - how many users have access to the admin gui of your firewall?
Advantages of this is, you can make the cert good for like 10 years, so its something you have to deal with ONCE.. Other thing is you can use any fqdn you want, doesn't have to resolve on the public net, doesn't even need to use valid tld.. You can also use rfc1918 addresses in the SAN, so you browser will be ok if you access via http://192.168.1.1 for example.
Now that this browser trusts your pfsense CA, you can generate signed certs for any other devices on your network that also use SSL certs for their gui..
If you have a wide bunch of users that need to access these local resources, you can also push out trusting this CA via group policy, or your install process of your machines, etc. etc.
If the https interface is only accessed by devices under your control - there is little reason to buy a ssl cert.. Only time you need a ssl cert that is auto trusted is when the users/devices/browsers accessing these resources are out side of your control.. And there are lots and lots them.. Say a public facing website for example.. In such a case you would buy a cert from a trusted CA, or these days you can just use ACME.
-
Or as another possibility: run a subdomain like lan.mydomain.tld and use a DNS provider, that acme.sh can use. Then it's possible without much handywork to use LetsEncrypt certs for your firewall. You don't have the luxury to add IPs as SANs into that certificates but other than that, it's working fine :) Never saw the need to really run OV or even EV certificates on pfSense, not even for proxy or web servers behind it. Only had one encounter while setting up a customer installation where the customer really had bought a EV cert with SANs for multiple hundreds of $. And that for a website, nextcloud installation, mailserver and the WebUI. Talk about overkill...
-
ACME/Let's Encrypt is the best thing to do here, assuming you have a public domain available you can leverage and a supported DNS provider.
