Timeout during connect (likely firewall problem)

My domain is:

not looking to disclosure so let's call it domain-xyz.com

I ran this command:

certbot --apache

It produced this output:

# sudo certbot --apache
Saving debug log to /var/log/letsencrypt/letsencrypt.log

Which names would you like to activate HTTPS for?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: domain-xyz.com
2: www.domain-xyz.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel): 
Requesting a certificate for domain-xyz.com and www.domain-xyz.com

Certbot failed to authenticate some domains (authenticator: apache). The Certificate Authority reported these problems:
  Domain: domain-xyz.com
  Type:   connection
  Detail: 100.200.300.400: Fetching http://domain-xyz.com/.well-known/acme-challenge/dKUUKpTa0HO0jc8hybW8hpqc9-2JQ3tCXq8eFlE7LDo: Timeout during connect (likely firewall problem)

  Domain: www.domain-xyz.com
  Type:   connection
  Detail: 100.200.300.400: Fetching http://www.domain-xyz.com/.well-known/acme-challenge/XSvHzPbW8NScP7VUqQQMGRfiX39qY9GCAsg5z-eEV9s: Timeout during connect (likely firewall problem)

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

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

Server version: Apache/2.4.51 (AlmaLinux)

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

# cat /etc/os-release 
NAME="AlmaLinux"
VERSION="9.0 (Emerald Puma)"
ID="almalinux"
ID_LIKE="rhel centos fedora"
VERSION_ID="9.0"

My hosting provider, if applicable, is:

owned corporate datacenter

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 --version
certbot 1.29.0

=== Additional Info ===

VirtualHost configuration:

<VirtualHost *:80>
# ServerName domain-xyz.com
  ServerAlias domain-xyz.com www.domain-xyz.com
  DocumentRoot /var/www/sites/domain-xyz/public_html
# ServerName www.domain-xyz.com domain-xyz.com

  <Directory '/var/www/sites/domain-xyz/public_html'>
    Options -Indexes -MultiViews +SymLinksIfOwnerMatch
    AllowOverride All
    Require all granted
    
    DirectoryIndex index.php
  </Directory>

# # Other directives here
</VirtualHost>

And the .htaccess file:

# redirect domains to server directories
RewriteEngine On
#RewriteCond %{REQUEST_URI} !/\.well\-known/?.*
RewriteCond %{REQUEST_URI} !^/.well-known/acme-challenge [NC]
RewriteCond %{REQUEST_URI} !^/well-known/acme-challenge [NC]

RewriteCond %{HTTP_HOST} ^(www\.)?domain-xyz\.com$ [NC]
RewriteCond %{REQUEST_FILENAME} !/v1/
RewriteRule ^(.*)$ /2022/$1 [L]

If I curl from outside:

~ % curl -L http://www.domain-xyz.com/.well-known/acme-challenge/XSvHzPbW8NScP7VUqQQMGRfiX39qY9GCAsg5z-eEV9s
*   Trying 100.200.300.400:80...
* Connected to www.domain-xyz.com (100.200.300.400) port 80 (#0)
> GET /.well-known/acme-challenge/XSvHzPbW8NScP7VUqQQMGRfiX39qY9GCAsg5z-eEV9s HTTP/1.1
> Host: www.domain-xyz.com
> User-Agent: curl/7.79.1
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 404 Not Found
< Date: Wed, 31 Aug 2022 13:52:09 GMT
< Server: Apache/2.4.51 (AlmaLinux) OpenSSL/3.0.1 mod_fcgid/2.3.9
< Content-Length: 196
< Content-Type: text/html; charset=iso-8859-1
< 
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL was not found on this server.</p>
</body></html>
* Connection #0 to host www.domain-xyz.com left intact

however, if I

# touch .well-known/acme-challenge/XSvHzPbW8NScP7VUqQQMGRfiX39qY9GCAsg5z-eEV9s

and test again:

 ~ % curl -L http://www.domain-xyz.com/.well-known/acme-challenge/XSvHzPbW8NScP7VUqQQMGRfiX39qY9GCAsg5z-eEV9s
*   Trying 100.200.300.400:80...
* Connected to www.domain-xyz.com (100.200.300.400) port 80 (#0)
> GET /.well-known/acme-challenge/XSvHzPbW8NScP7VUqQQMGRfiX39qY9GCAsg5z-eEV9s HTTP/1.1
> Host: www.domain-xyz.com
> User-Agent: curl/7.79.1
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Date: Wed, 31 Aug 2022 14:08:46 GMT
< Server: Apache/2.4.51 (AlmaLinux) OpenSSL/3.0.1 mod_fcgid/2.3.9
< Last-Modified: Wed, 31 Aug 2022 14:08:40 GMT
< ETag: "0-5e78a08aef41e"
< Accept-Ranges: bytes
< Content-Length: 0
< Content-Type: text/plain; charset=UTF-8
< 
* Connection #0 to host www.domain-xyz.com left intact

I do have SELinux enabled, but,
I'm used to auditing and applying policies to selinux, so I've done that. Nothing comes across regarding any events related. I've even disabled dontaudit policy with semodule -DB and went bananas looking for a hit that wouldn't show.
Finally I've set selinux to permissive, but fails anyway. So I've disregarded it being the issue.

What it seems to me is that it simply isn't creating the secret for validation. There's no timeout problem, and I'm stuck.

Hello @maverickws, welcome to the Let's Encrypt community. :slightly_smiling_face:

is difficult for us to debug and help you with.

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

Thank you for assisting us in helping YOU!

3 Likes

This error is a "Timeout". Meaning the Let's Encrypt server could not reach your domain.

Your examples using curl showed a 404 and 200 response. Both of those were successful connects just with different reply. Neither is a timeout. Are you sure you were testing from outside your network?

The Let's Debug test site is often helpful to debug

Without further details there is not much to say. A timeout is most often a firewall issue

3 Likes

Dear Bruce, thank you for your quick response.
Aside from the domain, I have provided answer to every single point solicited.
I am getting an error from a token that isn't created. I kindly invite you to read my post, which is very thorough in provided information.

2 Likes

What userid and group own the file(s) and what permissions does the file(s) have?
What userid is trying to access the file(s)?

Also please see @MikeMcQ's response Timeout during connect (likely firewall problem) - #3 by MikeMcQ as well.

1 Like

The apache plug-in creates a temporary location for challenge files. You can review the certbot log for these details. But, the error is a timeout - not a 404 Not Found

2 Likes

Why I ask is sometimes root's umask(1p) - Linux manual page is set to something that won't allow others to access the file(s).

1 Like

I figured that could be the case but wasn't quite sure.

Ok it fails here too.
You asked about if I'm from outside the network, so the server has a public ip directly to its public interface but is behind firewalls. The server IP has been added to the public access list which allows port 80 and 443 to said servers and i can connect to it from outside.

Now, my IP may be whitelisted for some other rule and I'm starting to wonder if that would be the issue, however finding it strange as other servers on the same list are working correctly, +looking at the firewall logs I don't see any hit for port 80 or 443 being blocked. I'm looking for another more external jumpbox where I can test from.

allowlist is a better word choice

1 Like

Or a cell phone with wifi turned off :slight_smile:

3 Likes

First things first: Happy Birthday!

Please call it something else, that is a (potential) real domain name.
Like: example.com

I like the IPv4+ range:

Once you have allowed the Internet to reach your server [at least for HTTP], you can then use HTTP-01 authentication.
If it still fails, then you might want to verify Apache hasn't allowed any name:port overlaps, with:
apachectl -t -D DUMP_VHOSTS

1 Like

Yup :slight_smile: thought the phone it was, but when i connect to it as hotspot it automatically sends me via cell network no need to disable wifi.
Anyway, indeed it's timing out. Going to check on that. Cheers!

4 Likes

Are invalid values for an IPv4 Address.

1 Like

No way, are they really?

Check here: IPv4 - Wikipedia(IPv4,the%20ARPANET%20in%20January%201983.

Max value is 255 for an IPv4 address field.

yeah it's rfc1918. you kind of missed the irony. obviously those octets aren't correct, it was an obfuscation. come on man, really.

edit actually 1918 is private allocation. i believe the correct one is 791.

2 Likes

Someone's sarcasm meter is borked - LOL

[a clearly bad attempt at one]

I did find it cool :slight_smile:
But we digress, now back to the [firewall] problem!

2 Likes

I would choose 666.666.666.666 devil.tld for the DNS A record. :rofl:

1 Like

I wasn't even thinking about caring how obvious it looked. Actually was thinking the more obvious it was not correct, more obvious the obfuscation would be.

Taking 5 before diving in that firewall, drinking fluids and all. :joy:

3 Likes

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