Challenge failed

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: shammas.firmsoft.tech

I ran this command: sudo certbot certonly --nginx

It produced this output:
Certbot failed to authenticate some domains (authenticator: nginx). The Certificate Authority reported these problems:
Domain: shammas.firmsoft.tech
Type: connection
Detail: 77.69.171.176: Fetching http://shammas.firmsoft.tech/.well-known/acme-challenge/36tUZKzX9wyt8S9SIfsax8oYrrVl0kncM1Q68Fg3bmg: 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.
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/1.18.0 (Ubuntu)

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

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 2.6.0

As far as I can tell ports 80 and 43 are open:

sudo ufw status

Status: active
To Action From


443/tcp ALLOW Anywhere
80 ALLOW Anywhere
443 ALLOW Anywhere
22 ALLOW Anywhere
80/tcp ALLOW Anywhere
443/tcp (v6) ALLOW Anywhere (v6)
80 (v6) ALLOW Anywhere (v6)
443 (v6) ALLOW Anywhere (v6)
22 (v6) ALLOW Anywhere (v6)
80/tcp (v6) ALLOW Anywhere (v6)

I also tried sudo ufw disable. That did not help.

Letʼs Debug canʼt reach your website as well as myself. Did you forward the ports (80, 443) from your router to your server?

5 Likes

Yes, my router has a port forwarding to this server--I am forwarding all ports in the range 12 to 20000 !!
Accessing http://shammas.firmsoft.tech using my cell phone when I am not on wifi works fine for me, so port forwarding must be working.
Please note that I am geographically located in Bahrain (a country in the Middle East). Could it be just an issue of timing out? The site is reachable for me because I am close by but not for you because I assume you are physically far away? Does that make sense? I am on at a decent internet speed however (more than 100mbps for both upload and download). Is there away to increase the timeout period for certbot to test this hypothesis?

Your site is not accessible to the Internet. Maybe the firewall blocking it is only allowing connections from within your country, but it needs to be globally accessible in order for Let's Encrypt to be able to validate that you own that name.

6 Likes

That is not a bad hypothesis. But signals usually travel all the way around The Earth for no longer than a second[1]. Connections to your server timeout after more than a minute.


  1. A traveler, moving at the speed of light, would circum-navigate the equator approximately 7.5 times in one second.

    How "Fast" is the Speed of Light?

    Weʼll also ignore the fact that the speed of signals in cables is not quite on par with the speed of light in a vacuum :slight_smile: ↩︎

5 Likes

Thank you guys for your kind replies but blocking at the country level does not apply in Bahrain. I just tried VPN to a server in the US so that I have a US IP address on my cell phone. Trying multiple times under this setting, the site was reachable at the rate of like once every 3 to 5 trials. It takes time to successfully connect, but times out frequently. So it is the slow connection as far as I can see it. Now my question is whether there is a way to extend the timeout period of certbot---just making it a bit more patient.

1 Like

Itʼs not the Certbot that times out, thatʼs Letʼs Encryptʼs validation servers that are located in different parts of the world. But in this case even the primary — US based server — cannot reach you.

FWIW I can successfully ping your server, but thereʼs no answer on either 80 or 443 ports.

6 Likes

I also think you have a fundamental problem with ports 80 and 443. I even tried a testing tool with a server in Manama and it could not see you either.

No, there is no way to tell the Let's Encrypt servers to increase their timeout values.

I think you need to find out why Let's Debug and Let's Encrypt can't see you using HTTP as that points to a general problem of anyone being able to connect.

But, just to get a cert you could use a DNS Challenge instead. I don't see support for your DNS Provider (Wild West?) so you would do this manually and repeat it every 60 days or so to renew your cert.

Or, you could try another (free) ACME CA. I think that will fail too but maybe that will convince you that you have a problem and that it is not with Let's Encrypt.

5 Likes

Once the access problem has been fixed, you will need to correct this problem before you can obtain a cert using HTTP authentication:

curl -Ii shammas.firmsoft.tech/.well-known/acem-challenge/Test_File-12345
HTTP/1.1 200 OK
Server: nginx
Date: Wed, 28 Jun 2023 14:14:12 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 120122
Connection: keep-alive
Vary: Accept-Encoding
X-Page-Name: 404
X-From-Cache: True
Set-Cookie: sid=Guest; Expires=Sat, 01 Jul 2023 07:14:12 GMT; HttpOnly; Path=/; SameSite=Lax
Set-Cookie: system_user=no; Path=/; SameSite=Lax
Set-Cookie: full_name=Guest; Path=/; SameSite=Lax
Set-Cookie: user_id=Guest; Path=/; SameSite=Lax
Set-Cookie: user_image=; Path=/; SameSite=Lax
X-Frame-Options: SAMEORIGIN
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Referrer-Policy: same-origin, strict-origin-when-cross-origin

Your site returns "200" [and 120122 bytes] when that file should not exist.

3 Likes

What's even weirder...
On the second request, the site returns "404".

curl -Ii shammas.firmsoft.tech/.well-known/acme-challenge/Test_File-1234567
HTTP/1.1 200 OK
Server: nginx
Date: Wed, 28 Jun 2023 14:32:28 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 120122
Connection: keep-alive
Vary: Accept-Encoding
X-Page-Name: 404
X-From-Cache: True
Set-Cookie: sid=Guest; Expires=Sat, 01 Jul 2023 07:32:28 GMT; HttpOnly; Path=/; SameSite=Lax
Set-Cookie: system_user=no; Path=/; SameSite=Lax
Set-Cookie: full_name=Guest; Path=/; SameSite=Lax
Set-Cookie: user_id=Guest; Path=/; SameSite=Lax
Set-Cookie: user_image=; Path=/; SameSite=Lax
X-Frame-Options: SAMEORIGIN
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Referrer-Policy: same-origin, strict-origin-when-cross-origin

curl -Ii shammas.firmsoft.tech/.well-known/acme-challenge/Test_File-1234567
HTTP/1.1 404 NOT FOUND
Server: nginx
Date: Wed, 28 Jun 2023 14:32:29 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 120122
Connection: keep-alive
Vary: Accept-Encoding
X-Page-Name: 404
X-From-Cache: True
Set-Cookie: sid=Guest; Expires=Sat, 01 Jul 2023 07:32:29 GMT; HttpOnly; Path=/; SameSite=Lax
Set-Cookie: system_user=no; Path=/; SameSite=Lax
Set-Cookie: full_name=Guest; Path=/; SameSite=Lax
Set-Cookie: user_id=Guest; Path=/; SameSite=Lax
Set-Cookie: user_image=; Path=/; SameSite=Lax

But still returns 120122 bytes for both.

3 Likes

And, my own test server times out after 2 minutes. Let's Debug and Let's Encrypt staging can't see it either. So far, you are the only one even getting a response :slight_smile:

curl -Ii shammas.firmsoft.tech/.well-known/acme-challenge/Test_File-1234567
curl: (28) Failed to connect to shammas.firmsoft.tech port 80 after 129373 ms: Connection timed out

Many of these failing tests come from AWS servers. Could there be a firewall blocking all of AWS?

@Nekit You couldn't connect either. Was that from AWS?

4 Likes

Nah. I tried from home and work connections, both in Russia.

4 Likes

I just tried from AWS [Ohio] and it was unable to connect [just timed out].

2 Likes


Lets visualize it! with a blurry image, sorry

3 Likes

I can ping it too but tcp fails.

@Rip Is your traceroute test using TCP?

4 Likes

using defaults fails:

traceroute shammas.firmsoft.tech
traceroute to shammas.firmsoft.tech (77.69.171.176), 30 hops max, 60 byte packets
 1  100.64.80.123 (100.64.80.123)  3.162 ms ec2-52-15-0-187.us-east-2.compute.amazonaws.com (52.15.0.187)  3.419 ms ec2-52-15-0-169.us-east-2.compute.amazonaws.com (52.15.0.169)  3.100 ms
 2  240.1.244.33 (240.1.244.33)  3.080 ms 240.1.244.32 (240.1.244.32)  0.289 ms  0.265 ms
 3  * 242.5.53.17 (242.5.53.17)  0.795 ms 100.66.13.74 (100.66.13.74)  1.219 ms
 4  240.0.236.15 (240.0.236.15)  10.750 ms 100.66.15.234 (100.66.15.234)  17.459 ms 100.66.15.228 (100.66.15.228)  17.571 ms
 5  241.0.12.205 (241.0.12.205)  0.181 ms 242.2.212.195 (242.2.212.195)  10.797 ms 241.0.12.204 (241.0.12.204)  0.188 ms
 6  100.100.4.28 (100.100.4.28)  10.828 ms 100.100.4.22 (100.100.4.22)  10.679 ms 100.100.4.26 (100.100.4.26)  10.699 ms
 7  eqix-dc2.etisalat.com (206.126.237.12)  16.452 ms  16.444 ms 240.0.236.14 (240.0.236.14)  10.883 ms
 8  242.2.212.197 (242.2.212.197)  11.380 ms * 242.2.213.69 (242.2.213.69)  11.062 ms
 9  * 100.100.4.28 (100.100.4.28)  10.930 ms 100.100.4.20 (100.100.4.20)  10.682 ms
10  * * eqix-dc2.etisalat.com (206.126.237.12)  16.461 ms
11  195.229.3.202 (195.229.3.202)  200.819 ms 88.201.100.22 (88.201.100.22)  197.924 ms 195.229.0.122 (195.229.0.122)  198.451 ms
12  * 195.229.31.243 (195.229.31.243)  202.532 ms *
13  195.229.29.178 (195.229.29.178)  213.563 ms 195.229.29.146 (195.229.29.146)  214.366 ms dynamic.ip.77.69.128.1.batelco.com.bh (77.69.128.1)  195.854 ms
14  * * 88.201.100.22 (88.201.100.22)  192.333 ms
15  * * *
16  dynamic.ip.77.69.128.1.batelco.com.bh (77.69.128.1)  200.098 ms *  196.406 ms
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
2 Likes

Using: traceroute -T -p 80 shammas.firmsoft.tech
We can see that the blocks are very close to the endpoint.

Working example:

10  be2331.ccr31.bio02.atlas.cogentco.com (154.54.85.242)  109.282 ms  109.212 ms  108.624 ms
11  be3078.ccr32.mrs02.atlas.cogentco.com (154.54.56.126)  122.192 ms  121.609 ms  119.847 ms
12  be2066.agr21.mrs02.atlas.cogentco.com (154.54.38.202)  120.595 ms be2753.agr21.mrs02.atlas.cogentco.com (154.54.39.14)  120.393 ms  121.857 ms
13  149.11.241.2 (149.11.241.2)  216.497 ms  217.217 ms  217.100 ms
14  * * *
15  dynamic.ip.77.69.128.1.batelco.com.bh (77.69.128.1)  214.892 ms  213.395 ms  213.925 ms
16  dynamic.ip.77.69.171.176.batelco.com.bh (77.69.171.176)  225.630 ms  225.219 ms  224.030 ms
17  dynamic.ip.77.69.171.176.batelco.com.bh (77.69.171.176)  225.992 ms  219.300 ms  212.528 ms

Failing example:

10  195.229.29.178 (195.229.29.178)  208.022 ms  208.052 ms 195.229.29.146 (195.229.29.146)  214.304 ms
11  * 88.201.100.22 (88.201.100.22)  198.329 ms 195.229.3.202 (195.229.3.202)  201.075 ms
12  195.229.31.243 (195.229.31.243)  211.013 ms * *
13  195.229.29.178 (195.229.29.178)  216.067 ms dynamic.ip.77.69.128.1.batelco.com.bh (77.69.128.1)  196.861 ms  193.104 ms
14  88.201.100.22 (88.201.100.22)  195.520 ms  190.950 ms *
15  * * *
16  dynamic.ip.77.69.128.1.batelco.com.bh (77.69.128.1)  199.311 ms  196.076 ms  197.138 ms
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
3 Likes

Using ICMP

rip:T430 ~ >>  traceroute -I --resolve-hostnames  77.69.171.176
traceroute to 77.69.171.176 (77.69.171.176), 64 hops max
1   192.168.1.1 (haus.localdomain)  2.199ms  2.187ms  2.145ms
2   192.173.154.113 (192.173.154.113)  40.243ms  37.980ms  41.818ms
3   192.173.152.85 (cr1.pnrcon.net)  19.946ms  20.748ms  20.218ms
4   192.173.152.65 (br1.pnrcon.net)  21.574ms  20.320ms  20.465ms
5   198.29.47.93 (198-29-47-93.win-networks.com)  24.566ms  23.156ms  25.606ms
6   198.29.45.6 (198-29-45-6.win-networks.com)  23.808ms  23.930ms  23.942ms
7   128.241.10.168 (ae-41.a02.snjsca04.us.bb.gin.ntt.net)  36.201ms  36.260ms  36.423ms
8   129.250.3.102 (ae-9.r25.snjsca04.us.bb.gin.ntt.net)  36.592ms  36.225ms  36.161ms
9   129.250.5.77 (ae-21.r30.tokyjp05.jp.bb.gin.ntt.net)  142.514ms  142.842ms  142.450ms
10   129.250.5.22 (ae-0.r31.tokyjp05.jp.bb.gin.ntt.net)  139.388ms  139.947ms  141.098ms
11   *  *  *
12   129.250.2.240 (ae-1.a01.sngpsi07.sg.bb.gin.ntt.net)  217.081ms  213.362ms  213.060ms
13   116.51.17.126 (xe-0-0-14-2.a01.sngpsi07.sg.ce.gin.ntt.net)  215.260ms  212.698ms  212.924ms
14   89.211.2.61 (89.211.2.61)  294.615ms  294.474ms  294.697ms
15   89.211.0.49 (if-3-0-2.csb-core1.qatar.net.qa)  295.948ms  296.058ms  296.219ms
16   89.211.3.70 (et-20-wac-gw4.qatar.net.qa)  297.200ms  326.545ms  297.436ms
17   82.148.106.102 (82.148.106.102)  298.575ms  298.118ms  298.399ms
18   88.201.100.25 (88.201.100.25)  296.485ms  296.177ms  296.427ms
19   *  *  *
20   77.69.128.1 (dynamic.ip.77.69.128.1.batelco.com.bh)  301.087ms  301.010ms  301.274ms
21   77.69.171.176 (dynamic.ip.77.69.171.176.batelco.com.bh)  302.810ms  302.884ms  302.592ms
2 Likes

I am sure the gsuite tool uses UDP.

2 Likes

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