Timeout during connect (likely firewall problem)

Help
1

Hi -- I've been pulling my hair out over here trying to enable https on my home server running nextcloud and piwigo using Apache (details at the bottom). The http site works, but when I run certbot all I get is "Timeout during connect (likely firewall problem)". My firewall is ufw, and allows ports 80 and 443. I even tried disabling ufw completely and running certbot, but it didn't help.

My sites-enabled folder for Apache has two files: photos.marcevanstein.com.conf, and cumulonimbus.marcevanstein.com.conf. photos.marcevanstein.com.conf looks like:

<VirtualHost *:80>
	# The ServerName directive sets the request scheme, hostname and port that
	# the server uses to identify itself. This is used when creating
	# redirection URLs. In the context of virtual hosts, the ServerName
	# specifies what hostname must appear in the request's Host: header to
	# match this virtual host. For the default virtual host (this file) this
	# value is not decisive as it is used as a last resort host regardless.
	# However, you must set it for any further virtual host explicitly.
	ServerName photos.marcevanstein.com
	ServerAlias www.photos.marcevanstein.com
	ServerAdmin [redacted]
 	DocumentRoot /var/www/html/piwigo

	# Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
	# error, crit, alert, emerg.
	# It is also possible to configure the loglevel for particular
	# modules, e.g.
	#LogLevel info ssl:warn

	ErrorLog ${APACHE_LOG_DIR}/error.log
	CustomLog ${APACHE_LOG_DIR}/access.log combined

	# For most configuration files from conf-available/, which are
	# enabled or disabled at a global level, it is possible to
	# include a line for only one particular virtual host. For example the
	# following line enables the CGI configuration for this host only
	# after it has been globally disabled with "a2disconf".
	#Include conf-available/serve-cgi-bin.conf

	AliasMatch /.well-known/acme-challenge/(.*)$ /var/lib/letsencrypt/http_challenges/$1
        <directory /var/lib/letsencrypt/http_challenges>
          AllowOverride None
          Require all granted
        </directory>
</VirtualHost>

The AliasMatch part was an experiment to see if I could access something under /.well-known/acme-challenge. I put a test file there (http://photos.marcevanstein.com/.well-known/acme-challenge/test), and it is accessible it seems.

cumulonimbus.marcevanstein.com.conf looks similar, but without the AliasMatch part.

Anyway, I've been at this for several days, and I clearly just don't understand enough about how these things work to be able to figure it out on my own. Thanks in advance for any help you can provide!

REQUESTED DETAILS

My domain is: photos.marcevanstein.com, www.photos.marcevanstein.com ,cumulonimbus.marcevanstein.com, and www.cumulonimbus.marcevanstein.com (none of them are working)

I ran this command: sudo certbot --apache

It produced this output:

Requesting a certificate for cumulonimbus.marcevanstein.com and 3 more domains
Performing the following challenges:
http-01 challenge for cumulonimbus.marcevanstein.com
http-01 challenge for photos.marcevanstein.com
http-01 challenge for www.cumulonimbus.marcevanstein.com
http-01 challenge for www.photos.marcevanstein.com
Waiting for verification...
Challenge failed for domain cumulonimbus.marcevanstein.com
Challenge failed for domain photos.marcevanstein.com
Challenge failed for domain www.cumulonimbus.marcevanstein.com
Challenge failed for domain www.photos.marcevanstein.com
http-01 challenge for cumulonimbus.marcevanstein.com
http-01 challenge for photos.marcevanstein.com
http-01 challenge for www.cumulonimbus.marcevanstein.com
http-01 challenge for www.photos.marcevanstein.com
Cleaning up challenges
Some challenges have failed.

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: cumulonimbus.marcevanstein.com
   Type:   connection
   Detail: Fetching
   http://cumulonimbus.marcevanstein.com/.well-known/acme-challenge/WKbW3iukK000shRb7L_ZrWl3XVIMYqDlI0hnwQN-ZJI:
   Timeout during connect (likely firewall problem)

   Domain: photos.marcevanstein.com
   Type:   connection
   Detail: Fetching
   http://photos.marcevanstein.com/.well-known/acme-challenge/RhBJX6ZG_IfpKMVSGtPnVCZSHo-gSLbXfEoqm9uVVy8:
   Timeout during connect (likely firewall problem)

   Domain: www.cumulonimbus.marcevanstein.com
   Type:   connection
   Detail: Fetching
   http://www.cumulonimbus.marcevanstein.com/.well-known/acme-challenge/kNzFZCKuzcSEiTejPC8SXkDUvxP92UpXvuYkI9H2gsk:
   Timeout during connect (likely firewall problem)

   Domain: www.photos.marcevanstein.com
   Type:   connection
   Detail: Fetching
   http://www.photos.marcevanstein.com/.well-known/acme-challenge/RCWNA6hR0ZGfbl3PtkX405YqovXVSNWp1CjesKSrUaM:
   Timeout during connect (likely firewall problem)

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A/AAAA record(s) for that domain
   contain(s) the right IP address. Additionally, please check that
   your computer has a publicly routable IP address and that no
   firewalls are preventing the server from communicating with the
   client. If you're using the webroot plugin, you should also verify
   that you are serving files from the webroot path you provided.

My web server is (include version): Apache, running on a home server

The operating system my web server runs on is (include version): Ubuntu 20.04.2 LTS (GNU/Linux 5.4.0-73-generic x86_64)

My hosting provider, if applicable, is: Home server, although the DNS is managed through asmallorange via cpanel.

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): for setting up the DNS to point to the server, yes, but otherwise no

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

2 Likes
2

I concur with Let's Encrypt's servers: I can't get to your sites, it just hangs there waiting for a response that doesn't come. You need to figure out what firewall is preventing anybody from getting to your site and fix it.

$ curl -v http://cumulonimbus.marcevanstein.com/.well-known/acme-challenge/test
*   Trying 72.194.9.6...
* TCP_NODELAY set

And that's it, it just sits there.

2 Likes
3

That looks like a Cox Internet IP address, so if you're on a residential connection they're blocking port 80.

4 Likes
4

Hi @petercooperjr, thanks so much for your help! Yes, this must be exactly what was happening. The reason I thought the site worked is that it works from home, but I guess that's just within the local network. If I try to connect via by phone cell network, it doesn't work.

What confuses me, though, is that I was able to get this to work a couple months ago. I got a certificate originally, and it was only when trying to renew that certificate that I ran into this issue. (the reason it doesn't look like a renewal is that I disabled the old certificate by renaming /etc/letsencrypt to /etc/letsencrypt-OLD as one of my many attempts to solve the problem).

Is there any way forward?

4 Likes
5

It's possible that Cox only intermittently enforces its blocks, or has changed it policy to add it as a block whereas it hadn't before?

If you want users to be able to get to your site over http: (even if you then immediately redirect it to https:), then you need to either convince Cox to not block the port for you (don't know if they might do it if you ask nicely, or if they'd want you to be on a business-type Internet plan), or host somewhere else.

If you're okay with users only being able to get to your site when they type https: (and can trust that Cox won't end up blocking port 443 as well eventually), then you need to use a different Challenge Type than the HTTP-01 that you're trying now. TLS-ALPN-01 works over port 443, but Certbot doesn't support it so you'd need to try a different ACME Client which does. Or, you can use DNS-01, which would require certbot to be able to automatically update TXT records in your DNS. This can range from being really easy to nearly impossible, depending on if your DNS provider has an API and if a plugin for it has been written for certbot. Or, if your DNS provider doesn't have an API, then you can have the _acme-challenge. record delegated to some other service, like acme-dns, which does integrate well with certbot.

7 Likes
7

Hi @petercooperjr, thanks so much for your help. Following your advice, I managed to get it working using TLS-ALPN-01, with dehydrated as the ACME Client (roughly following this post). Of course, it only works over https, but that's good enough for my simple personal use case. :slight_smile:

I can't say I trust Cox not to block 443 in the future, but it works for now!

Anyway, can't thank you enough for your help. I was just going nuts over this, and wasn't getting anywhere on my own!

5 Likes
8

Hi, @MarcTheSpark, welcome to the community!

Thanks for the feedback confirmation. Knowing that what's been suggested actually fixed the problem will help future readers who are also Cox users who are searching the Help forum for answers. We really appreciate that.

1 Like
9

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