The issue with let's encrypt certificate updating

With respect, given any knowledge of letsencrypt’s published methods of validation also

Would not a needed ‘feature request’ have been obvious and self generated by the devs a year or so ago ?

I am attempting to change the Admin to Port 85 but when I click update now the gear in the top right just spins and the update doesnt happen. I am having this exact problem with the error for updating the certificate.

Thanks
Phil

Possibly you have pending system updates: Recent update to sysadmin rpm

Ok so updates must have been an issue. I thought I had done them all last night however there were more today. So I am now able to get the Admin port changed to 85 and the LetsEncrypt port to 80 however I still get the “There was an error updated the certificate: Verification timed out” message. I made sure the lets encrypt networks were not in the PBX Firewall however I do have them noted in my pFSense firewall to pass port 80 to the pbx server.

Things I’ve now done three times to work around around this very issue in the last week:

  1. fwconsole chown
  2. TEMPORARILY disable the FreePBX firewall. Standard warnings and noting that Lorne has said this should not be necessary.
  3. Reboot the system.

In two cases I could load the challenge file remotely via the URL but the request still failed until I rebooted the system.

I wish I had more insight into what’s actually going on, but I don’t; we’re doing these installs on fixed-cost basis so we have to be as efficient as possible.

Confirm that your pfSense passes port 80 with no restrictions on source IP.

Well using a port checker from an outside address port 80 does not show as open. Are you familiar with pfsense? Below is my NAT Rule and the destination is set to the correct IP address.

LE changed their policy and now send verification from random IP addresses that are not publicized in advance. I don’t know pfSense but you need to change the Source field of your redirect to allow any IPv4 address.

1 Like

Technically, LetsEncrypt has never changed their policy at least as of 2017, they just chose to enforce it as of February 19th 2020 :slight_smile:

Further, Acme v1 is deprecated

Sometimes the verification times out even though everything is fine, it depends on how loaded their servers are and from which IPs they are cross validating. In those cases, if you try it a second time (rarely a third), it will work.

Renewals won’t be a problem since it keeps trying automatically periodically once its due for renewal.

Thanks for the responses, The issues was in my firewall on pfsense. I was able to get it to update with a new date of 6/13/2020 however it still shows on the dashboard that there is a certificate about to expire. The only other certificate in the manager is a default self signed one.

I take that back. It looks like it has cleared now and is all set. Thanks for the help.

I’m pretty green when it comes to iptables, but I messed around with it long enough to get a working proof of concept. I’m hoping someone can tell me if this is a bad idea and/or how it could be improved.

Start by enabling “Custom Firewall Rules” via Connectivity > Firewall > Advanced > Advanced Settings > Custom Firewall Rules: Enabled

edit /etc/firewall-4.rules and insert

#Lets Encrypt
#Create lefilter chain
-N lefilter

#Remove FreePBX rule that allows all established states through
-D fpbxfirewall -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT

#Insert rule into INPUT chain to pass all port 80 traffic to lefilter
-I INPUT -p tcp -m tcp --dport 80 -j lefilter

#Insert rule back into fpbxfirewall chain to allow all established traffic except for traffic on port 80
-I fpbxfirewall -p tcp ! --dport 80 -m state --state RELATED,ESTABLISHED -j ACCEPT

#Allow new port 80 states to be generated
-A lefilter -m state --state NEW -j ACCEPT

#Filter subsequent traffic to allow access to /.well-known/acme-challenge
-A lefilter -m string --string "GET /.well-known/acme-challenge" --algo kmp -j ACCEPT

#Return back to the INPUT chain for further processing
-A lefilter -j RETURN
#End of Lets Encrypt

Ensure /etc/firewall-4.rules is owned by the ‘root’ user and not writable by any other user. If it’s not, then ‘chown root:root /etc/firewall-4.rules’ and ‘chmod 644 /etc/firewall-4.rules’.

Stop and start the firewall, either in the gui or on the command line. From the command line: ‘fwconsole firewall disable’ then ‘fwconsole firewall start’

After that, with any luck, letsencrypt traffic on port 80 will get through, any other exceptions will continue to get through, and any non-whitelisted traffic to port 80 should be dropped.

I’m hoping this, or something like it, can be added to the official distro/firewall module. My fear now, is that the ‘fpbxfirewall’ rule that I’m removing could be renamed which will prevent this custom rule from removing it, and subsequently allow all port 80 traffic through.

1 Like

Yeah. I got the same error, thanks for the comments of all of you, now I have fixed it

Had a system with a valid cert that needed to be renewed today. I have to open port 80 to the world and disable the responsive firewall to get that done. I tried several times with the firewall enabled; no dice. I could load the response file via port 80 remotely with the firewall enabled, but it’s an IP from which a phone has connected repeatedly in the past. I could see the packets being passed through the network firewall to the FreePBX LAN IP, but the responsive firewall didn’t seem to play nice with them.
I’m happy to do a packet or log capture on this if SNG staff want, I didn’t want to do without specifics though.

The method I posted above works. Lorne is running it up the chain to see if it’s something they could implement in the official distro.

3 Likes

Any update on this one? If this can be addressed in an update?

Exactly what i’ve been looking for,
Why do you need this part?

I’m removing a default FreePBX firewall rule that assumes if a state was created, the connection must have already passed through all of the firewall restrictions, so the traffic must be legitimate. We need all states on port 80 to be opened, and then subsequently scanned to see if they’re attempting to access the acme challenge. If the traffic is, then it’s accepted. If the traffic is not trying to access the acme challenge, it is then shuffled off onto the same rules that new states are typically subjected to.

1 Like

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.