Let's Encrypt Certificate renewals failing

From memory, I implemented the LE-Only port in sysadmin about 3 years ago, when LE said they were going to send requests from anywhere. Because of that, Sysadmin already does this for you, there’s no need to mess around with string matching in packets.

I’m kinda surprised that no-one else mentioned this. That’s what it’s there for. It 404’s and fail2bans anything that tries to scan it, and responds happily to LE.

1 Like

It has been mentioned several times, but you have to be ok with only using port 80 for LE. I haven’t reviewed the fail2ban code relevant in your example, but this also sounds likely to ban legitimate users who aren’t specifically entering https or port 81 in the url.

That’s the only port LE uses. So if you want to use LE, you have to use port 80.

Secondly, if legitimate users are going there, read what the screenshot says.

I did mention this. Apparently nobody read it.

1 Like

Just to be complete, LE only needs port 80 when using HTTP-01 protcol No open ports thus no firewall fiddling is needed for LE when using DNS-01 .

Is there a way to issue CLI commands to change the Lets Encrypt port to 80, change the admin port to 81, and then set the Lets Encrypt Services to the Internet Zone? I have quite a few PBXs and it would be great if these changes could be made in mass.

Thanks so much thx2000!!!

Your solution is what I was looking for–and it works—and it’s secure enough for me.

1 Like

The other thing to note (if like me you enforced LE connections on the border firewalls) that LE have started verification of the .well-known/acme-challenge from multiple global addresses - to stop (minimise) local redirection of the challenge. The solution for me was [but I only have one service] was open 80 to all incoming addresses, refresh the LE cert and lock down again.
Not ideal, and I wish LE would allow you to specify a query port when making the first request (and FreePBX open up Fail2Ban for the duration of the queries).

In my recent testing of LE creation and validation, I noted that when LE validates from their servers, they have a very identifiable user agent string, as seen in the apache log:

52.28.236.88 - - [08/Apr/2020:19:40:11 -0300] "GET /.well-known/acme-challenge/<redacted> HTTP/1.1" 200 87 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"

So one could whitelist the Sangoma servers and the PBX by source IP and then use @thx2000’s earlier rule to allow inbound from LE’s user agent. I don’t know if LE has a stated position on whether or not their user agent string will remain fixed or not, but I’ve not really investigated since user agent is trivial to spoof.

The next version of the PBX Firewall module will have a feature that allows world access to the LE token folders if you don’t wish to dedicate port 80 to LE.

2 Likes

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