Hello.
I have FreePBX 14 and I’ve got an issue when updating Let’s encrypt certificate, which is in the both ways: fwconsole and certificate management. There are no events in the log, except a single message: “There was an error updating the certificate: Verification timed out”, which also appears in the certificate management page of web interface.
Firewall/NAT settings are correct and I see traffic between my server and mirror1.freepbx.org host on port 80.
I’ll be apreciate for any tip about where to dig.
1 Like
Let’s Encrypt made a change last week where they are validating from multiple sources, so whitelisting just the FreePBX and Let’s Encrypt mirrors aren’t enough. If we open port 80 to the world, we’re now seeing validation checks from 4-5 different IP’s.
I can’t imagine keeping port 80 open, but to date Let’s Encrypt isn’t committing to a set group of IP’s they will validate from
1 Like
You can set LE only on port 80 in the port management section under System Admin.
So you’re saying if I set that to Port 80, the PBX firewall would only accept LE traffic on port 80 and block/disregard anything else?
Kind of continuation of
I suggest caution leaving it open, use certbot/acme.sh ‘renew’ hooks to occasionally expose your bits
Thanks to all, issue is solved when opened port 80 for multiple sources.
Hello, there is an additional question. As a full access to a webserver for anyone is not good idea with security point of view, I would like to solve that by using directories restrictions. What are directories used for challanges access except “well-known” and “freepbx-known”?
From the Wiki:
" NEVER, EVER, EVER, EVER forward port 80 from your Router to your PBX. If you need remote access to FreePBX, the FOP, or the recording interface, set-up a VPN. You have been warned!"
https://wiki.freepbx.org/pages/viewpage.action?pageId=4161590
Maybe it’s time to just use a paid third-party cert.
IMO, there should be nothing else on port 80 to restrict. Every other service (admin GUI, UCP, provisioning, etc.) should be on a different port (separate VirtualHost), preferably HTTPS only, preferably protected by the domain name, and preferably limited to authorized IP addresses.
However, in addition, why hasn’t this been fixed to only open the port for a few seconds while renewal is attempted?
I don’t see how that’s better. Can you recommend one that (in the absence of a technical problem or the CA going out of business) would run for the expected life of the system without human intervention?
funny to watch this thread, the writing has been on the wall since forever.
There is no reason not to use DNS-01 if $10 a year is not a problem, then there is no problem.
There is risk but approaching 0 in opening up port 80 for one minute every 60 days.
But the acme client provided by Sangoma MUST do acme-V2 and should have a renew hook to provide that occasional pinhole when needed,
I don’t disagree with that. And when managing 10 or 25 or 50 systems that’s not a tenable solution vs. something fully automated or a two year commercial cert.
Unfortunately, DNS-01 is incompatible with the DNS service bundled with many of the popular domain registrars. The majority of small business do not have a separate account for DNS.
In the old days, you could buy a Toshiba, Mitel, etc. PBX and if the hardware didn’t fail and you paid the phone bill it would run. It should be a goal of FreePBX to come as close to that as possible. If the hardware doesn’t fail and you pay your ISP, trunking provider and registrar, it should run! Every additional required third party account is a hassle and point of failure; the design should avoid them wherever possible. (Somewhat off topic, the design should also minimize the probability of an automatic update breaking something.)
No, it’s not incompatible for most. Every one has a DNS service and most actually have an API or ‘log in’ method to manipulate your TXT records to enable DNS-01. DO, Vultr, Godaddy, namecheap and cloudflare to name some popular ones. Otherwise legit ones would allow you to move your NS records to ‘any of the above’ for a nominal or free cost . Show me one that doesn’t and have [email protected] fix it if possible 
Currently the acme client provided by FreePBX is woefully asshalfed and will likely break by July , no?
JM2CWAE
Two year certs will very soon be a thing of the past, get over it
Sorry, I didn’t realize that the client could work with non-API DNS management. Assuming that it’s not a frail kludge that will fail because of a minor change to the provider’s site, then I agree that DNS-01 is the way to go, because it doesn’t require any inbound connections at all. You could still allow HTTP if someone had an unusual setup where DNS verification wouldn’t work.
One downside is that if you change registrars (or separate DNS providers), a matching config change on FreePBX would be needed.
There is always advantage in using a robust and reputable DNS service and the cost is often surprisingly affordable. (Cloudfare, NameCheap)
Pretty well, have your well named certs put in /etc/asterisk/keys/ and have ’ fwconsole certificates’ do its “worst” on the update hook
There are some valid security concerns (not specific to Google) noted in
It appears that if your PBX gets hacked into and the DNS API key stolen, with most registrars the attacker could rewrite your A records and with some they could even transfer your domain away!
Maybe briefly opening port 80 is the lesser of the evils.
I believe you can automate to open port 80 during the provisioning process.
This quoted section of the wiki page was written many years ago and has since been updated with a note at the top indicating things are out of date. The page was written before the existence of the PBX Firewall module, so the underlying assumption is that the system is mostly secured by an external device. The part warning about providing access to port 80 is meant to warn against providing untrusted access to the Admin GUI, which is assumed to be running on port 80.
The page is useful for general information, but is too stale to be of much value today on a current system.
If you want to do it that way use a ‘Bastion’ machine to generate and distribute certs
,that waty there is no key on the machine, there are however much juicier pickings like access to your trunks.So you probably still need to guard against root access