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. 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: repositorio.leon.uia.mx

I ran this command: certbot-auto --dry-run renew

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log

Processing /etc/letsencrypt/renewal/repositorio.leon.uia.mx.conf

Cert is due for renewal, auto-renewing…
Plugins selected: Authenticator apache, Installer apache
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for repositorio.leon.uia.mx
Waiting for verification…
Challenge failed for domain repositorio.leon.uia.mx
http-01 challenge for repositorio.leon.uia.mx
Cleaning up challenges
Attempting to renew cert (repositorio.leon.uia.mx) from /etc/letsencrypt/renewal/repositorio.leon.uia.mx.conf produced an unexpected error: Some challenges have failed… Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/repositorio.leon.uia.mx/fullchain.pem (failure)

** DRY RUN: simulating ‘certbot renew’ close to cert expiry
** (The test certificates below have not been saved.)

All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/repositorio.leon.uia.mx/fullchain.pem (failure)
** DRY RUN: simulating ‘certbot renew’ close to cert expiry
** (The test certificates above have not been saved.)

1 renew failure(s), 0 parse failure(s)


  • The following errors were reported by the server:

    Domain: repositorio.leon.uia.mx
    Type: connection
    Detail: Fetching
    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): apache2 (2.4.25-3+deb9u7)

The operating system my web server runs on is (include version): devuan ascii (equiv. debian stretch)

My hosting provider, if applicable, is: not applicable

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

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

I did some tests from other networks, and they all can reach this server, at both port 80 and 443.

It seems likely that your server has blocked the Let’s Encrypt validation hosts.

Do you have anything like fail2ban installed?


We don´t have fail2ban installed, the firewall rules for this server are off, and the policy is ACCEPT. There is a firewall covering this server, but I have no access to it, but have been assured that it is not blocking access to ports 80 or 443 -my tests also show this is the case, it does accept traffic and responds on both ports-

Hi @cacho

checking your domain that looks bad ( https://check-your-website.server-daten.de/?q=repositorio.leon.uia.mx ):

Host T IP-Address is auth. ∑ Queries ∑ Timeout
repositorio.leon.uia.mx Refused yes 1 0
www.repositorio.leon.uia.mx Refused yes 1 0
repositorio.leon.uia.mx A Mexico City/Mexico (MX) - Universidad Iberoamericana, A.C. No Hostname found no

But an older check (this morning) was good:

Host T IP-Address is auth. ∑ Queries ∑ Timeout
repositorio.leon.uia.mx A Mexico City/Mexico (MX) - Universidad Iberoamericana, A.C. No Hostname found yes 1 0
AAAA yes
www.repositorio.leon.uia.mx Name Error yes 1 0

/.well-known/acme-challenge/random-filename works. But using Kostenloser Website-Verfügbarkeitstest | Uptrends all is red:

Compare the list of name servers (current check - older check). Looks like a problem.

This is very strange. I put a file there for testing as the certbot client removes the random file when it is done, it shows all green.


The domain has four nameservers, geographically independent, and all of them have the proper data for repositorio.leon.uia.mx now, www.repositorio.leon.uia.mx does not exist, and is not wanted.

This domain has been working with letsencrypt for a couple of years now, and this is the strangest part: Every check you made with uptrends.com is reflected in my logs, but not one access attempt is logged for letsencrypt´s certbot runs.

Is there something that can be done?

1 Like

A potentially confusing factor is that it looks like this site shows 404 Not Found errors as red also, so you could get very visually different results if you test with a file that exists and again with one that doesn't exist.

1 Like

Sorry, that was a false alarm. @schoen has the correct idea. Checked my own domain with the /.well-known/acme-challenge/not-existing-file - it's the same picture, all is red.

Good to know - uptrends must be used with an address with http status 200.

Ok, so the server is responding properly, but it still is not being accesed by letsencrypt to validate the certificates.
What else can I do?

Change that link to


to check, if it isn't a configuration problem well-known vs. well-known/acme-challenge.

Checked that url there is a minor problem - https://check-your-website.server-daten.de/?q=repositorio.leon.uia.mx%2F.well-known%2Fa

Domainname Http-Status redirect Sec. G
http://repositorio.leon.uia.mx/ 302 https://repositorio.leon.uia.mx/ 0.427 A
http://repositorio.leon.uia.mx/.well-known/a 200 0.437 H
DSpace Home 302 http://repositorio.leon.uia.mx/ 2.176 F
https://repositorio.leon.uia.mx/ 200 2.327 B
http://repositorio.leon.uia.mx/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de 404 0.424 A
Not Found
Visible Content: Not Found The requested URL /.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de was not found on this server. Apache/2.4.25 (Debian) Server at repositorio.leon.uia.mx Port 80

It's redirected to /.

But: Try it again (one time): The main problem: Is there again a timeout? If yes, that's fatal. Perhaps a global firewall.

Do you have access to the name server? If yes, use one time dns-validation and --manual, that should always work.

Ok, I changed the files to that directory, they still work. I´ll try dns-validation.

With DNS validation that server was renewed. Now I have several others failing, but they behave a little bit different.
They all have access logs indicating letsencrypt was able to fetch the files, but they all present the same error, timeout, likely because of a firewall. How can this be if the logs have the appropiate records?
This is one of them: - - [08/Aug/2019:06:22:45 -0500] “GET /.well-known/acme-challenge/q4VQYD70qADIdx0Hcxz_yXIll5LjrQ56lyETq6kPVHk HTTP/1.1” 200 308 “-” “Mozilla/5.0 (compatible; Let’s Encrypt validation server; +https://www.letsencrypt.org)” - - [08/Aug/2019:06:22:46 -0500] “GET /.well-known/acme-challenge/q4VQYD70qADIdx0Hcxz_yXIll5LjrQ56lyETq6kPVHk HTTP/1.1” 200 308 “-” “Mozilla/5.0 (compatible; Let’s Encrypt validation server; +https://www.letsencrypt.org)” - - [08/Aug/2019:06:22:46 -0500] “GET /.well-known/acme-challenge/q4VQYD70qADIdx0Hcxz_yXIll5LjrQ56lyETq6kPVHk HTTP/1.1” 200 308 “-” “Mozilla/5.0 (compatible; Let’s Encrypt validation server; +https://www.letsencrypt.org)”

I can´t see any errors there. This is now for server “www.dialogosfeycultura.org”, which is in the same network segment.

Those IP addresses are from the Let’s Encrypt staging environment. Something specific to the staging environment is that it performs validation from multiple servers at the same time (Validating challenges from multiple network vantage points).

There are three remote VAs and two of the three remote VAs must succeed for the validation to succeed.

Right now, I see 4 requests arriving for a single challenge. I’m not sure if the above statement is still true about the required threshold for success, but I think it’s the most likely explanation for your symptoms.

1 Like

You're correct. That's still the required threshold in the staging environment. You might also notice we've also been performing multiple challenge validation requests in the production environment as well but presently it is information gathering only and isn't being used to influence the overall validation result in that env.

Thank you all for your time and suggestions, it was a routing problem, the servers answered from a different network than the one used to reach them for some reason, it is now fixed and working again.

1 Like

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