Timeout during connect (likely firewall problem)

Help
1

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. https://crt.sh/?q=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: lokago.de

I ran this command: certbot -v

It produced this output:

2024-10-21 19:51:39,971:INFO:certbot._internal.auth_handler:Challenge failed for domain lokago.de
2024-10-21 19:51:39,971:INFO:certbot._internal.auth_handler:Challenge failed for domain www.lokago.de
2024-10-21 19:51:39,971:INFO:certbot._internal.auth_handler:http-01 challenge for lokago.de
2024-10-21 19:51:39,971:INFO:certbot._internal.auth_handler:http-01 challenge for www.lokago.de
2024-10-21 19:51:39,971:DEBUG:certbot._internal.display.obj:Notifying user:
Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:
Domain: lokago.de
Type: connection
Detail: 207.154.228.245: Fetching https://lokago.de/.well-known/acme-challenge/5j95xih_S-ILzOlVKDrhfq0xiVJ_G4erDPEIZUiRKj4: Timeout during connect (likely firewall problem)

Domain: www.lokago.de
Type: connection
Detail: 207.154.228.245: Fetching https://www.lokago.de/.well-known/acme-challenge/j-OljrvHqEQs2bC5Tsl3FXiLfR2MB3EVm4qBN9i6YQs: Timeout during connect (likely firewall problem)

Hint: The Certificate Authority failed to download the temporary challenge files created by Certbot. Ensure that the listed domains serve their content from the provided --webroot-path/-w and that files created there can be downloaded from the internet.

2024-10-21 19:51:39,972:DEBUG:certbot._internal.error_handler:Encountered exception:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/certbot/_internal/auth_handler.py", line 108, in handle_authorizations
self._poll_authorizations(authzrs, max_retries, max_time_mins, best_effort)
File "/usr/lib/python3/dist-packages/certbot/_internal/auth_handler.py", line 212, in _poll_authorizations
raise errors.AuthorizationError('Some challenges have failed.')
certbot.errors.AuthorizationError: Some challenges have failed.

My web server is (include version): nginx version: nginx/1.26.1

The operating system my web server runs on is (include version):
Linux shop-beta.lokago.de 6.8.0-47-generic #47-Ubuntu SMP PREEMPT_DYNAMIC Fri Sep 27 21:40:26 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

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): yes (spinupwp)

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

nmap -Pn -p80,443 lokago.de
Starting Nmap 7.95 ( https://nmap.org ) at 2024-10-21 22:46 EEST
Nmap scan report for lokago.de (207.154.228.245)
Host is up (0.071s latency).
Other addresses for lokago.de (not scanned): 2a03:b0c0:3:d0::1093:a001
rDNS record for 207.154.228.245: shop-beta.lokago.de
PORT STATE SERVICE
80/tcp open http
443/tcp open https
Nmap done: 1 IP address (1 host up) scanned in 1.01 seconds

1 Like
2

This is the case for IPv4, however NOT for IPv6:

$ nmap -Pn -p80,443 -6 lokago.de
Starting Nmap 7.95 ( https://nmap.org ) at 2024-10-21 21:58 CEST
Nmap scan report for lokago.de (2a03:b0c0:3:d0::1093:a001)
Host is up.
Other addresses for lokago.de (not scanned): 207.154.228.245

PORT    STATE    SERVICE
80/tcp  filtered http
443/tcp filtered https

Nmap done: 1 IP address (1 host up) scanned in 19.55 seconds
$

Let's Encrypt prefers IPv6. It's strange the challenge even got to the https:// part, as it starts with http://. Although I believe the IPv4 fallback behaves a little bit weird in that in the initial phase there's some fallback being done, but after the redirect not any more.

You need to fix your IPv6. Perhaps a firewall.

1 Like
3

Thank you for the quick answer. As far as I can tell, the firewall configuration looks good:

ufw status
Status: active

To Action From

22 ALLOW Anywhere
80 ALLOW Anywhere
443 ALLOW Anywhere
22 (v6) ALLOW Anywhere (v6)
80 (v6) ALLOW Anywhere (v6)
443 (v6) ALLOW Anywhere (v6)

Also I'm not sure why this issue suddenly popped up. It worked fine for the last couple of years...

1 Like
4

Maybe Digital Ocean changed your IPv6 address or has something interfering?

Does this show the same value as the AAAA record value

curl -6 https://ifconfig.io

I can't reach your home page on IPv6 from my own test server. Not unique to Let's Encrypt

curl -i6 -m8 http://lokago.de
curl: (28) Connection timed out after 8001 milliseconds
3 Likes
5

What show?:
curl -4 ifconfig.me
curl -6 ifconfig.me

[let's check both]

1 Like
6

HTTPS to their IPv4 address gets a cert with their domain name. Probably is right one :slight_smile:

2 Likes
7

curl -4 ifconfig.me
207.154.228.245

curl -6 ifconfig.me
2a03:b0c0:3:d0::1b30:4001

8

Ok, the AAAA record values did not match. I adjusted it, so far no change but maybe it takes a moment until it's propagated...?

1 Like
9

Those match the DNS. Did you change something? Because IPv6 is working now

Update: we cross-posted. Should work. What error message are you seeing now? Sometimes minor differences matter.

3 Likes
10

From my end IPv6 is all open now on port 80 and 443.

11

Yes, I fixed the AAAA record. I myself still can't curl on ipv6. But the certificate could now be renewed! Thanks, guys!

2 Likes
12

From what device? Does it have IPv6 support?

2 Likes
13

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