Letsencrypt working in 2.3
-
Dear All,
As StartCom is likely to go down based in this issue: https://docs.google.com/document/d/1C6BlmbeQfn4a9zydVi2UvjBGv6szuSB4sMYUcVrR8vQ/preview, I would expect that many more people will feel the need to switch to Letsencrypt soon. Having certbot or another update client in the HAProxy package in a sufficiently secure manner would superb then.
Regards,
Michael
Yes, second that. I'm using StartCom at home now, using pfSense as a reverse proxy(add-on) that adds https for the websites running behind it. As StartCom is going down, I started looking into Letsencrypt and found this thread.
Letsencrypt seems ideal for this kind of stuff where you just want a little bit more(convenient) then self signed certificates. -
As StartCom is going down
They don't think they're going down. Their page mentions them generating new root certs for Mozilla to get off the shit list. IE and Chrome still trust them. It might be premature to dump your existing cert. I also use StartCom for my dinky site and I haven't seen any problems in Firefox with it yet.
-
@KOM:
IE and Chrome still trust them.
The(they have multiple, it's unclear to me which is which) root CA is also on the Chrome "shitlist" as of a few days ago.
Anyway, it seemend a good idea to switch to something else, as I do have to replace my certificates soon because of StartCom's problems. -
I've been doing some testing and the script here is working well;
https://raw.githubusercontent.com/Neilpang/acme.sh/master/acme.sh
put this script in your ~/.achme.sh/ folder and you're good to go with commands like;
~/.achme.sh/acme.sh –issue --dns -d yourdomain.tld -d sub.yourdomain.tld
after DNS is updated you're then able to update the certs and keys with
~/.achme.sh/acme.sh --renew -d yourdomain.tld (no need to specify all the subs here)this will create and update certs under ~/.achme.sh/yourdomain.tld/
I imported the key and cert manually in the web gui, but I'd like to do this automatically. Where are these keys/certs stored when using the web gui? and is it possible to load(move/copy) them with cli somehow?
After some digging I found the file /var/etc/haproxy/blabla.pem - however if i just cat my cert and key into this file and reloads haproxy, the old certificate is still in use.so.. how to import and reload certificates with cli?
-
I've been doing some testing and the script here is working well;
https://raw.githubusercontent.com/Neilpang/acme.sh/master/acme.shso.. how to import and reload certificates with cli?
Something similar to:
https://forum.pfsense.org/index.php?topic=107161.msg651063#msg651063 -
I've been doing some testing and the script here is working well;
https://raw.githubusercontent.com/Neilpang/acme.sh/master/acme.shso.. how to import and reload certificates with cli?
Something similar to:
https://forum.pfsense.org/index.php?topic=107161.msg651063#msg651063Thanks a lot for the "script.sh"! that helped me alot!
My certs that i use for haproxy is now being updated automatically!I see that in the script you are restarting the webgui (reloading the config file) with "/etc/rc.restart_webgui". I've checked "/etc/rc.*" but there's no haproxy restart script there (I can only find a "/etc/rc.haproxy_ocsp.sh" which updates haproxy OCSP responses).
How do I restart haproxy from cli?
EDIT: /usr/local/etc/rc.d/haproxy.sh -
FYI
https://github.com/pfsense/FreeBSD-ports/pull/89
that is all
-
Great to see this is getting some traction. I don't get all the hate towards LE. It seems even cPanel have implemented Letsencrypt into their AutoSSL feature.
I too am using a StartCom free DV cert to secure my pfsense webGUI, and a captive portal authentication page.
I intend to start using HAProxy soon to serve content from local webservers to the outside world directly from pfsense, rather than from a transparent Apache proxy inside the LAN. I'm already using Letsencrypt on this but I would much prefer to have this moved to the firewall.
I'll be watching this with great interest. Thanks for the great work guys.
-
Hi All
Initially thanks for the howto. I did use a different one, as it worked better for me.
I also managed to have it automated.Im using acme.sh by Neilpang (i did install bash):
https://github.com/Neilpang/acme.shIm running the web if on different port, therefore i need the validation on that different port (666):
for issue:
/root/.acme.sh/acme.sh –issue -d domain.tld --standalone --tlsport 666 -w /usr/local/www/
for renew:
/root/.acme.sh/acme.sh --renew-all --standalone --tlsport 666 -w /usr/local/www/after that i modified script from here, especially the parts with write rights, and hardlinks:
https://gist.github.com/mamedov/f3c63322dde1a73537b11c621a4fd02eNow it should work automagically. (of course you still need to change webconfigurator to https)
its not really a comprehensive guide, but it has some inspiration, i hope.
-
Hi All
Initially thanks for the howto. I did use a different one, as it worked better for me.
I also managed to have it automated.Im using acme.sh by Neilpang (i did install bash):
https://github.com/Neilpang/acme.shIm running the web if on different port, therefore i need the validation on that different port (666):
for issue:
/root/.acme.sh/acme.sh –issue -d domain.tld --standalone --tlsport 666 -w /usr/local/www/
for renew:
/root/.acme.sh/acme.sh --renew-all --standalone --tlsport 666 -w /usr/local/www/after that i modified script from here, especially the parts with write rights, and hardlinks:
https://gist.github.com/mamedov/f3c63322dde1a73537b11c621a4fd02eNow it should work automagically. (of course you still need to change webconfigurator to https)
its not really a comprehensive guide, but it has some inspiration, i hope.
The PR above has been pulled in. 2.4 should have a working package
-
Hi All
Initially thanks for the howto. I did use a different one, as it worked better for me.
I also managed to have it automated.Im using acme.sh by Neilpang (i did install bash):
https://github.com/Neilpang/acme.shIm running the web if on different port, therefore i need the validation on that different port (666):
for issue:
/root/.acme.sh/acme.sh –issue -d domain.tld --standalone --tlsport 666 -w /usr/local/www/
for renew:
/root/.acme.sh/acme.sh --renew-all --standalone --tlsport 666 -w /usr/local/www/after that i modified script from here, especially the parts with write rights, and hardlinks:
https://gist.github.com/mamedov/f3c63322dde1a73537b11c621a4fd02eNow it should work automagically. (of course you still need to change webconfigurator to https)
its not really a comprehensive guide, but it has some inspiration, i hope.
The PR above has been pulled it. 2.4 should have a working package
Great news!
https://redmine.pfsense.org/projects/pfsense/roadmap -
Any plans for Lets Encrypt support in a 2.3 release?
Took a look at the 2.3 snapshot but couldn't find it -
Already available in 2.3.3
-
And now on 2.3.2_1
-
Maybe I'm clueless as far as how acme/letsencrypt can help me on a inward facing network. Where the GUI is strictly accessible over internal / VPN network to start with.
So I allow an external influence to sort my internal certs, counter productive much?
Don't get me wrong, EFF has this thing going on, and I use them and trust them, by all means.
What am I missing here? I've got to be missing the larger picture, right?
-
So I allow an external influence to sort my internal certs, counter productive much?
Hardly "influence", but it provides a trust chain to ensure browsers can verify the validity of your firewall's GUI certificate.
Don't get me wrong, EFF has this thing going on, and I use them and trust them, by all means.
What am I missing here? I've got to be missing the larger picture, right?
It eliminates the extra steps necessary for you to tell your browser to trust the otherwise invalid certificate on the firewall. If you get complacent in always clicking past certificate errors, you are more likely not to notice if something about it has changed. Especially with browsers like Chrome that make it more difficult to setup a persistent acceptance of an invalid or self-signed certificate.
Sure you could make your own CA and import it into your clients OS/browsers but that's a lot of extra overhead for little benefit. If the firewall has a valid certificate you don't have any of the "scary" browser warnings or concerns, and a lower barrier to entry is always better when it offers superior security.
Plus the certificates can be used by services such as HAproxy for adding/enhancing security to sites behind the firewall. If you only have HTTP now for hosted web sites and HTTPS certificates have been cost prohibitive, there is more incentive to go secure. Google prefers to list HTTPS sites and browsers are now displaying warnings for HTTP sites with login forms and other cases.
-
And now on 2.3.2_1
Thanks was able to install the plugin, but:
When trying to create a cert with the setting "webroot local folder" i get an "cannot create directory" error messageand i'm not the only one, se here: https://forum.pfsense.org/index.php?topic=125293.0
When trying to create a cert with setting "webroot FTP" the process also fails.
So far i think some of the issues are:
- i have no rule who allows 80 or 443 over WAN, and from what i see in the logs letsencrypt tryes to access a temp file over WAN:80
- my webinterfaces is set to ssl so there is no webserver listening on port 80, so also even if i open 80/443 in the fw, letsencrypt cannot acces the file
so maybe the issue process should ensure that the correct port are open and has a listener and tell letsencrypt to use this port? or are there settings i missed?
-
Doing local webroot is not going to be viable for most people. There are posts here on the forum that show how to do it using haproxy if you must, but it won't work with the GUI unless you drastically reduce security. tl;dr: don't do it.
If you're on the latest version of the ACME pkg, then FTP webroot should work, at least for sftp, that's what I tested. You do need to have a port forwarded to the web server hosting the files for that, but there isn't any way for the firewall to know what you have to validate that. At some point it's up to the user to make sure their config is correct.
We're looking into standalone mode to see if it's viable, though we tend to not like running extra services on the firewall like that. At least it's short-lived, but it would still need a persistent firewall rule.
-
-