-
I found a problem with it and pushed a fix a couple hours ago. Update the package to 0.1.8 when you see it. I put in fixes for SFTP Webroot and DNS-Manual today.
https://github.com/pfsense/FreeBSD-ports/commit/a8952d9a67c674e521f75f5c3e61d879f89d43a4
https://github.com/pfsense/FreeBSD-ports/commit/9bda224f04c361836ebd7ebf1992de20d504487bThe new package won't show up for 2.3.3 or 2.4 until new snapshots are built.
I see the update and giving it a shot now! Shall report back in a jiffy.
-
Couple Caveats so far:
-
When you click Issue and receive the TXT record (that works lovely now thank you!) make sure you hit Renew after you have added the TXT record to your domain, otherwise you will simply generate a new TXT record.
-
Somehow it has generated the cert as self-signed and not via Let's Encrypt which is throwing errors in the browser. Might be because of the update, going to start from scratch and see how it goes.
EDIT: So I still had my Startcom Root CA on the firewall, which seemed to mean the Let's Encrypt CA wouldn't install. After removing that, and reissuing the cert, it's all going swimmingly.
Cheers jimp! Great little package!
-
-
I found a problem with it and pushed a fix a couple hours ago. Update the package to 0.1.8 when you see it. I put in fixes for SFTP Webroot and DNS-Manual today.
https://github.com/pfsense/FreeBSD-ports/commit/a8952d9a67c674e521f75f5c3e61d879f89d43a4
https://github.com/pfsense/FreeBSD-ports/commit/9bda224f04c361836ebd7ebf1992de20d504487bThe new package won't show up for 2.3.3 or 2.4 until new snapshots are built.
got an update to 0.1.9
github says "Sorry, this commit history is taking too long to generate."
any tip on what's new/fixed in this release?
-
0.1.9 was this PR: https://github.com/pfsense/FreeBSD-ports/pull/296/files
-
FYI-
acme pkg version 0.1.10 = Fix formatting of nsupdate options
acme pkg version 0.1.11 = Add key type and algorithm selection to nsupdate, other fixes to nsupdate
acme pkg version 0.1.12 = Add standalone HTTP and TLS server methodsRe: Standalone mode: For security reasons, Let's Encrypt requires 80 for HTTP and 443 for TLS checks. If you bind to any other port you must forward port 80/443 to that other port or the check will fail. And it goes without saying that you must allow that traffic to the firewall with rules.
Perhaps in the future it could be fancy and add a temporary rule to pass traffic to the port, but for now you'll have to add one by hand. And you'll probably want to shut down the rule afterward unless you really want to leave that port open all the time.
-
Two small bugs/improvement requests.
1. If you click on the questionmark in the acme plugin page - it sends you to a non existing page.
2. For each entry in the domain san list - the password is shown in clear text even in the summary - it would be better to mask it -
If anyone is interested I wrote a how-to post on using this Let's Encrypt package.
https://blog.artooro.com/2017/02/16/quick-easy-lets-encrypt-setup-on-pfsense-using-acme/It works great already. Thanks for building it!
The biggest improvement I'd like for myself is the ability to select whether an "Actions list" command is executed before or after the renewal/issue. This way a command could be used to create a firewall rule that allows ACME to verify, and then the rule can be automatically removed when finished.
-
I'm trying to wrap my head around making LetsEncrypt work with my HAProxy setup so that renewals go through automatically, regardless of which domain validation requests come through.
Here's the current setup on pfSense:
Ports 80 and 443 open on firewall
HAProxy reverse proxy routing both HTTP and HTTPS requests to appropriate backend servers. Only simply routingHTTP/SNI SSL passthrough, no SSL termination at this point.I'd like to take advantage of the LetsEncrypt package, and was thinking of using the Standalone HTTP server option with a non-standard port, and then having HAProxy route the validation requests (carrying forward with automated renewals, obviously) to this Standalone Server instance.
Something like ACL (if /.well-known/blah blah blah/) use backend LetsEncrypt-standalone-server.I am assuming that this provides a better (more secure?) option than using wwwroot, since that's the gist I got from this thread.
Now, my first question is about whether I need to set the firewall up to allow any additional ports through (say, to the Standalone Server's port from ??? where), or is this rendered unnecessary because both the proxy and the Standalone Server are on the same host (the pfSense router)?
Secondly, when creating the backend server entry for HAProxy to route to for the Standalone Server (the LetsEncrypt response/validation server), what do I use for this? 127.0.0.1:port or the router's address? 192.168.1.1:port?
Thank you for your time.
-
Possible bug, one { too much, Please look at:
https://forum.pfsense.org/index.php?topic=125946.0
Thanks
-
I have installed the package on many machines but some of them are unable to store account keys it seems.
They can be generated but clicking on "save" does not seem to make them permanently available.Is there anything I can do about it?
Regards,
Julian -
I have installed the package on many machines but some of them are unable to store account keys it seems.
They can be generated but clicking on "save" does not seem to make them permanently available.Is there anything I can do about it?
I'm running this on over a dozen firewalls (mix of VMs and real hardware) here locally and haven't had any problems of this nature.
What is the exact procedure you're following?
What sort of hardware are you using this one?I have noticed that slower hardware can take longer to generate keys on so you might have to really be patient and wait for things to complete.
Worst case for the account keys, generate a new key on another box, then copy/paste it over to a slow one, save, then register it via the slow one.
-
Hey there,
I'm following the guide here: https://doc.pfsense.org/index.php/ACME_package but I've gotten hung up on the following statement in the recommended setup:
Before starting, an appropriate DNS key and settings must be in place in the DNS infrastructure for the domain to allow the host to update a TXT DNS record for _acme-challenge.<domain name="">.</domain>
Right now I access our router from 10.0.0.1 and have not assigned it a domain name. My questions are:
What are the
appropriate DNS key and settings? Where do I find those?
What DNS infrastructure do I add them to?
What does 'domain' refer to here?I realize these are rather naive questions but I hope they can clarify the documentation at the very least. If there is specific Let's Encrypt documentation I should be reading I'd love a link to that as well.
Thanks! :)
-
If you don't know, then that method is probably not for you. :-)
They are set on your DNS server for your domain, nothing to do with pfSense. It's an nsupdate/RFC 2136 style setup. If you run your own DNS server, search for the name of your DNS host or software along with RFC2136 you might find some info.
-
Gotcha. Thanks. :) I'll do the reading and see if I can make sense of it. The other methods all made sense to me but this one was unfamiliar and also labeled 'recommended' which is why I started to investigate.
We have pfSense in a small office primarily use it for security and performance, not web hosting. We have an internal DNS but not one accessible from the outside world. I had understood Let's Encrypt support as providing a valid SSL certificate for the WebUI but now as I am typing I am questioning that assumption. Ah well.
-
Does anyone know if they(pfsense) are working to add Namecheap support for dns validation? I'm surprised that this is not in the list.
-
Does anyone know if they(pfsense) are working to add Namecheap support for dns validation? I'm surprised that this is not in the list.
Namecheap does not have a good API for updating just TXT records or single records.
The normal DynDNS method does not support TXT records. Their other API requires you to read out all of the records, update, and then submit the entire set of records back to them. To me that seems like too much of a risk to mess with.
If the upstream acme.sh project picks up support for it then we'll add the GUI parts but I'm not sure I'd recommend it.
I have a bunch of domains with Namecheap and I'd love to see it work, but I can't imagine Namecheap making it easy to do since they also sell SSL certs and this would cut into their business.
-
Godaddy does SSL certs as well, but yeah I get your point. Well I'm still on godaddy for the domain i'm using for this effort for the next 2 years…we shall see what happens in that time.
Thanks for the reply.
-
Does anyone know if they(pfsense) are working to add Namecheap support for dns validation? I'm surprised that this is not in the list.
Namecheap does not have a good API for updating just TXT records or single records.
The normal DynDNS method does not support TXT records. Their other API requires you to read out all of the records, update, and then submit the entire set of records back to them. To me that seems like too much of a risk to mess with.
If the upstream acme.sh project picks up support for it then we'll add the GUI parts but I'm not sure I'd recommend it.
I have a bunch of domains with Namecheap and I'd love to see it work, but I can't imagine Namecheap making it easy to do since they also sell SSL certs and this would cut into their business.
Hi jimp
Is this something that can be used to include namecheap support?
https://github.com/h3/letsencrypt-namecheap-hook
-
That in python and acme.sh is a shell script. It probably would not be viable to include, especially since that is coded as a hook for the Dhydrated script, not acme.sh
Also read the code, it uses the API I mentioned. I'm really not crazy about the idea of a script manipulating the entire set of DNS records for a domain in that way, but that's how Namecheap coded their API…
-
Would it be possible to add dns_cloudns.sh to the next version? The API script was recently added acme.sh github page but I wouldn't know where to start modifying the GUI.
