I’ve been troubleshooting off-and-on an issue with being able to install certificates on my FreePBX instance for several months now. I was finally able to resolve an issue with simply installing self-signed certificates in the first place and now I’ve moved on to trying to generate and install a Let’s Encrypt certificate. This instance of FreePBX has seen a couple major version upgrades; 14 → 15 → 16, so I imagine this has introduced some quirks along the way. When attempting to generate a LE cert, it simply fails with no useful information as to why:
[root@voip ~]# fwconsole certificates --generate --type=le --hostname=<redacted> --country-code=US --state=CO --email=<redacted> -vvv
Processing: <redacted>, Local IP: 127.0.0.1, Public IP: <redacted>
Self test: trying http://<redacted>/.freepbx-known/c3f075679958b68aa8aba8f32d873b61
Self test: received c3f075679958b68aa8aba8f32d873b61
Getting list of URLs for API
** Responsive LetsEncrypt Rules are not enabled. Enabling Responsive LetsEncrypt Rules is recommended. Enable at the command line with 'fwconsole firewall lerules enable' or within the web interface at
Connectivity->Firewall->Advanced->Advanced Settings.
LetsEncrypt Update Failure:
Curl:
[root@voip ~]#
The warning about responsive rules is expected here because I disabled that and made sure my edge firewall was opened up for troubleshooting. I have confirmed the ./freepbx-known/ directory is publicly accessible. What I find odd is the failure right after “Getting list of URLs for API” where it should be proceeding to “Requesting new nonce for client communication.” I’ve tried reinstalling Certificate Manager with fwconsole ma downloadinstall certman --force with no change in results. Any ideas why it might be failing or how I can get more information about why it’s failing?
I’m not sure I follow that logic. Allowing PUTs cannot be correct. According to the wiki, the only requirements are:
The local pbx must be able to http get the challenge token from itself using the fqdn provided. If the PBX is behind a NAT router/firewall this may fail depending on your router configuration. It is for this reason that you see references to setting the PBX hostname to the LE fqdn to allow this challenge to succeed.
Sangoma mirror servers must be able to http get the challenge token by resolving the configured fqdn. It is for this reason that previous firewall recommendations stated that the Sangoma mirror servers must be whitelisted.
The Let’s Encrypt server(s) must be able to get the challenge token by resolving the configured FQDN. This challenge can come from anywhere, so there is no value in whitelisting for this purpose, port 80 must be open to world for the challenge to succeed.
I don’t think the process ever makes it to the challenge phase before failing for whatever reason. I spun up a fresh install with the same firewall configurations (pfSense + HAProxy). LE certificate generation works just fine on the test instance so something must be amiss with my production server. For reference, it is the official Sangoma distro.
If you have haproxy working, then I would suggest you use DNS-01 as your acme protocol, and have haproxy provide the certification. no need for the FreePBX acme client then and no need to have FreePBX on HTTPS no need for Firewall rules.
Many recipes out there
for one, personally I use
which has a built in for haproxy and supports over 100 of the most common NameServices
The end goal here was to get Sangoma Connect set up. I was running into issues getting the HTTPS ports configured - due to the certificate installation issue - but now that I have a self-signed cert installed, it does indeed look like I may be able to configure Sangoma Connect behind my existing pfSense HAProxy configuration without having to configure a valid cert directly on the PBX itself. Assuming this will work, I will definitely go that route as that’s how I configure other servers/services as well.
self signed certs will likely not be acceptable, if you use a proxy, then understand that the proxy will reply to all connections, not FreePBX, how you set your front-ends and back-ends will define what certs are served and intercepting https/ip connections is what you need , haproxy is your safest choice, implementing strict SNI will solidify your protection
I figured out why this was failing! It turns out, because this system has gone through so many upgrades, the CA bundle had never been updated so it was refusing to connect to sites with current LetsEncrypt certificates. I used the solution in New let’s encrypt error: SSL certificate problem: unable to get local issuer certificate [RESOLVED] - FreePBX / Security - FreePBX Community Forums and am now able to generate certificates without issue. Coincidentally, my RSS feeds now load, too! I’m surprised that CA bundles are not updated/refreshed on system upgrades or at some regular interval.