Certbot failed to authenticate domain due to timeout

I'm following this tutorial in how to get a raspberry pi matrix-synapse homeserver up and running.

Everything seems to be working fine. The matrix-synapse confirmation page loads. I'm able to get through every step except the certbot step. I assume there's a prerequisite that I don't have installed. I thought it might be wanting acmetool, so I installed that, but it gave me a "too many failed authorizations recently" error before I could test that. Would anyone else happen to know something that I might be missing in this? I'm guessing it's simple and I'm missing it due to lack of experience/knowledge about web server hosting and its prerequisites.
I also had ufw disabled during this process to make sure it wouldn't interfere with anything.

My domain is: dragonmail.contact

I ran this command: sudo certbot --nginx -v

It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx

Which names would you like to activate HTTPS for?
We recommend selecting either all domains, or all domains in a VirtualHost/server block.


1: dragonmail.contact


Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel): 1
Requesting a certificate for dragonmail.contact
Performing the following challenges:
http-01 challenge for dragonmail.contact
Waiting for verification...
Challenge failed for domain dragonmail.contact
http-01 challenge for dragonmail.contact

Certbot failed to authenticate some domains (authenticator: nginx). The Certificate Authority reported these problems:
Domain: dragonmail.contact
Type: connection
Detail: 172.94.33.141: Fetching http://dragonmail.contact/.well-known/acme-challenge/IygG7OZr3Gf7DZVPxQH8K4MS72fJ7JVmhUJDeeRTcWg: Timeout during connect (likely firewall problem)

Hint: The Certificate Authority failed to verify the temporary nginx configuration changes made by Certbot. Ensure the listed domains point to this nginx server and that it is accessible from the internet.

Cleaning up challenges
Some challenges have failed.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

My web server is (include version):
nginx version: nginx/1.18.0 (Ubuntu)
But I'm using the matrix-synapse docker image.

The operating system my web server runs on is (include version):
5.15.0-1015-raspi
PRETTY_NAME="Ubuntu 22.04.1 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.1 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="Data privacy | Ubuntu"
UBUNTU_CODENAME=jammy

My hosting provider, if applicable, is:

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):
certbot 1.30.0

Have you performed the port forwarding part of the tutorial you are following?

It seems like neither ports 80 nor 443 are open to the internet right now, and they need to be.

You should check with your ISP also, whether they permit incoming traffic on these ports.

5 Likes

I have very little experience with setting this up lately. I used apache2 years ago but nginx is new to me.
nginx 978 root 6u IPv4 24892 0t0 TCP *:80 (LISTEN)
nginx 979 www-data 6u IPv4 24892 0t0 TCP *:80 (LISTEN)
nginx 980 www-data 6u IPv4 24892 0t0 TCP *:80 (LISTEN)
nginx 981 www-data 6u IPv4 24892 0t0 TCP *:80 (LISTEN)
nginx 982 www-data 6u IPv4 24892 0t0 TCP *:80 (LISTEN)
docker-pr 1815 root 4u IPv4 27887 0t0 TCP *:8008 (LISTEN)
docker-pr 1828 root 4u IPv6 27894 0t0 TCP *:8008 (LISTEN)

It shows that nginx is listening on port 80 and the firewall is disabled now, but attempts to use it timeout. Is there a way to check and see what's going on? I looked at the nginx logs and if something is sending a request my way I can't see it in the logs at all. I can confirm that I can use port 8008 because when I use a web browser to load the page: http://dragonmail.contact:8008/_matrix/static/
it works as it should and serves up the page even on my phone, but not 80 even though nginx is set to listen on 80. I will read through more of the nginx docs and see if something jumps out at me. Thank you!

Did your IP change?:

Name:    dragonmail.contact
Address: 172.94.33.174
3 Likes

@flarefox It could very well be a problem with a device other than your server (like your home router/gateway, or your ISP's router or firewall). That's part of what @_az was getting at.

It's important to check the firewall status there on your server, as you did, but a next step could be checking about the path from the Internet to your server, as something is probably interfering there.

(@rg305's question about why your IP address changed is also interesting.)

4 Likes

Oh yes. Every time I reboot my IP is different and I update my DNS to account for it. Doesn't take long to do and I planned on just scripting the update to be automatic once I could confirm that everything works.

Right, ok. I'm not sure how to check everything other than by using the let's debug site to check. I have nothing blocking my connection and I'm connected through a pptp vpn which forwards everything, so there shouldn't be anything blocked. Is there a tool to check that? Thank you very much for your help!
That being said, it does seem like it's something with my server configuration. Port 80 responds, but not when I try to use the acme challenge. I get a timeout every time it tries a /.well-known/acme-challenge/ url.

1 Like

Where and how are you checking that? I'm not able to connect to it at all myself.

2 Likes

huh. Weird. I see the same thing. I can't connect to it through the vpn but I can connect to it directly locally. Is there somewhere in the system where all incoming traffic is logged so I can see if the server sees it and is rejecting it or if it's somewhere else? I confirmed that my router has all the port forwarding settings set. I need to check the vpn setup, though, and I don't know how to confirm that. Is there a test I can run?

Doesn't seem to matter if the vpn is up or down. Port 80 isn't responding to anything. I have forward set and I only get a response for port 80 if I go to the confirmation page:
http://dragonmail.contact:8008/_matrix/static/
and replace it with the local equivalent without the port:
http://192.168.3.199/_matrix/static/
It works fine, but that's probably just a glitch. If I go to dragonmail.contact without a port or the ip without a port and without the _matrix/static/ on it, no response. It also doesn't show up in the logs, so I think I have something misconfigured somewhere.

For the most detailed view of what IP packets your computer is receiving, you could run a packet sniffer like Wireshark. The output can be quite voluminous and detailed, but it really makes clear exactly which communications are or are not happening!

2 Likes

Thank you! That told me that port 80 is indeed closed. I'm not sure what I'm supposed to do to open it, though. My sites-available/enabled config file is:

server {
        server_name dragonmail.contact;
        root /var/www/html
        location / {
                proxy_pass http://localhost:8008;
        }
}

because that's what the web tutorial showed. Though there's more at the end when they enable making it federated and I should add that in at some point, but I just want to see it work first.

There should be a listen statement within each server block.

3 Likes

Thank you very much! It works now. I didn't realize my system came with apache already installed and running in the background. It had bound to 80 and wasn't responding because it wasn't configured. Once I let nginx take over, everything is good now. Thank you!

2 Likes

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