this post was submitted on 15 May 2026
14 points (100.0% liked)

Selfhosted

50711 readers
999 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

  7. No low-effort posts. This is subjective and will largely be determined by the community member reports.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 2 years ago
MODERATORS
ruud@lemmy.world
Loki@lemmy.world
CannaVet@lemmy.world
devve@lemmy.world
HybridSarcasm@lemmy.world
HybridSarcasm@lemmy.hybridsarcasm.xyz
14
Need help figuring out how to write Let's Encrypt ACME servers into banIP allowlist (OpenWrt) (feddit.org)
submitted 12 hours ago* (last edited 10 hours ago) by Lemmchen@feddit.org to c/selfhosted@lemmy.world
12 comments fedilink hide all child comments
 

Recently I've installed luci-app-banip on my OpenWrt router and blocked most countries from accessing my services on my network. Not seeing why I would want any of that traffic I also blocked the whole of the ARIN registry, responsible for IP addresses from Canada and the United States.
Edit: Note this is only for inbound traffic. Outbound traffic is allowed no matter the target country.

Fast forward a few weeks and my certbot renewals fail with the following error: Failed to renew certificate enter.domain.here with error: HTTPSConnectionPool(host='acme-v02.api.letsencrypt.org', port=443): Read timed out. (read timeout=45)

Confused af I start looking for solutions and as so often only find useless or completely ridiulous solutions (lowering my MTU to 1300, what? WHY?). Finally I find some enlighted figure that says they recently enabled a blocklist for certain countries and that was the issue for them.
Now I make the connection to my use of banIP, re-allow the USA and my cert renewals start working again. Hooray!

However, there are two things bothering me:

  1. Why would such a block even interrupt my renewals? I'm using DNS challenges and the ACME servers should only check the DNS entries, not where those entries actually redirect to. The DNS server/root isn't in my home network, so isn't affected by any firewall shenanigans I do here.
  2. How can I make an exception for the Let's Encrypt ACME servers while blocking the rest of the ARIN IP space?

I see there's the option for ASN selection and external allowlists:

Does anybody have an idea on how to configure this so that Let's Encrypt continues to work without compromising on my network security?

(Edit: And just for clarity, I do not live in the US or anywhere on the American continent.)

top 12 comments
sorted by: hot top controversial new old
[–] bigredgiraffe@lemmy.world 1 points 4 hours ago

So I am pretty sure that error is happening because certbot can’t retrieve the certificate which is coming from that API no matter what type of challenge you are using (this is what ACME is).

Now when you say you are blocking inbound traffic, have you made an exception for established outbound session return traffic? If not then you your inbound rule will block all traffic because without that exception the explicit deny will typically override any session/stateful based rules your firewall might have by default (this applies to most firewall vendors I have run into).

That said, I’m not sure what your goal is but blocking outbound traffic to those ASN might be more effective for you anyway because your firewall should already be dropping any inbound traffic that isn’t otherwise allowed so I’m not sure blocking inbound traffic really gains you anything but I’m just guessing. Hope that all makes sense!

[–] Cyber@feddit.uk 2 points 9 hours ago

Ok, bare with me, I've had roo muxh to drink, but, don't ban the world, only allow countries you want.

Now, Let's Encrypt is a US entity, so whilst you might not want to allow the US in, perhaps allow countries + Let's Encrypt subnet

Also... still block some countries for outbound too... like blocking any C&C destinations.

If I'm waay off, sorry, I'll try to respond in the morning when I'm not drunk.

[–] AcornTickler@sh.itjust.works 3 points 12 hours ago (1 children)

Forgive my ignorance as I am very new to networking. Does it not look like it is the other way around? Your certificate manager tries to connect to Let's Encrypt and fails? Even with DNS challenges, your certificate manager has to tell Let's Encrypt to check your DNS records somehow.

[–] Lemmchen@feddit.org 1 points 11 hours ago

Outbound traffic has never been blocked, so it's not a matter of me or my "certificate manager" being able to reach Let's Encrypt.

[–] qprimed@lemmy.ml 2 points 12 hours ago* (last edited 12 hours ago) (1 children)

The DNS server/root isn't in my home network

are you using external DNS hosting? is it in a (now) blocked country? if so, then your local certbot is unable to update the DNS server records (return traffic from your DNS host is being blocked by your iptables/nftables config).

error: HTTPSConnectionPool(host='acme-v02.api.letsencrypt.org', port=443): Read timed out. (read timeout=45)

yeah, that would suggest an https renewal method. had you previously configured web server renewal at all before switching over to DNS? any other suspicious notifications in the logs?

edit: in thinking about this a little more... the renewal has to be initiated by your host, and that is likely done via https (you talk https to the acme server and tell it you want a renewal by DNS). so, if you are blocking the acme servers then the same issue applies - no return traffic.

[–] Lemmchen@feddit.org 1 points 11 hours ago* (last edited 11 hours ago) (1 children)

I've been using DNS challenge for this domain from the start. I'm not sure what you mean by external DNS hosting. The domain is from netcup, the certbot host runs in my local network (as does the HTTP server that the domain points to).

Netcup is a German hosting company, I live in Germany, inbound traffic from Germany is NOT blocked on my router, outbound traffic isn't blocked at all.

[–] qprimed@lemmy.ml 1 points 11 hours ago* (last edited 11 hours ago) (1 children)

not sure what you mean by external DNS

not hosting your own DNS server. specifically it sounds like your DNS server is hosted on your domain provider, not your own local network. you have set up certbot to automatically configure your remotely hosted DNS server for the DNS based renewal.

if DNS based recert was working before then it should be working now.

as I said in my edit, you are likely blocking the return https traffic from the US based let's encrypt acme servers - so your initial diagnostic is correct. your local firewall is likely stopping the acme servers from talking back to your local host.

you are right back where you started, asking for info in how to allow-list the acme IP ranges. but at least we may now know why it is not working and you are seeing an https timeout even though you are using DNS based certificate renewals.

edit: typos

[–] Lemmchen@feddit.org 1 points 10 hours ago (1 children) 
$ grep -i "dns" /etc/letsencrypt/renewal/enter.domain.here.conf

authenticator = dns-netcup
dns_netcup_credentials = /path/to/netcup/credentials.ini

AFAICT it is using DNS challenges, unless the cerbot netcup plugin somehow does stuff it shouln't need to do.

[–] qprimed@lemmy.ml 2 points 10 hours ago

agreed. you are using DNS-01 challenges. so the workflow is...

your local certbot machine initiates an https connection to the letsencrypt servers to start the DNS-01 challenge. during this HTTPS dialog, your local certbot is informed of the key material to insert into your DNS records. your local certbot then modifies your netcup DNS server (hosted remotely, not on your local network) with the keying material and the letsencrypt servers verify that the keys are actually there, proving that you control the domain. the letsencrypt serves then issue you the certificate (again, via HTTPS) and your local certbot stores it in your local host.

the issue is most likely stems from the initial HTTPS connection that certbot tries to make to the let's encrypt servers. while your firewall allows this traffic out, it does not allow return traffic back in because of your explicit blocking of US (and perhaps other) based addresses.

even through your are using DNS for your domain autentocation, your local host - the machine running certbot - is unable to initiate the certificate transfer because of the firewall blocking return traffic.

the two external networks (and, therefore IP ranges/subnets/etc) that are important here are the let's encrypt servers and the netcup DNS servers. certbot will have to talk to both of these in order to function.

[–] ShellMonkey@piefed.socdojo.com 1 points 11 hours ago (1 children)

Assuming that the 'enter.domain.here' is a masking of the real domain, I would have to wonder if the acme client is actually trying to use the http validation rather than DNS. You could pcap on the outside to look for it coming in to confir.

As for filtering to specifically allow their addresses, I think their system has a unique user agent that you could filter against, or use an inbound proxy to allow global access to the '/.well-known/acme-challenge/' path while keeping the rest of the site blocked.

[–] Lemmchen@feddit.org 1 points 11 hours ago* (last edited 10 hours ago)

enter.domain.here is simply a redaction of my real domain as I did not want to doxx myself.

[–] Decronym@lemmy.decronym.xyz 0 points 11 hours ago* (last edited 4 hours ago)

Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I've seen in this thread:

Fewer Letters More Letters
DNS Domain Name Service/System
HTTP Hypertext Transfer Protocol, the Web
HTTPS HTTP over SSL
IP Internet Protocol
SSL Secure Sockets Layer, for transparent encryption

4 acronyms in this thread; the most compressed thread commented on today has 20 acronyms.

[Thread #293 for this comm, first seen 15th May 2026, 21:40] [FAQ] [Full list] [Contact] [Source code]