Some advice regarding certificates

wgstarks

I’ll start this by saying I know absolutely nothing about certificates and could really use some advice.

Before setting up acme I was using a positive ssl certificate.

Now that I have acme/LE that certificate is almost the same

The Comodo ssl certificate is due for renewal soon and I am considering just letting it expire since I don't think it is really serving much purpose, but I’m not sure what effect this might have for my pfsense firewall?

jimp

If you switch the WebGUI to use the LE Cert then it should be fine to let the other one go.

Unless you're using it in a package that doesn't show on the list there. Where are you using that Comodo cert? Only for the GUI? Or in something else like HAProxy? If it was in a VPN it should show that there.

wgstarks

IIRC it was just for the webUI.

jimp

Then set the WebGUI to use the LE cert, test and make sure it's working OK, then you can remove the comodo cert. If something breaks, you can step back to the older config and then you know what to target next.

Napsterbater

@wgstarks switch the web config of pfSense to use the let's encrypt cert before your positive SSL one expires and other than that there shouldn't be any other issue that's let's encrypt search should act just as good as the other one.

Edit: for some reason it didn't show any replies until I replied but apparently everybody on the same page =p

johnpoz

@wgstarks said in Some advice regarding certificates:

IIRC it was just for the webUI.

If this is just for the web gui.. Why are you playing with certs from acme or some public ca.. Who access the web gui? You? Just create a cert with CA in pfsense for like 10 years.. Trust the CA in the browser and be done with it.. You can use whatever freaking domain you want be it public or not, you can use IPs in the san so you can access it via whatever fqdn you want or just plain IP.. Multiple fqdn on multiple interfaces and or ever firewall IP, etc. and all show pretty green trusted cert.

The only reason you should have to use acme or true public ca si when people that you do not know are going to access the interface.. I find that unlikely for the pfsense admin web gui.

SteveITS

@johnpoz said in Some advice regarding certificates:

If this is just for the web gui.. Why are you playing with certs from acme or some public ca.. Who access the web gui? You? Just create a cert with CA in pfsense for like 10 years.. Trust the CA in the browser and be done with it..

This is similar to my question about Let's Encrypt certs...wouldn't one need to allow access on port 80 from the Internet to pfSense to verify the cert?

jimp

@teamits said in Some advice regarding certificates:

This is similar to my question about Let's Encrypt certs...wouldn't one need to allow access on port 80 from the Internet to pfSense to verify the cert?

Not for DNS-based challenges.

JeGr

@teamits said in Some advice regarding certificates:

This is similar to my question about Let's Encrypt certs...wouldn't one need to allow access on port 80 from the Internet to pfSense to verify the cert?

Not exactly to pfSense but to the appliance, yes. But one can

try to catch all currently known LE servers via an IP list (I'm looking at you, pfBlockerNG) and only allow them
additionally map incoming source any dest port 80 requests to localhost port 12345 and configure acme.sh to open its own server on localhost/12345 when it calls for LE to check and certify the domain. This way, yes, you'd have port 80 open to the world but having a listening process on that port only when an actual certification is in process. At any other times the port simply "fails" as there's no service on localhost/12345 (12345 as an example, one could use a fully random high port not used by other services etc.)

Greets Jens

jimp

@jegr said in Some advice regarding certificates:

try to catch all currently known LE servers via an IP list (I'm looking at you, pfBlockerNG) and only allow them

That won't be viable. They randomize/vary these on purpose to avoid people deliberately allowing or blocking just their own requests. It sounds counter-intuitive but if an attacker can divert just LE connections they could hijack someone else's domain in a stealthy way with an intrusion in just the right place.

JeGr

That won't be viable. They randomize/vary these on purpose to avoid people deliberately allowing or blocking just their own requests. It sounds counter-intuitive but if an attacker can divert just LE connections they could hijack someone else's domain in a stealthy way with an intrusion in just the right place.

Right of course, that's why I was writing "try". There are lists flying around with LE IPs spotted in the wild, but I'd recommend against those and just use my second point if DNS validation is no viable solution.

johnpoz

Or just use your own CA and trust it... I mean really how many freaking people will need access to your firewall gui? Isn't it just easier to trust the CA and hand that out to the support crew that should be very limited that have access to pfsense gui..

Set the cert for 10 years and be done with it..

wgstarks

@johnpoz said in Some advice regarding certificates:

Or just use your own CA and trust it... I mean really how many freaking people will need access to your firewall gui? Isn't it just easier to trust the CA and hand that out to the support crew that should be very limited that have access to pfsense gui..

Set the cert for 10 years and be done with it..

I agree that this would be much simpler (at least for my use case). Does this also work for the OpenVPN server? The main reason I setup Acme/LE was because I was under the impression (very possibly mistaken) that the certificate would be needed for remote clients connecting to my pfsense OpenVPN server.

jimp

You should always use an internal CA with OpenVPN. Never use a public CA with it.

The way CA validation works, any certificate signed by that CA will be valid. You don't want anyone else to be accepted onto your VPN unless you signed their certs, not LE. Then anyone with an LE cert could connect, which is not secure.

Now for Mobile IPsec with EAP-MSCHAPv2 it could be useful since it's only used to validate the server identity and not client identity, but LE doesn't put in the IKE Intermediate oid so it can't be used for that anyhow.

wgstarks

@jimp
So, as I posted earlier, I know next to nothing about certificates and just want to be sure I understand correctly.

I should ditch the LE certificate completely and create a CA in pfsense? Then use that CA to create self signed certificates for OpenVPN clients and the webUI?

jimp

You can use the LE cert for the GUI, just don't try to use it for a VPN. If you don't want to bother with LE, then use a self-signed GUI cert, or one from your self-signed CA. This doesn't matter a ton, really.

Use your own self-signed CA for OpenVPN (and IPsec if you use it).

wgstarks

Looking at the certificate manager in pfsense I see that I already have a CA (Private_CA) which shows in use by OpenVPN Server, so I think I’m ok there. In the certificates tab I have the LE certificate which also shows that it is in use by OpenVPN Server. I’m not sure how to correct this?

Derelict

Look at the configuration(s) for your OpenVPN Server(s) and see where that certificate is selected for use.

wgstarks

@derelict
Peer CA is set to Private_CA
Server certificate is set to LE_cert

Can I just create a new certificate using Private_CA and use that for Server Certificate without creating problems? There’s only a couple of clients configured so not really a big deal if I have to export new client certificates.

Derelict

Yeah. Create a server certificate signed by the Private_CA and change the OpenVPN server to use that. You will need to export new client configs.

https://www.netgate.com/docs/pfsense/book/openvpn/using-the-openvpn-server-wizard-for-remote-access.html#creating-a-certificate-authority