Let's Encrypt renewal not working on FreePBX 17

My v16 systems are still fine, but the systems I’ve migrated to 17 are unable to renew. I find it interesting that it was originally able to acquire the certificate with the firewall turned on, but now unless the firewall is disabled the renewal fails.

Has anyone else had a similar problem on v17, and/or has anyone found a resolution?

There’s been some issues but you need to provide details on your issue to help track down the problem.

Here is an easy solution

I have been deploying FreePbx/Asterisk on Debian for years (Bookworm for 2 years) where the Distro version wasn’t available, I have always used Neil Pang’s

https://github.com/acmesh-official/acme.sh

it is simple to understand, easy to deploy, and does HTTP-01 and DNS-01 protocols (among others) with DNS-01 you don’t need any fire wall rules or even access to your Box if you have one of over 100 common DNS services. it will automatically renew any of several 'Free Certs ZeroSSL by default but the less agile Let’sEncrypt ones if you want. And has deployment scripts for many devices like OpenWRT and Mikrotik and propriatory routers and NAS’s outside you immediate VOIP scenario.

Just uninstall the FreePBX module and run the acme.sh script with args to suit.

Or we can troubleshoot this properly and see if this is a bigger issue that needs to be solved or something else specific to this deployment.

Goign to go over the standard array here
FQDN listed in Hostname under System Admin?
Do you have a FQDN supplied in Port Manager (somtimes this does not auto populate properly)
Do you have Lets Encrypt HTTP port enabled in Port Manager
Do you have your GUI redirected to port 8080 or a different unused port
If behind a firewall or NAT have you made use that you have enabled Port 80 as a port forward and is accessible by the internet
Though supposed to be automatic, did you ensure Fail2Ban and Intrusion detection are not impeding Let’s Encrypt.
Is your FQDN pointing to the correct IP in DNS
If using Cloudflare, do you have any Proxy’s enabled or Automatic SSL enabled that could be conflicting.

TL:DR
FQDN Assigned?
FQDN Routable?
Are you Sure
See DNS Haiku

It’s an issue with the firewall. The firewall configuration I submitted on the forum the last time this was an issue, in CentOS/FreePBX 16, is still mostly present in FreePBX 17, but doesn’t appear to be working now. I’m not sure if there’s a difference between the way iptables functions in CentOS vs Debian, but with Wireshark I can see the request come in, however the connection never gets established because the firewall is blocking it.

I’m assuming I’ll need to fire up another test system to debug iptables again, but I was hoping someone may have stumbled upon a solution already.

For those interested in testing whether your FPBX17 firewall is letting LE traffic through, all you need to do is drop a text file into ‘/var/www/html/.well-known/acme-challenge’, then try to visit http://hostname/.well-known/acme-challenge/testfile from any IP that isn’t already whitelisted in the firewall. Since LE has decided not to disclose where LE requests may come from, that test file should be accessible from anywhere.

Oh, is this unit behind a NAT? I noticed this issue on a past system, but you can creat a cron job to occur before hand to set the interface to trusted/local in intrusion detection.

No, it’s a Vultr VPS. But yeah, that would be a quick fix as well, a quick script to disable the firewall, renew the cert, then put the firewall back.

Thats a bit sketchier, I wonder what the traffic look like and if you could do something more port knocking using Vultr’s Firewall. You may also be able ot leverage Cloudflares Free accounts? PR in front should it support. I wonder why Let’s Encrypt is so peculiar about sharing domains or IP’s off where traffic is sourcing from for thje purpose of employing more strict rules.

I havn’t, and should admit that I also wouldn’t have the skills to understand how to whole HTTP-1 challange occurs but if its a read only folder with nothing that ever get’s edited you could use the above firewall with port 80 always open in IPtables. I belive there is documentation of such elsewhere

cloudflare using dns-01 with acme.sh just needs an api key (free) no more debugging of firewall needed

1 Like

I know you’re a big fan of doing it that way, and I understand why. My concern is storing the API key on the PBX. I think it’s pretty likely that there are still exploitable bugs floating around in the code, and if someone were to breach the PBX, they could wreak havoc on DNS.

Maybe less of a concern if you’re able to lock down the PBX to whitelist only known good IPs, but we need some services to remain open to the public, like provisioning, restapps, and UCP. Vulnerabilities like SEC-2023-001, in particular, is what really scare me about having the API key on the PBX.

You don’t have to keep the key on the PBX, you can run DNS-01 on any machine anywhere even on a docker container which you only start with the built in ‘on-update’ hook,

you could delete and regenerate API keys at will if super paranoid.

Personally I ‘lock-down’ all services by delegating all TLS to haproxy with ‘strict SNI’ enforced. IP connections will be dropped without a trace and you can use any bizarre domain name from namecheap for each seperate service

Hadn’t really thought about using haproxy, but it’s probably not a bad way to go. Trying to wrap my head around acquiring the cert elsewhere and passing it to the PBX though. We use that cert all over the place, not just the admin interface and UCP. Clearly Devices, Clearly Anywhere, SIP, restapps, EPM, and FOP2 are some things off the top of my head that are using the cert. Seems like there would be a lot of wheel re-inventing to pass off the certificate, and inject it into all of those services. Does fwconsole let you take the updated cert and inject it everywhere it needs to go?

For deployment to many things including haproxy

add frontends and backends in haproxy for all/any http/tcp services under separate domain names, have haproxy rewrite all TCP/HTTP requests to TLS and enforce sctrict SNI. then haproxy will handle all certifications but only pass on connections to your allowed domain names., the services themselves can run without TLS on 127.0.0.1 or whatever. You can still use your firewall if you find it necessary.