I’ll admit that my config might be screwed. This is our PBX and I often test things out on it more than I should, instead of spinning up a test system.
So someone take a look and tell me what I may have done wrong.
Got the email saying cert failed to renew.
So I popped on.
Well that is not right.
SysAdmin Pro shows this on the Port Management.
The Firewall shows this.
The certificate should be updating.
Assuming your certman and firewall modules are up to date, then there is only one specific firewall config required. The firewall advanced setting, “Responsive LetsEncrypt Rules” must be enabled. If it is then the firewall temporarily allows inbound LE token requests on port 80 while the LE cert renewal is in progress. Obviously any external firewalls must also be configured to pass port 80 traffic.
Pretty much always. and always before I post an issue.
And it was not. I never changed this, and the system has been upgraded over time from FreePBX 14. SO it was disabled by default when the setting was added.
This means you all missed this in the messaging about this change, and that none of the “normal” settings say a damned thing about checking this.
All these other LE settings need removed or cleaned up to tell people to do this
Just confirmed that the default setting is enabled on a new firewall module install, is it possible you disabled the setting yourself, possibly long before it was hooked automatically by certman?
Not a chance. And that does not preclude that all the messaging about LE on the other screens make no mention of the setting.
When I submitted the pull request for my le rule changes to replace the version that was crashing the firewall, I didn’t give an option to enable or disable le rules (they were always enabled).
There were some comments from QA about not being able to disable them, so I reworked into what you now see. I’m pretty happy with current structure. It gives the end user control over what the firewall actually does and removes some naive assumptions about port usage of the original Sangoma approach.
A mistake was using the existing lerules db flag for the new “responsive le rules”. The original Sangoma le rules had the option disabled by default. I changed the flag to enabled by default, but folks that upgraded the firewall during the period the original Sangoma lerules were in the wild, and did not enable the original le rules setting may find the new “responsive lerules” disabled.
I should have created a new db setting that wouldn’t have been inherited at all. If you dig through the tickets and commit comments, I’m pretty sure I brought the potential issue up, but didn’t make a fuss about it.
Most all the work was on the firewall side of the fence. I didn’t do anything with the messaging in certman itself, but adding a warning that the responsive lerules are disable makes sense.
Thanks @jerrm, that explains the change. The current defaults are correct, but will cause confusion in the near term. I have a ticket open now to get the GUI check back and ensure a warning is displayed in Certman if you’re using LE certs and the advanced setting is disabled.
Nothing to get back, AFAIK there was never a check. Make it a public ticket - no promises, but now that it annoys me, a PR may show up if it’s a boring TV night.
Going back through git, I see the prior warnings - they had been removed before I started making changes.
I can restore something similar, but there are valid configs that would be OK without lerules enabled. I’m a UI minimalist and cringe at a having an invalid warning up all the time.
Now that the GUI LE output is readable, I would lean toward adding more descriptive suggestions upon failure, something like showing any or all of the following as appropriate if the update fails:
Internet zone access is not enabled for the LetsEncrypt service. Enabling Responsive LetsEncrypt Rules is recommended at Firewall->Advanced Settings.
Responsive LetsEncrypt Rules are not enabled. Responsive LetsEncrypt Rules can be enabled at Firewall->Advanced Settings.
LetsEncrypt will always send challenge queries to port 80, but no http service is listening on port 80. FreePBX http services are currently listening on ports 81, 84, 8080. Certificate requests will fail unless an up stream firewall or proxy redirects port 80 to a listening http port.
etc…
Verbiage needs work, but you get the idea.
Thoughts?
Yeah, that’s in line with what I was thinking and how I recall it working back when it was added.
Stayed at home babysitting the past couple of days and hacked at this. Just posted a PR on the above ticket. Added comments and screen shots to the ticket.
Take a look and tear it apart. Still not entirely happy with some of the text, but think it’s good enough.
