Some advice regarding certificates
-
@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?
-
@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.
-
@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
-
@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.
Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!
Need help fast? Netgate Global Support!
Do not Chat/PM for help!
-
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.
-
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..
-
@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.
-
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.
Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!
Need help fast? Netgate Global Support!
Do not Chat/PM for help!
-
@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?
-
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).
-
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?
-
Look at the configuration(s) for your OpenVPN Server(s) and see where that certificate is selected for use.
-
@derelict
Peer CA is set to Private_CA
Server certificate is set to LE_certCan 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.
-
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
-
Great. Thanks to everyone for your help.
