Unexpected Blocking of Certificate Requests from teibasec.de

Help
1

Problem Description:
I’m contacting you regarding unexpected connectivity issues affecting certificate issuance for my domain: teibasec.de.

My server (Ubuntu 24.04 at internal hostname ub24p04.teibasec.de, public IP 89.163.234.226) has been carefully configured to use acme.sh with the dns_cf plugin for DNS-01 validation, using Cloudflare.

I’ve been running controlled and minimal test requests against the staging environment over the last 48 hours — no more than 5 test certificate requests total on May 10th, using a wildcard domain: *.teibasec.de. These were used to validate automation and NGINX integration.

Then, on May 11th, I attempted a single production certificate issuance, which initially failed due to a script misconfiguration (missing parameter). Upon correcting the issue, I attempted again and were immediately blocked!!

Since then:

Both curl -v https://acme-v02.api.letsencrypt.org/directory and acme.sh requests fail with timeout errors, even over IPv4.

  • Staging (acme-staging-v02.api.letsencrypt.org) was previously rate-limited too, but has since resumed.
  • My current staging and production requests never exceeded recommended limits
    and did not result in duplicate certs.
  • This seems to be a temporary IP-based block, possibly mistaken or overreactive.

I am requesting your assistance and support in clarifying:

  1. Why is our IP (89.163.234.226) currently blocked from accessing the production ACME API?
  2. Is this block rate-limit related, and if so, how long should I wait before retrying?
  3. Are there logs or metrics I can check to avoid this in the future?

I respect Let’s Encrypt’s infrastructure, use proper staging before production, and aim to automate responsibly. Understanding what triggered the block would help me stay aligned with best practices.

Thank you in advance for your distinguished support.

Kind regards,
Khaled

2

Tell us what you get from these commands:

ip route get "$(dig +short acme-v02.api.letsencrypt.org|tail -n 1)"

traceroute acme-v02.api.letsencrypt.org

What could have happened is some router on your network is confused and believes 172.0.0.0/8 to be a private range. It's not. The private range is 172.16.0.0/12

5 Likes
3

Hello @khaledfa2,

From around the world connection to the domain name seems blocked
see HTTP Permanent link to this check report
and HTTPS Permanent link to this check report

Has something happened to your router and/or firewalls?

Edit

Also here is a list of issued certificates crt.sh | teibasec.de,
it doesn't seem like the Rate Limits have been hit.

3 Likes
4

Much more likely that your own network (or network provider) is blocking your outgoing requests, Let's Encrypt rarely block IPs.

4 Likes
5

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