No new certificate (Let's Encrypt) for my mail server

IPFire 2.27 (x86_64) - Core Update 169

Hello, again,
Let’s Encrypt worked fine for a long time … but:
Since 18.08.2022 every day I got this warning:

/etc/cron.daily/nethserver-letsencrypt-certs:

Challenge failed for domain bma.firma.de
Challenge failed for domain mail.firma.de
Some challenges have failed.

The reason was location filter of IPFIRE. We only allowed

  • Germany
  • Austria
  • USA (for Let’s Encrypt update )

But Let’s Encrypt has changed something and now I have to disable location filter to get new certificate
Is there no other elegant way ? How to solved the problem ?

Funny, just encountered the same issue with the renewal process here on my side.

So far LE did access IPfire’s web server from US servers only, which has obviously changed or does change randomly.

I too, automatically disabled the location block for country US previously, but this fails now. Not the removal of the country block, but the subsequent LE challenge.

After completely manually disabling location blocking on IPFire, and restarting the renewal process, all ran well.

So, my question is as above: How do others renew their certs with active location block, using an automated process, e.g. a script?

It’s ridiculous to always disable location blocking manually prior to renewing the certs each month, right?

Good morning,
I see only 2 ways:
A)

  • special firewall rules that opens port 80 for 30 minutes and disable location filter for that time
    … I saw something like this … but can’t find it again
    … now found it: Let's Encrypt - Location filter and firewall rule (command) - #3 by pablo78
    … I began this … and it’s very tedious to add all countries to the list
    Is there a way to ADD ALL COUNTRIES with 3…4 clicks to the list??

B)

  • install and configure Lets Encrypt at IPFire ?
    … this would be the better way - we have to search …

Option A is not really an alternative in my case because I’ve already set up Option B that uses the IPFire package Dehydrated for creating and verifying LE certs.

Option B causes this issue on my side, because of active location blocks for all countries but Germany.

A bash script starts the certs renewal process and so far the script removed the location block for the US beforehand.
For some unknown reasons, this is not working anymore and I suspect that LE now uses other countries IP addresses other than US for the challenging process.

I quick test, revealed this is true. I stopped location blocking at its whole and the challenge process worked like a charm.

Basically this means, I don’t know each country which LE uses and that I have to remove from location block and I do not know how to switch off location blocking completely for the time LE needs access to IPFire web server.

Someone made a comment about the location block somewhere that made me rethink the way I was using the location block.
So I made a location group instead.
And use the location block for the worst places like XD.not sure how much this effects anything. It gets the job done.

Maybe this post here?

I’ve found a list of LE domains that are responsible for the challenge process here but unfortunately no IP addresses and no ASN that could be used to open the firewall for those.

A group for what? Block certain countries instead of using the whole location block thingy?

Yes it was a little time consuming. But yes.
In groups there is a option for location. So I made a group for server and a group for everyone else.

And the server is IPFire or a web server behind IPFire?

Yes. Either way.
You can make multiple location groups with different access.
So as a example
Ipfire location group access all countries except XD.
User location group access Germany
XD could be blocked by location block

Found the reference

Thanks for your reply!

Slightly OT: I’ve read somewhere that XS is not necessary when the option

Drop packets from and to hostile networks (listed at Spamhaus DROP, etc.)

is already enabled in Firewall options.
A quick test revealed:

  • When disabling location blocking and let the above FW option active, I still see FW logs with chain DROP_HOSTILE in the logs.
  • When disabling the FW option, DROP_HOSTILE does not appear anymore.

Don’t know if both possibilities are treated equal or if there any differences?

The only difference I see: country block XD does not create any log whereas the active FW option does. This obviously complies with your finding above:

The sole purpose of the location filter is to reduce noise in the logs, it’s security importance is rather low in my personal view.

1 Like

Glade you found the info helpful.
I do not have any coding or scripting skills.
Just trying to do the best I can.
Glade I could help.

Not sure if the location block is a ipsets?
And a fire wall group of location is not?
A ipset would use less resources.
Atleast that is my understanding.

I had the exact same problem with certbot to renew Let’s Encrypt certificates with error: Timeout during connect (likely firewall problem).

To fix: in ipfire v171 > Location Block I had to disable the code/country: A3/“Worldwide Anycast Instance”.
now everything works again with certbot.

2 Likes