Timeout error when using certbot nginx

Help
1

My domain is: test.moonbyte.net

I ran this command: certbot -d test.moonbyte.net --nginx -m corporate@moonbyte.net --agree-tos --redirect --non-interactive --
keep -v

It produced this output:

Certbot failed to authenticate some domains (authenticator: nginx). The Certificate Authority reported these problems:
Domain: test.moonbyte.net
Type: unauthorized
Detail: During secondary validation: 2606:4700:3031::ac43:d07d: Invalid response from http://test.moonbyte.net/.well-known/acme-challenge/_jmAxZ_cW_0rwkad1CKJC4lkSm50FloKWm21nB-bTQg: 522

My web server is (include version): Nginx (latest 1.20.1)

The operating system my web server runs on is (include version): Alma Linux 9.4

I can login to a root shell on my machine (yes or no, or I don't know): Yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): No

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): 2.11.0

I can access the site just fine through both port 80 and 443, all firewall restrictions for cloudflare IP's only are removed. I can access this web server directly without proxying through cloudflare, or by directly accessing the IP of the web server. Without proxying through cloudflare it will give a direct HTTP timeout error, proxied through cloudflare will give a Cloudflare timeout error.

Does not make any sense to be honestly, server is reachable there is no firewall restrictions but it still can't access the site. Possibly an issue with Certbot / NGINX?

2

Are you blocking requests from non-USA requesters?

Because Let's Encrypt can reach you from its Primary location in the USA but not from one or more of its Secondary centers outside the USA.

The geography block would be at your Origin server, not the Cloudflare settings, to behave as your describe.

As background if this is the case:

4 Likes
3

That was it lol... I feel dumb now for not checking that

Thank you so much for the help!

3 Likes
4

Wouldn't the source IP address be from Cloudflare?

Although I guess they'll send the original source IP address in an HTTP header and you can blocklist off that too of course.

1 Like
5

Yes, but their edges are also distributed world-wide. And, the nearest to the requester is (usually) chosen. There is some complexity involved in what IP is seen by the Origin and where (like in forwarded-for header or other).

In any case, they said they had the same problem when not proxied.

When they were proxied I saw Let's Debug's tests from its German server timed out so whatever method they used to block non-USA was effective even behind the CDN.

3 Likes
6

I believe my firewall is currently blocking the request based on the original source IP address. In both cases, proxied, or not I was getting a time out error.

I'm going to test this tomorrow through my automated deployment process, but based on the test.moonbyte.net domain after removing country restrictions from my firewall this started working against test.moonbyte.net so I don't see why it wouldn't work against my other sub domains.

7

I need to do some testing to confirm if my firewall is blocking the request based on the original source IP though... But my assumption to this is based on GDPR policies. Until we meet the requirements of GDPR I wanted to make sure all countries under GDPR was blocked. For GDPR you want to be blocking requests coming from a GDPR country, even if their traffic is being routed through cloudflare and the edge node is not in their home country.

8

Confirmed, firewall was blocking based on origin IP. After removing country restrictions this is now working through my automated deployments.

1 Like
9

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