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 ssH

    I 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.

    @mitchese:

    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


  • Netgate

    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/topics

    Getting Bad Vibes
    https://community.letsencrypt.org/t/getting-bad-vibes/3424

    Eric Rescorla (NSA back door involvement) (Youtube)
    https://community.letsencrypt.org/t/getting-bad-vibes/3424/43

    NBR: Security vs. Privacy
    https://community.letsencrypt.org/t/nbr-security-vs-privacy/4247

    Surveillance Advantages of Short Lifetime Certificates
    https://community.letsencrypt.org/t/surveillance-advantages-of-short-lifetime-certificates/4559

    Seth Schoen: Let’s Encrypt Presentation (Youtube)
    https://community.letsencrypt.org/t/seth-schoen-lets-encrypt-presentation-youtube/502

    Peter Eckersley: Let’s Encrypt Presentation (Youtube)
    https://community.letsencrypt.org/t/peter-eckersley-lets-encrypt-presentation-youtube/530


  • Netgate

    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.



  • @efr4k:

    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.



  • @NOYB:

    @efr4k:

    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?



  • @michaelschefczyk:

    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?



  • @idarlund:

    I've been doing some testing and the script here is working well;
    https://raw.githubusercontent.com/Neilpang/acme.sh/master/acme.sh

    so.. how to import and reload certificates with cli?

    Something similar to:
    https://forum.pfsense.org/index.php?topic=107161.msg651063#msg651063



  • @hvisage:

    @idarlund:

    I've been doing some testing and the script here is working well;
    https://raw.githubusercontent.com/Neilpang/acme.sh/master/acme.sh

    so.. how to import and reload certificates with cli?

    Something similar to:
    https://forum.pfsense.org/index.php?topic=107161.msg651063#msg651063

    Thanks 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


  • Netgate



  • 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.sh

    Im 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/f3c63322dde1a73537b11c621a4fd02e

    Now 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.



  • @stpq:

    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.sh

    Im 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/f3c63322dde1a73537b11c621a4fd02e

    Now 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



  • @heper:

    @stpq:

    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.sh

    Im 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/f3c63322dde1a73537b11c621a4fd02e

    Now 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


  • Banned

    Already available in 2.3.3


  • Rebel Alliance Developer Netgate

    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?


  • Rebel Alliance Developer Netgate

    @mudmanc4:

    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.

    @mudmanc4:

    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.



  • @jimp:

    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?


  • Rebel Alliance Developer Netgate

    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.



  • @jimp:

    And now on 2.3.2_1

    Where about please

    Thanks


  • Rebel Alliance Developer Netgate

    @mrcola:

    @jimp:

    And now on 2.3.2_1

    Where about please

    Thanks

    System > Package Manager, Available Packages tab: acme



  • Is there a reason all of the implementations tried are not using the dns-01 challenge?

    I find it crazy people are exposing 80 or 443 to issue a free cert, even temporarily. The dns challenge is perfect for internal systems and acme.sh has a ton of build in api clients to automate record changes.

    Just trying to see if this is something everyone overlooked or if there is a glaring reason no one has set it up that way yet?


Log in to reply