Stopped working for some NGINX server blocks - Timeout during connect (likely firewall problem)

Help
1

I just moved my data to a new server and copied all the config files including all the certs and so on.

But now I get for some NGINX server blocks "Timeout during connect (likely firewall problem)".

Server is public reachable by IPv4 and IPv6. TCP, no firewall.
I can also download a file from .well-known/acme-challenge when I place it there.

Works:

#server {
#  server_name sub.example.com;
#  listen 80;
#  return 301 https://sub.example.com$request_uri;
#}

server {
  server_name sub.example.com;
#  listen 80;
  listen 443 ssl;

  ssl_certificate /etc/letsencrypt/live/sub.example.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/sub.example.com/privkey.pem;
  include snippets/letsencrypt.conf;

  root /home/www/htdocs/foo;

  location ^~ /.well-known/ {
    root /home/www/htdocs/letsencrypt;
  }
}

Doesn't work anymore:

server {
  server_name sub.example.com;
  listen 80;
  return 301 https://sub.example.com$request_uri;
}

server {
  server_name sub.example.com;
#  listen 80;
  listen 443 ssl;

  ssl_certificate /etc/letsencrypt/live/sub.example.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/sub.example.com/privkey.pem;
  include snippets/letsencrypt.conf;

  root /home/www/htdocs/foo;

  location ^~ /.well-known/ {
    root /home/www/htdocs/letsencrypt;
  }
}

Certbot is showing the correct IPv4.

Any ideas? It's crazy because some other hosts work with the same config (always 2 blocks, first for redirect 80 -> 443, the second for 443 only). That worked always before.

2

But, you don't have any listen statements for IPv6

Does Let's Encrypt report success?
https://letsdebug.net

It is difficult to help debug comms problems without knowing the actual domain name

2 Likes
3

Is usually exactly that - a firewall rule that is blocking HTTP.

2 Likes
4

When you opened this thread in the Help section, you should have been provided with a questionnaire. Maybe you didn't get it somehow (which is weird), or you've decided to delete it. In any case, all the answers to this questionnaire are required:

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command:

It produced this output:

My web server is (include version):

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

My hosting provider, if applicable, is:

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

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

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

1 Like
5

What is giving you that error? Regular web requests or the Certbot/LetsEncrypt messages during the ACME protocol?

The issue is likely the lack of an IPV6 statement as @MikeMcQ noted. The LetsEncrypt resolvers are failing to connect on that protocol, and the operation is failing because of that. Normal web operations might fallback to IPv4 so you don't realize this, but for ACME/LetsEncrypt, that misconfiguration is fatal.

4 Likes
6

Oh yeah I had a bad IPv6 DNS entry, really stupid. Would be nice to see more details within certbot.

This is really "bad": Detail: xxx.xxx.xxx.xxx: Fetching https... : Timeout during connect (likely firewall problem) (showing the IPv4 only so I never thought about that IPv6 thing!)

8

How could certbot [or anyone else] know that IPv6 address is or isn't yours?
Whatever was at the IPv6 address that you listed in DNS must have redirected to IPv4/name OR failed to respond and then LE failed to IPv4.
It is impossible for any of us to know what actually happened, since you did not provide the FQDN.

What would you like the error message to say/contain?

2 Likes
9

I personally would like it to give the IPv6 address as the failing IP. I can understand why it doesn't but that doesn't mean I wouldn't like it different :slight_smile:

Or, when IPv4 fails because it is fallback from IPv6 timeout, use a message that indicates that it was retry failing and not initial request.

I've seen these often enough to look for it right away but not everyone has.

@Xairoo See IPv6 fallback retry docs here:

2 Likes
10

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