Letsencrypt working in 2.3
-
It's a manual process today, but here's what I did to get it working. You'd need to repeat steps 13+ here every 3 months as the certificates are meant to be automatically renewed. Hopefully someone can turn this into a package that automatically creates and updates the config.
-
enable ssh, ssh to fw
-
mkdir -p /usr/local/www/.well-known/acme-challenge
-
pkg install git bash
-
rehash
-
mkdir /usr/local/src
-
cd /usr/local/src
-
git clone https://github.com/lukas2511/letsencrypt.sh.git
-
cd letsencrypt.sh/
-
edit letsencrypt.sh, change WELLKNOWN=/usr/local/www/.well-known/acme-challenge
-
edit /etc/ssl/openssl.cnf, modify appropriate fields in req_distinguished_name section, set commonName to the external DNS FQDN of the firewall
-
make sure the firewall has a valid DNS A record in the public internet and that it's currently pointing to the firewall's external IP
-
make sure a firewall rule allows access via HTTP(s) from the outside world to permit the challenge rule to go through (you can close this back up once complete)
-
/letsencrypt.sh -c -d your.fw.domain.com
-
take the output from certs/your.fw.domain.com/privkey.pem and fullchain.pem, import their contents into a new cert in the web UI -> System -> Cert Manager -> Certificates
-
set the web UI to use that cert in system -> advanced -> admin access
-
profit
If things go horribly wrong, you can revert to HTTP in the SSH CLI at the end of option 2, if memory serves.
-
-
Wow! Thanks for your instructions, I'm up and working with letsencrypt also for HAProxy.
My pfsense has a HAProxy instance running on it and handling the https ports; some of my issues described below MIGHT be caused by the HAProxy, so if others reading this are not using HAProxy, this may not apply to you. A tl;dr of haproxy is, it accepts requests on port 80/443, and then redirects to an appropriate backend. For the pfsense configuration, the pfsense server is listening on port 442, so the connection is first to 443, where HAProxy verifies it is pfsense that I want to speak with, then forwards to :442 (as opposed to any other sites I'm running)
A few comments to the relevant steps:
[3] After running step 3, you need to log out and back in from the shell, otherwise 5 can't find the command "git"
[4] "Src" directory didn't exist on one of the pfsense boxes, not sure why but mkdir /usr/local/src
[8] Has a typo, should be ssL not ssHI can also go one step further - for anyone using HAProxy and who has multiple SSL Certificates. The challenges from letsencrypt come over http, you can make this request new certificates for your other domains.
Your script needs one small change, so that the domain appears in the configuration file. I have added line 525 below, then in my openssl.conf I simply commented out the commonName option so it pulls from the environment
522 local tmp_openssl_cnf
523 tmp_openssl_cnf="$(_mktemp)"
524 cat "${OPENSSL_CNF}" > "${tmp_openssl_cnf}"
525 export commonName=${domain}
526 printf "[SAN]\nsubjectAltName=%s" "${SAN}" >> "${tmp_openssl_cnf}"
527 openssl req -new -sha256 -key "${BASEDIR}/certs/${domain}/${privkey}" -out "${BASEDIR}/certs/${domain}/cert-${timestamp}.csr" -subj "/CN=${domain}/" -reqexts SAN -config "${tmp_openssl_cnf}"I originally followed this guide (http://loredo.me/post/116633549315/geeking-out-with-haproxy-on-pfsense-the-ultimate), so my setup is very very similar to his setup if anything is unclear in my instructions check there.
then you can extend this as follows for your HTTP frontend:
Create a main frontend, which is NOT shared and listens on port 80; type: http/https(offloading), acls blank, actions blank and backend is "none". This will be the main entry for http, and the shared frontends will handle requests here.Create a shared frontend, primary frontend is the one created above. The ACL can be setup as
-> name: challenge
-> expression: Path starts with:
-> Not: YES (checked)
-> Value: /.well-known/acme-challenge/
and the action can be setup as
-> Action: Use Backend
-> Parameters: backend redirectHTTPS (this is the original backend which sends a 302 foward to the browser if they accidentally type http://example.com )
-> Conditional names: challenge (the name of the ACL above)This frontend will redirect anyone, as long as they're not visiting .well-known/acme-challenge/
Finally, create a shared frontend to handle lets-encrypt requests
The ACL can be setup as
-> name: challenge
-> expression: Path starts with:
-> Not: NO (Not checked)
-> Value: /.well-known/acme-challenge/
and the action can be setup as
-> Action: Use Backend
-> Parameters: backend pfsense (this is the backend which connects with pfsense's webserver .. we want to send all lets-encrypt requests here so the script can answer the challenge-response)
-> Conditional names: challenge (the name of the ACL above)With the above configuration, letsencrypt requests are delivered correctly, and I can request a certificate for any domain which points to pfsense!
Next step: try to automate 12-13, and duplicate step 14 multiple times :)
-
good work and quite right - edited original. FYI you can use rehash to have tcsh re-read the binaries available in $PATH without logging out. /usr/local/src existed on my install but it has been upgraded over the years dating back to 1.x.
A few comments to the relevant steps:
[3] After running step 3, you need to log out and back in from the shell, otherwise 5 can't find the command "git"
[4] "Src" directory didn't exist on one of the pfsense boxes, not sure why but mkdir /usr/local/src
[8] Has a typo, should be ssL not ssH -
There are reasons this isn't already in pfSense 2.3:
Caution is warranted.
https://www.reddit.com/r/PFSENSE/comments/4eqh2v/pfsense_23_letsencrypt_working_by_hand/d22nulb
-
Pullrequest for a acme package is pending (for a while now)..: https://github.com/pfsense/FreeBSD-ports/pull/89
Anyway certificates never ment that you should send every private detail about yourself over the connection without thinking. "Is this really my own banking site/gmail website.." .. As for validating domain ownership, if you can put contents behind a domain names webserver, that means that specific domain name is intended for you to use isn't it..? And LE does not provide wildcard certificates so your public www.company.tld webhoster wont be able to generate a certificate for your exchange.company.tld server hosted elsewhere.. To me it seems like the acme protocol is done in a legit way.. And a website with a 'valid' certificate called yourTrustedBankSite.hacked.tld you should not fill in your pin / security code / password no matter who signed the 'domain validated' certificate.. A official paid CA would happily provide signed certificates for *.hacked.tld with a single email send to hostmaster@hacked.tld.
Main point on that reddit discussion seems to be not to use 3rd party signed cert for the router webgui.. Using it for packages like haproxy is not something they specifically object.. (ive read over it..)
-
@jwt:
There are reasons this isn't already in pfSense 2.3:
Caution is warranted.
https://www.reddit.com/r/PFSENSE/comments/4eqh2v/pfsense_23_letsencrypt_working_by_hand/d22nulb
I'm sorry if this is off topic, but I'm very interested in understanding the security differences between Let's Encrypt and Domain Validated certs. As far as I can tell, the validation method used by Let's Encrypt doesn't seem particularly different than, say, Comodo's option of doing domain validation by putting a hash of a CSR at a particular URL. Is there some important distinction that I'm missing?
Admittedly, this seems like less of an argument in favor of Let's Encrypt, and more of an argument against DV certs…
-
so 14 and 15 cant be automated or done via terminal? If so 13 could be too and it seems like the whole thing can be configured to automatically update every 3 months.
-
I have the same question as reggie14. Is the concern about Let's Encrypt specifically or just domain validated (DV) certificates in general? I understand erring on the side of caution. I'd do the same thing if in doubt. I haven't looked at the specific solutions offered in this thread, so my opinion isn't an endorsement of any of them.
I don't see how using a DV certificate for WebGUI access is worse than using a self signed certificate. Presumably there's already an expectation for users to understand the pros and cons of self signed certificates vs domain validated certificates vs extended validation (EV) certificates vs self managed PKI. How does that change by having support for Let's Encrypt?
For home and SOHO users, I think something like Let's Encrypt offers a fairly practical solution if you consider cost, convenience, and security. Both are a class of users that (in my experience) are the most likely to use the default, self signed certificate while ignoring browser warnings.
I currently use a DV certificate from StartSSL for my home pfSense box. Is it as secure as managing my own PKI and having a dedicated management machine that trusts only my self managed CA? No. Is it good enough for what I need? Absolutely.
There are also a couple of things in that Reddit thread that I'm not sure about.
-
Is the wildcard DNS issue actually that concerning? If you control the DNS for your domain you can (likely) remove wildcard entries. If you don't control the DNS, is it really your domain? Regardless, the Wikipedia entry for wildcard DNS says a wildcard entry won't override an explicitly defined DNS entry. So, if I use https://pfsense.example.com as a host, what kind of an attack would benefit from someone getting a certificate for https://somescam.example.com? Did I misunderstand the flaw / concern?
-
There are situations that warrant enabling the WebGUI on the WAN. The most obvious example is making configuration changes remotely. Temporarily enabling WAN access to the WebGUI can save a ton of hassle if you accidentally make a mistake that breaks VPN access.
I think the point of Let's Encrypt is to provide a baseline, minimum level of security with almost no effort. It's about raising the bar on the bottom end of security, not replacing existing best practices at the top end. As long as there aren't any technical flaws that reduce security, it's a much better option than having people bypassing certificate warnings IMHO.
-
-
I skimmed over the issue with the DV certs. It seems that the method that the attckers used was to gain access to the DNS and then create an entry for a machine they controlled. If someone else has access to your DNS then there is a problem right there. The Acme protocol assumes you have secured your DNS. This is of course and assumption. I think it is a valid one and companies should take takes to make sure they don't give someone else access. Without this rogue DNS entry, the flaw doesn't work.
For this reason, I think it is reasonable to use Let's Encrypt for Pfsense, at least for the home and SOHO user. I might want to get a seperate cert if I really had to make sure the system was secure, but I think that most users benefit from the easy access to encryption.
-
When I first heard of Let's Encrypt a little over a year ago in spring of 2015, I was really looking forward to their service. Then as some details and policies became known, and raised red flags, my enthusiasm quickly turned to skepticism.
NOYB @ Let's Encrypt
https://community.letsencrypt.org/users/noyb/activity/topicsGetting Bad Vibes
https://community.letsencrypt.org/t/getting-bad-vibes/3424Eric Rescorla (NSA back door involvement) (Youtube)
https://community.letsencrypt.org/t/getting-bad-vibes/3424/43NBR: Security vs. Privacy
https://community.letsencrypt.org/t/nbr-security-vs-privacy/4247Surveillance Advantages of Short Lifetime Certificates
https://community.letsencrypt.org/t/surveillance-advantages-of-short-lifetime-certificates/4559Seth Schoen: Let’s Encrypt Presentation (Youtube)
https://community.letsencrypt.org/t/seth-schoen-lets-encrypt-presentation-youtube/502Peter Eckersley: Let’s Encrypt Presentation (Youtube)
https://community.letsencrypt.org/t/peter-eckersley-lets-encrypt-presentation-youtube/530 -
One of the things about getting old(er) is that dampened response to the new shinny becomes the order of the day.
This, and the unease expressed by NYOB are the substance of my reluctance to rush pfSense onto the "Let's Encrypt" train.
-
I haven't seen any arguments that convince me that LE is any worse than any other non-EV certificate, ie regular DV.
Yes, there's a chance someone can pop your box without having access to your domain, but if so that is just lack of trying. If they have your box and want to get your domain, they have a huge attack surface against you to make sure they get your domain creds.
-
I haven't seen any arguments that convince me that LE is any worse than any other non-EV certificate, ie regular DV.
What are your credentials that say others should relay on your judgment?
Perhaps you just have a different risk tolerance than others. Or maybe you just haven't looked very diligently or objectively or have different assessment of the importance of certain things found.You certainly do not speak for me.
-
I haven't seen any arguments that convince me that LE is any worse than any other non-EV certificate, ie regular DV.
What are your credentials that say others should relay on your judgment?
Perhaps you just have a different risk tolerance than others. Or maybe you just haven't looked very diligently or objectively or have different assessment of the importance of certain things found.You certainly do not speak for me.
DV relies on the assumption that if you have control over the email delivery chain and control over DNS for domain.tld that you own domain.tld. The former can be subverted via the latter so the only real trust is control over DNS.
LetsEncrypt removes the assumption of control over email delivery chain, and relies on the actual thing being trusted by DV: control of DNS.
LE is no better or worse than DV certs. If you're not comfortable with DV certs then there's a huge percentage of sites you shouldn't trust, including this one.
-
As explained above, your arguments against LetsEncrypt are essentially arguments against DV certificates in general. Ok, I'll concede that - the world is an imperfect place. A site with only a DV (or LetsEncrypt) cert should probably not be trusted with the nuclear launch codes.
However, I find the crux of your argument to be completely ridiculous in the terms of the pfSense WebGUI. First, I disagree that there are ever good reasons to expose a firewall GUI to the internet. If you're really concerned about security, that should be the first thing to go. If you broke VPN, you would just need to get physical hands on the device (or have a second VPN). Second, there should only be (in a large organization) a handful of people that even have access to said WebGUI and only another handful of people that even know it exists. Are you really that concerned about an attacker spoofing your firewall WebGUI login that maybe 10 people have credentials to? If so you need to re-evaluate the group of people that have access to the WebGUI. They shouldn't be trusted anyhow.
Should we all get EV certificates? In a perfect world - sure, let's assume there's nothing better to do with $2k+ a year than going through the arduous process of EV for a WebGUI that isn't internet facing anyhow. But in reality, you're eliminating a valid and reasonable method for users to get encrypted access to their firewall GUI. I think we can all agree that LetsEncrypt is a better option than say using Chrome's –ignore-certificate-errors option. But that is exactly what you're implying that small businesses and home users should be doing. Because you wouldn't use a LetsEncrypt certificate on your installation. No one is saying you have to.
I also want to point out the double standard of making a huge huff about LetsEncrypt while leaving plain HTTP as a single radio button away. Clearly that's the better option. ::)
I love that last line in the reddit comment "This is exactly why there isn't support for Let's Encrypt in pfSense 2.3. (I'd looked at it and decided that it wasn't yet time.)"
Cool story, bro - I didn't realize pfSense was a maintained by a dictatorship. Not everyone's use case matches yours. Lighten up old man. -
Just thought I'd point out that there appears to be a feature request being worked on to have LetsEncrypt support in version 2.4…
https://redmine.pfsense.org/issues/5434
-
p.s. its not only usefull for the webgui itself, but also for other packages running on pfSense like for example haproxy or maybe vhosts package or even the captive portal might use a trusted cert to let people enter their voucher codes.
I would really like to have it available through 'official' channels instead of people needing to take lots of different scripts from sources the search-engine of choice presents..
-
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
-
This might be slightly off-topic for this thread, but it's at least related. I have a public-facing web server that obtains Let's Encrypt certificates for a number of internal hosts using the dehydrated script (https://github.com/lukas2511/dehydrated), and I'm able to automate deploying certs to most of those hosts using some fairly simple scripting. Typically this involves using scp to copy the relevant cert files to the appropriate locations, and then reloading the web server or other software using the cert. Is there any reasonably-straightforward way to automatically deploy a cert to a pfSense machine?
-
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.
