Applying for new certificates and got "Timeout during connect"

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: sohn.ydns.eu, tywrss.ydns.eu, sohn.ix.tc, tywrss.ix.tc

I ran this command: sudo certbot --apache

It produced this output: Performing the following challenges:
http-01 challenge for sohn.ix.tc
http-01 challenge for sohn.ydns.eu
http-01 challenge for tywrss.ix.tc
http-01 challenge for tywrss.ydns.eu
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. tywrss.ydns.eu (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: 137.25.138.29: Fetching http://tywrss.ydns.eu/.well-known/acme-challenge/NYm0bOtjEGv1Yx2_JVvsrkTZvVp82-uoKJth_wgZlWo: Timeout during connect (likely firewall problem), tywrss.ix.tc (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: 137.25.138.29: Fetching http://tywrss.ix.tc/.well-known/acme-challenge/9NEbRzwTnckgyDHgSl7eqov82Aoqjyw3mZGfy6Nj_8w: Timeout during connect (likely firewall problem), sohn.ix.tc (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: 137.25.138.29: Fetching http://sohn.ix.tc/.well-known/acme-challenge/8tf7Jscf92FV1W3eSOnCKykyQIUFsm08GrtfWy2IrV0: Timeout during connect (likely firewall problem), sohn.ydns.eu (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: 137.25.138.29: Fetching http://sohn.ydns.eu/.well-known/acme-challenge/qMbpftrb6Wa85dYBgk0YP_5V7GHREsA3yU6-S38pXJY: Timeout during connect (likely firewall problem)

IMPORTANT NOTES:

My web server is (include version): apache2 2.4.29-1ubuntu4.22 amd64

The operating system my web server runs on is (include version): Linux Mint 19.3, kernel: 5.4.0-113-generic #127~18.04.1-Ubuntu

My hosting provider, if applicable, is: dynamic DNS on my own server

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): n/a

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

1 Like

Hi @ipsmile, and welcome to the LE community forum :slight_smile:

It seems that since your last renewal inbound HTTP connections are now being blocked.
HTTP authentication requires TCP port 80 to reach your server for HTTP.

Does your ISP now block TCP port 80?

2 Likes

Thanks for your attention. As far as I know, no, my ISP doesn't block inbound port 80 and 443. However, my server crashed yesterday for a while.

1 Like

Just your port 80 is not open, port 443 gets through. Although, your server does not properly handle the https request. See SSL Labs report and:

curl -I -m10 http://sohn.ix.tc
curl: (28) Connection timed out after 10001 milliseconds

curl -I -m10 https://sohn.ix.tc
curl: (35) error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
3 Likes

This "connects":

curl -Ii http://sohn.ix.tc:443/
HTTP/1.1 200 OK
Date: Sat, 04 Jun 2022 15:19:14 GMT
Server: Apache/2.4.29
Last-Modified: Wed, 09 Mar 2022 00:11:06 GMT
ETag: "0-5d9bdef0e8ebf"
Accept-Ranges: bytes
Content-Type: text/html

LOL

3 Likes
curl http://sohn.ix.tc:443/.well-known/acem-challenge/Test_File-1234
<!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>

Seems like the HTTPS server block is missing the "SSLEngine ON".

3 Likes

Thanks for verifying the problems. I have reset these four virtual hosts. From my end, my curl commands can all return the correct web contents.

I don't have firewall set up on my server. At the home gateway, only port 80 and 443 are directed to this server via NAT.

apachectl -t -D DUMP_VHOSTS             
VirtualHost configuration:
*:80                   is a NameVirtualHost
         default server 127.0.0.1 (/etc/apache2/sites-enabled/000-default.conf:1)
         port 80 namevhost 127.0.0.1 (/etc/apache2/sites-enabled/000-default.conf:1)
         port 80 namevhost sohn.ydns.eu (/etc/apache2/sites-enabled/sohn.ydns.eu.conf:1)
                 alias www.sohn.ydns.eu
         port 80 namevhost sohn.ix.tc (/etc/apache2/sites-enabled/sohn.ix.tc.conf:1)
                 alias www.sohn.ix.tc
         port 80 namevhost tywrss.ix.tc (/etc/apache2/sites-enabled/tywrss.ix.tc.conf:1)
                 alias www.tywrss.ix.tc
         port 80 namevhost tywrss.ydns.eu (/etc/apache2/sites-enabled/tywrss.ydns.eu.conf:2)
                 alias www.tywrss.ydns.eu

However, I am still timed out with the sudo certbot --apache command.

Well, I am still not sure what the root cause of the issues here. All of these virtual hosts had their certificates before and renewed without any issues for at least a year until renewal cron job didn't work anymore. Manually, tried to renew the certificates showing similar error messages.

I have deleted the old certificates and trying to apply for new certificates, and there is no improvement.

Hmm. I still see port 443 open to your domain. And it still responds in the same wrong way. Did you restart after changing Apache? When you change port assignments best to restart rather than just reload. This would not cause certbot to timeout as I don't see your http server redirecting to https. Just noting best to restart here.

I do not timeout anymore trying to reach your server with http. So, I do not know why running certbot would still timeout. There might be something unusual in your Apache config files. Can you show us one of them like:

/etc/apache2/sites-enabled/sohn.ix.tc.conf

Are you sure your DNS is still pointing to the right IP? I ask because I see mostly Asian double-byte characters on your sohn domain home page. Yet, your domain names are for TCI and EU. Nothing wrong with that of course. Just makes me wonder especially given the inconsistent port responses too.

UPDATE: I just trying a Let's Debug test and it is warning me about your DNS servers taking very long to respond. And then failed with SERVFAIL. Was your most recent timeout for DNS or for HTTP response?

2 Likes

You've made changes...

Please show the most recent certbot error message.

And review your DNS:

nslookup sohn.ix.tc 8.8.8.8
Name:    sohn.ix.tc
Address: 137.25.138.29

nslookup www.sohn.ix.tc 8.8.8.8
*** dns.google can't find www.sohn.ix.tc: Non-existent domain

All the "www" names fail to resolve.

2 Likes

Wah!!! It went through this time. I got the new certificates. Thanks!!!

Obtaining a new certificate
Performing the following challenges:
http-01 challenge for sohn.ix.tc
http-01 challenge for sohn.ydns.eu
http-01 challenge for tywrss.ix.tc
http-01 challenge for tywrss.ydns.eu
Waiting for verification...
Cleaning up challenges
Created an SSL vhost at /etc/apache2/sites-available/tywrss.ydns.eu-le-ssl.conf
Deploying Certificate to VirtualHost /etc/apache2/sites-available/tywrss.ydns.eu-le-ssl.conf
Enabling available site: /etc/apache2/sites-available/tywrss.ydns.eu-le-ssl.conf
Created an SSL vhost at /etc/apache2/sites-available/sohn.ix.tc-le-ssl.conf
Deploying Certificate to VirtualHost /etc/apache2/sites-available/sohn.ix.tc-le-ssl.conf
Enabling available site: /etc/apache2/sites-available/sohn.ix.tc-le-ssl.conf
Created an SSL vhost at /etc/apache2/sites-available/tywrss.ix.tc-le-ssl.conf
Deploying Certificate to VirtualHost /etc/apache2/sites-available/tywrss.ix.tc-le-ssl.conf
Enabling available site: /etc/apache2/sites-available/tywrss.ix.tc-le-ssl.conf
Created an SSL vhost at /etc/apache2/sites-available/sohn.ydns.eu-le-ssl.conf
Deploying Certificate to VirtualHost /etc/apache2/sites-available/sohn.ydns.eu-le-ssl.conf
Enabling available site: /etc/apache2/sites-available/sohn.ydns.eu-le-ssl.conf

Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.


1: No redirect - Make no further changes to the webserver configuration.
2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
new sites, or if you're confident your site works on HTTPS. You can undo this
change by editing your web server's configuration.


Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Redirecting vhost in /etc/apache2/sites-enabled/tywrss.ydns.eu.conf to ssl vhost in /etc/apache2/sites-available/tywrss.ydns.eu-le-ssl.conf
Redirecting vhost in /etc/apache2/sites-enabled/sohn.ix.tc.conf to ssl vhost in /etc/apache2/sites-available/sohn.ix.tc-le-ssl.conf
Redirecting vhost in /etc/apache2/sites-enabled/tywrss.ix.tc.conf to ssl vhost in /etc/apache2/sites-available/tywrss.ix.tc-le-ssl.conf
Redirecting vhost in /etc/apache2/sites-enabled/sohn.ydns.eu.conf to ssl vhost in /etc/apache2/sites-available/sohn.ydns.eu-le-ssl.conf


Congratulations! You have successfully enabled https://tywrss.ydns.eu,
https://sohn.ix.tc, https://tywrss.ix.tc, and https://sohn.ydns.eu

You should test your configuration at:
https://www.ssllabs.com/ssltest/analyze.html?d=tywrss.ydns.eu

https://www.ssllabs.com/ssltest/analyze.html?d=tywrss.ix.tc
https://www.ssllabs.com/ssltest/analyze.html?d=sohn.ydns.eu


IMPORTANT NOTES:

  • Congratulations! Your certificate and chain have been saved at:
    /etc/letsencrypt/live/tywrss.ydns.eu/fullchain.pem
    Your key file has been saved at:
    /etc/letsencrypt/live/tywrss.ydns.eu/privkey.pem
    Your cert will expire on 2022-09-03. To obtain a new or tweaked
    version of this certificate in the future, simply run certbot again
    with the "certonly" option. To non-interactively renew all of
    your certificates, run "certbot renew"

  • If you like Certbot, please consider supporting our work by:

    Donating to ISRG / Let's Encrypt: Donate - Let's Encrypt
    Donating to EFF: Support EFF's Work on Let's Encrypt | Electronic Frontier Foundation

1 Like

What was the cause of the problems I experienced before? I don't think I have done anything significant to fix the problems on my side.

I can't say.
I still see ports 80 and 443 not answering.

2 Likes