Just a suggestion, but someone at Sangoma needs to grab the LetsEncrypt problem by the balls very quickly. If it only is supposed to work for “the distro” please clarify.
LE generation/renewal works as well on non distro as distro, but non-distro users are left to their own devices to manage the firewall.
In some ways it works BETTER for non-distro precisely because you have to manage your own rules. The distro lerules enable/disable function is what’s broken right now and only impacts folks using the distro firewall module.
Open ticket: https://issues.freepbx.org/browse/FREEPBX-21683
For non-distro users I have customizable script that will dynamically open http access for LetsEncrypt here: https://github.com/jerrm/fpbx-lewatch
There is a separate issue with erroneous assumptions about what is a valid network config, but both distro and non-distro are equally broken in this regard.
Open ticket: https://issues.freepbx.org/browse/FREEPBX-21681
1 Like
What works “as well on non distro as distro”
The complaints are that “it” doesn’t work for renewals
Hey,
Just from a general principle perspective, SNG7 is our target platform for getting things working. So, for better or worse, any bugs that exist on platforms other than the SNG distro (but don’t exist on the distro) are of lesser priority from a Sangoma internal development perspective. I think there’s a hope that members of the community that like to run those other distros will step up to assist with platform specific bugs.
That being said, if there are general architectural problems that manifest themselves only on other distros than SNG, that would be a bit concerning to me.
I know that’s probably not the answer you were looking for, but hopefully it provides a little bit of clarity to the specific question you asked.
Matthew Fredrickson
Surely most folks want that LetsEncrypt just works, no?
If you offer it, then just make sure it works, no? If you are unable to do that maybe listen to @jerrm
2 Likes
I would not disagree, but the devil is always in the details on things like this. We’ve been putting some time into some improvements in LetsEncrypt over the path month or two, but the guy who’s been doing a lot of the work is on holiday. I think he should be back this next week-ish so we’ll probably need to have a discussion around some of these outstanding issues that have cropped up.
Matthew Fredrickson
We already have someone discussing at least one of the above tickets with @jerrm and working on a patch. When the other guy is back we’ll have to see where things land with these tickets from a bigger picture perspective.
Matthew Fredrickson
1 Like
The renewal issue is 100% Distro. Non-distro doesn’t have the problem because non-distro doesn’t use the firewall module.
Here’s a course of action that would guarantee that the firewall is a permanent non-issue: use DNS validation for the certs. Hear me out here:
- You would set up an acme-dns server somewhere in your infrastructure–call it auth.freepbx.org. Acme-dns is a DNS server whose sole purpose is to serve the TXT records required for DNS validation with Let’s Encrypt. It’s written in Go, it’s free software, and I’ve been using it for a while for my own infrastructure.
- In the certificate module, the user enters or confirms the FQDN for the PBX (call it pbx.example.com) and clicks a Register button
- The module sends a POST to https://auth.freepbx.org/register
- Your acme-dns server answers with a JSON string containing credentials, including a full FQDN in the form of e90587bf-fb75-43ae-88dd-bbb8bba81557.auth.freepbx.org
- The user gets a one-time pop-up asking them to add a CNAME record with their DNS host, pointing _acme-challenge.pbx.example.com to e90587bf-fb75-43ae-88dd-bbb8bba81557.auth.freepbx.org
- Optionally, the module checks a public DNS server like 1.1.1.1 to confirm that record is there
- The module then issues the cert using whatever client you choose that supports acme-dns–probably the simplest one to integrate would be acme.sh.
And then a scheduled task runs, renewing the certificate as needed. Let’s Encrypt never needs to reach the user’s server directly, so the firewall is now a complete non-issue.
I’ve been using acme-dns for the last couple of years to get certs for pretty much everything in my infrastructure. It works very well, deployment is pretty simple, and it means I don’t need to poke holes through my firewall for anything (related to that, anyway).
1 Like
NOOOooooo!!!
I’m all for LetsEncrypt with dns-01,but…
An extra dependency on Sangoma infrastructure is the last thing we need. If Sangoma provides their own dns server, it should only be an option for those too lazy or incapable to manage their own DNS.
Sangoma already has an unneeded and problematic phone-home in the existing http-01 implementation.
The fact that it takes more than one hand to count the number of times the FreePBX mirrors have been down that I have personally stumbled on does not give me warm feelings about the dependability of the infrastructure.
The fact the current renewal issue exists at all is hard to excuse and raises doubts on anything security related. They never bothered to test even a single certificate renewal cycle.
1 Like
Fair point–so make the acme-dns server configurable. You can use theirs, you can use auth.acme-dns.io, you can use your own.
FreePBX distro already runs dnsmasq, which can be easily configured to serve the TXT record. No API is needed because it’s on the local machine. On your main DNS, you’d put an NS record delegating _acme-challenge.pbx.example.com to the PBX. You need to forward UDP port 53 to the PBX, but it would have an iptables entry that only accepts queries for _acme-challenge.pbx.example.com.
An attacker probing UDP 53 would not see a response, unless he already knew the domain name (other security measures should be in place to make it very difficult for a random scanner to discover).
The appeal of dns-01 auth is removing pbx listening and firewall interaction completely. Forwarding port 53 could be an issue in some environments.
A dnsmasq based solution would be problematic for non-distro users. It would almost certainly require require a sysadmin dependency to cross the asterisk/root permissions boundary.
Like @dicko, I’m a fan of acme.sh. dns-01 using one of the over 100 dns providers already supported by acme.sh can remove any dependency on sysadmin. I could see a “friendly” interface for 4 or 5 of the top providers and a generic “text box” style entry to allow for anything else acme.sh supports.
It would be easy for Sangoma to add their own acme.sh plugin if they wanted to add their own servers as an option as @danb35 suggests.
bear also in mind that using dns-01 you don’t need to use your pbx directly at all, run acme.sh wherever you have a bash shell and use the ‘deploy’ scripts to move the issued certs as needed, the collection includes ssh, mikrotiks erc.
Just want to say that the next best thing to free certs is almost free with NO hassle. You can get five years worth of Comodo certs from Namecheap for $30. Renew once a year and import to pbx.
The benefit of Sangoma running an acme-dns instance is that any user with any DNS host can still use dns-01 validation–all they need to do with their DNS host is enter one CNAME record that doesn’t need to change in the future. And if the acme-dns server URL is configurable, nobody’s tied to any of Sangoma’s services if they don’t want to, or if those services prove unreliable.
Anyone capable of that can already do so, no FreePBX mods needed.
As much as I like acme.sh, creating a GUI for dns-01 will be a headache. There’s not much consistency in parameter names. If the dnsapi plugins had a standard option to output xml or json descriptions of the needed variables, building a generic GUI could be pretty straightforward.
Although it’s my personal wish, I think the odds of Sangoma doing anything with dns-01 are slim to nil. If they can get the firewall issues worked out (which should be much simpler than they are making it), http-01 will be seen as the easier to support. The flexibility of acme.sh also means there are are ways to get it wrong.
Well , personally I think anyone who can run a PBX should also be able to manage his/her DNS securely, but in that perceived absence , then await another patchy apache patch or perhaps . . .
As a lowest common denominator compromise, a recipe/script to have folks migrate to $0 cost Cloudflare and thus DNS-01 compliance and an accompanying script to make FreePBX happy ?
JM2CWAE
1 Like
I agree, but reality suggests otherwise.
dns-01 would be a new feature, I hope Sangoma pursues it, but even if so, expect it would be a future enhancement.
The existing http-01 implementation is broken and a critical security issue - disabling the firewall completely. The existing http-01 functionality needs to be fixed immediately.
They pushed a still broken fix to edge prematurely IMO. The updated module can still leave the firewall disabled or compromised, but at least its not a 100% certainty anymore.
Still waiting to see what they do with it. Maybe @mattf or @kgupta1 can comment?