.AuthorizationError: Some challenges have failed. - but access log contains - 2 GETs with 200

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: tmapp.cz

I ran this command: sudo certbot run -v -a webroot -i nginx -w /var/www/common/letsencrypt -d tmapp.cz --no-redirect --agree-tos --email "myEmail@gmail.com"

It produced this output:
Domain: tmapp.cz
Type: connection
Detail: Fetching http://tmapp.cz/.well-known/acme-challenge/bkLcFV46VMDJA6KNxld47NCsuQPcmFGHeuzpsS356FM: 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.
Encountered exception:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/certbot/auth_handler.py", line 91, in handle_authorizations
self._poll_authorizations(authzrs, max_retries, best_effort)
File "/usr/lib/python3/dist-packages/certbot/auth_handler.py", line 180, in _poll_authorizations
raise errors.AuthorizationError('Some challenges have failed.')
certbot.errors.AuthorizationError: Some challenges have failed.

What is strange:
cat /var/www/common/letsencrypt/access_log.log
52.28.236.88 - - [29/Mar/2021:16:58:47 +0000] "GET /.well-known/acme-challenge/bkLcFV46VMDJA6KNxld47NCsuQPcmFGHeuzpsS356FM HTTP/1.1" 200 87 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"
3.128.26.105 - - [29/Mar/2021:16:58:53 +0000] "GET /.well-known/acme-challenge/bkLcFV46VMDJA6KNxld47NCsuQPcmFGHeuzpsS356FM HTTP/1.1" 200 87 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"

Additional Info:

  • I am not able to use IPv6, my Internet provider doesn't support IPv6, so I have configured DNS records only with "A" + IPv4

My web server is (include version): nginx version: nginx/1.18.0 (Ubuntu)

The operating system my web server runs on is (include version):
Distributor ID: Ubuntu
Description: Ubuntu 20.04.2 LTS
Release: 20.04
Codename: focal

My hosting provider, if applicable, is: my own virtual 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): NO

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

I think you should be seeing at least three or four requests in your logs. Let's Encrypt needs to run validation from multiple points of the Internet to confirm that you own the name as seen from everywhere, and just two successes probably isn't enough. Is there some firewall that might be blocking some IPs? (Maybe a country-based filter or the like?)

Yes, I know, I read it, but unfortunately I do not find the reason why I do not see more requests. Unfortunately I cannot find any errors or more information why it failed.

When I check the link everything works, but the certbot returns this error.

There is no firewall, it is my "virtual server" and I disabled the firewall.

If I check my "dns" / domain, I can see that "all servers" reported / find my "public" IPv4:

but not sure if there is not problem with IPv6, because I cannot configure IPv6 (AAAA dns record), I am able to access / change dns records through domain provider but I am not able to configure IPv6, because my internet provider doesn't support IPv6.

Onother think is, that I had working solution 2 or 3 month ago, but I used the different domain provider, then I changed the domain provider and / or probably something was changed in this process and I am not able to setup the process again.

Here is another check, looks that IPv4 should be correct:

Hmm it look strange:
Server: nginx
Date: Mon, 29 Mar 2021 16:58:56 GMT
Content-Type: application/json
Content-Length: 1018
Connection: keep-alive
Boulder-Requester: 117283233
Cache-Control: public, max-age=0, no-cache
Link: https://acme-v02.api.letsencrypt.org/directory;rel="index"
Replay-Nonce: 0004CFeutRQngfCmV8SIzYeMEIMQT-QRNJoyvlcns3xfFXI
X-Frame-Options: DENY
Strict-Transport-Security: max-age=604800

{
"identifier": {
"type": "dns",
"value": "tmapp.cz"
},
"status": "invalid",
"expires": "2021-04-05T16:58:45Z",
"challenges": [
{
"type": "http-01",
"status": "invalid",
"error": {
"type": "urn:ietf:params:acme:error:connection",
"detail": "Fetching http://tmapp.cz/.well-known/acme-challenge/bkLcFV46VMDJA6KNxld47NCsuQPcmFGHeuzpsS356FM: Timeout during connect (likely firewall problem)",
** "status": 400**
},
"url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/11933594379/kdUgDg",
"token": "bkLcFV46VMDJA6KNxld47NCsuQPcmFGHeuzpsS356FM",
"validationRecord": [
{
"url": "http://tmapp.cz/.well-known/acme-challenge/bkLcFV46VMDJA6KNxld47NCsuQPcmFGHeuzpsS356FM",
"hostname": "tmapp.cz",
"port": "80",
"addressesResolved": [
"109.238.218.212"
],
"addressUsed": "109.238.218.212"
}
],
"validated": "2021-03-29T16:58:46Z"
}
]
}
Storing nonce: 0004CFeutRQngfCmV8SIzYeMEIMQT-QRNJoyvlcns3xfFXI
Challenge failed for domain tmapp.cz

and know I can see a lot of "GETs" in my logs but very long after the certbot finished checking.
64.62.250.100 - - [29/Mar/2021:17:09:39 +0000] "GET /.well-known/acme-challenge/bkLcFV46VMDJA6KNxld47NCsuQPcmFGHeuzpsS356FM: HTTP/1.1" 404 134 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15"
17.58.84.29 - - [29/Mar/2021:17:11:46 +0000] "GET /.well-known/acme-challenge/bkLcFV46VMDJA6KNxld47NCsuQPcmFGHeuzpsS356FM: HTTP/1.1" 404 134 "-" "AppleNewsBot"
17.58.82.229 - - [29/Mar/2021:17:13:40 +0000] "GET /.well-known/acme-challenge/bkLcFV46VMDJA6KNxld47NCsuQPcmFGHeuzpsS356FM: HTTP/1.1" 404 134 "-" "AppleNewsBot"
17.58.85.206 - - [29/Mar/2021:17:19:16 +0000] "GET /.well-known/acme-challenge/bkLcFV46VMDJA6KNxld47NCsuQPcmFGHeuzpsS356FM: HTTP/1.1" 404 134 "-" "AppleNewsBot"
64.62.250.100 - - [29/Mar/2021:17:09:39 +0000] "GET /.well-known/acme-challenge/bkLcFV46VMDJA6KNxld47NCsuQPcmFGHeuzpsS356FM: HTTP/1.1" 404 134 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15"
17.58.84.29 - - [29/Mar/2021:17:11:46 +0000] "GET /.well-known/acme-challenge/bkLcFV46VMDJA6KNxld47NCsuQPcmFGHeuzpsS356FM: HTTP/1.1" 404 134 "-" "AppleNewsBot"
17.58.82.229 - - [29/Mar/2021:17:13:40 +0000] "GET /.well-known/acme-challenge/bkLcFV46VMDJA6KNxld47NCsuQPcmFGHeuzpsS356FM: HTTP/1.1" 404 134 "-" "AppleNewsBot"
17.58.85.206 - - [29/Mar/2021:17:19:16 +0000] "GET /.well-known/acme-challenge/bkLcFV46VMDJA6KNxld47NCsuQPcmFGHeuzpsS356FM: HTTP/1.1" 404 134 "-" "AppleNewsBot"
17.121.204.208 - - [29/Mar/2021:17:20:15 +0000] "GET /.well-known/acme-challenge/bkLcFV46VMDJA6KNxld47NCsuQPcmFGHeuzpsS356FM: HTTP/1.1" 404 134 "-" "AppleNewsBot"
17.58.85.206 - - [29/Mar/2021:17:38:21 +0000] "GET /.well-known/acme-challenge/bkLcFV46VMDJA6KNxld47NCsuQPcmFGHeuzpsS356FM: HTTP/1.1" 404 134 "-" "AppleNewsBot"
17.58.82.229 - - [29/Mar/2021:17:40:46 +0000] "GET /.well-known/acme-challenge/bkLcFV46VMDJA6KNxld47NCsuQPcmFGHeuzpsS356FM: HTTP/1.1" 404 134 "-" "AppleNewsBot"
17.58.84.29 - - [29/Mar/2021:17:44:23 +0000] "GET /.well-known/acme-challenge/bkLcFV46VMDJA6KNxld47NCsuQPcmFGHeuzpsS356FM: HTTP/1.1" 404 134 "-" "AppleNewsBot"
17.121.204.208 - - [29/Mar/2021:17:49:52 +0000] "GET /.well-known/acme-challenge/bkLcFV46VMDJA6KNxld47NCsuQPcmFGHeuzpsS356FM: HTTP/1.1" 404 134 "-" "AppleNewsBot"
17.58.85.206 - - [29/Mar/2021:17:55:38 +0000] "GET /.well-known/acme-challenge/bkLcFV46VMDJA6KNxld47NCsuQPcmFGHeuzpsS356FM: HTTP/1.1" 404 134 "-" "AppleNewsBot"
"GET /.well-known/acme-challenge/bkLcFV46VMDJA6KNxld47NCsuQPcmFGHeuzpsS356FM: HTTP/1.1" 404 134 "-" "AppleNewsBot"
17.58.85.206 - - [29/Mar/2021:17:38:21 +0000] "GET /.well-known/acme-challenge/bkLcFV46VMDJA6KNxld47NCsuQPcmFGHeuzpsS356FM: HTTP/1.1" 404 134 "-" "AppleNewsBot"
17.58.82.229 - - [29/Mar/2021:17:40:46 +0000] "GET /.well-known/acme-challenge/bkLcFV46VMDJA6KNxld47NCsuQPcmFGHeuzpsS356FM: HTTP/1.1" 404 134 "-" "AppleNewsBot"
17.58.84.29 - - [29/Mar/2021:17:44:23 +0000] "GET /.well-known/acme-challenge/bkLcFV46VMDJA6KNxld47NCsuQPcmFGHeuzpsS356FM: HTTP/1.1" 404 134 "-" "AppleNewsBot"
17.121.204.208 - - [29/Mar/2021:17:49:52 +0000] "GET /.well-known/acme-challenge/bkLcFV46VMDJA6KNxld47NCsuQPcmFGHeuzpsS356FM: HTTP/1.1" 404 134 "-" "AppleNewsBot"
17.58.85.206 - - [29/Mar/2021:17:55:38 +0000] "GET /.well-known/acme-challenge/bkLcFV46VMDJA6KNxld47NCsuQPcmFGHeuzpsS356FM: HTTP/1.1" 404 134 "-" "AppleNewsBot"

Hi @tmarsak

the result shows a timeout.

http://tmapp.cz/ answers, http://tmapp.cz/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de has a timeout.

Looks like you have a blocking instance.

And your log doesn't show the Check-your-Website - referer.

there must be the "timeout" right now, because the "file" in:
.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
is generated only temporary by certbot and when the process failed, after few minutes the files are automatically deleted.

I am using following command:
sudo certbot run -v -a webroot -i nginx -w /var/www/common/letsencrypt -d tmapp.cz --no-redirect --agree-tos --email ".....@gmail.com"

and this command generated "temporary acme-cahlenge file" and when the process "failed" everything was deleted. But I can run the same command with additional parameter "--debug-challenges" => so it keeps the files there and I can check the urls / and responses, but when I "un-pause / enter for contineu" the process failes.

Or what I am doing wrong ?? :frowning:

No, that's wrong. There must be a http status 404 - Not Found, not a timeout.

But checking with my browser there is the expected http status 404 - Not Found.

So you have something that blocks - may be ip addresses from data centers (like the ip of "check-your-website").

Timeout - 10 seconds no answer.

Firewall, failban, wrong htaccess etc.

Aaaa ok, understand, could you pls check this link:
http://tmapp.cz/.well-known/acme-challenge/Zh17t7x65UY6y4duaG7fTQ4uYi7PQMlTNCatdDp2Ysk

I executed the certbot, and now it waits for confirmation, so file / link should be accessible and should respons.

I am able to access the file from my mobile phone, it is different internet provider :frowning: so thats why I expected that there cannot be problem :frowning:

Do not know, how I can check that "my internet provider" blocks some IPs :frowning: do not know if it is possible to check somehow from my side, or I can only contact him and ask.

Now the non-www version + http works, see https://check-your-website.server-daten.de/?q=tmapp.cz%2F.well-known%2Facme-challenge%2FZh17t7x65UY6y4duaG7fTQ4uYi7PQMlTNCatdDp2Ysk

There is the (now correct) http status 200, because the file exists.

yes, true, but when I "un-pause" the process, the output is the same: ERROR :frowning:

Challenge failed for domain tmapp.cz
http-01 challenge for tmapp.cz
Reporting to user: The following errors were reported by the server:

Domain: tmapp.cz
Type: connection
Detail: Fetching http://tmapp.cz/.well-known/acme-challenge/Zh17t7x65UY6y4duaG7fTQ4uYi7PQMlTNCatdDp2Ysk: 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.
Encountered exception:

So most probably my "internet provider" blocks IPs of the servers which should validate the link?? Can I check it somehow ??

It certainly looks like your Internet provider is blocking some of the requests. Your best bet is to either contact them to see if they can fix that, or to try switching to the DNS-01 challenge if your DNS provider provides an API.

yes, it is my last possible chance :frowning: I do not want to create / prolong cert with manual changes through web app so I had a parallel discussion with my DNS provider about some API, looks that they support that, but I have to move the domains somewhere else (different part of the company or something like that).

But it will have one additional positive impact, I will be able to create cert with wildcard for third level domains.

So thank you very much for the support !! really appreciate that you confirmed me that I didn't make any mistake on my side. Well I spent three days with the analysis and checks, because I had everything in the scripts and I only redeploy the scripts (after three months) and I found that something is wrong :smiley: I couldn't believe that something can be wrong, because you cannot make a mistake if everything is in scripts and automatically deployed :smiley:

There's a lot of options for DNS challenges, check out acme-dns if you can't use your provider's DNS API directly as it sets up a separate DNS server just for automating handling authentications, and you just delegate your requests to it. I really prefer DNS challenges, though it seems most people find the HTTP ones easier.

And do bug your Internet provider. Even if what's blocking things is something that's designed to protect you in some way rather than a misconfiguration, it's good to know what blocks exists upstream from you just in case an actual user is having trouble using your site (rather than just Let's Encrypt's automated processes).

Well, sometimes it just means that you get automatically-deployed mistakes instead of manually-deployed mistakes. :slight_smile:

I don't think it's your provider.

I think, it's your server.

Why was check-your-website blocked the first time?

My server ?? well the current setup is that I am using my "personal computer" with Win 10 where I have Hyper-V with ubuntu server. There I am testing nginx + lets encrypt certbot + nodejs app etc.

I disabled the firewall on ubuntu server, only for sure that all traffic should be enabled. And as I mentioned (and you could also saw), when ran the certbot with "pause" you were able to open the link. I am also able to open the link from my phone (different why how to check that link is accessible from internet).

This link / content is generated temporary / automatically by "certbot" + webroot + nginx, so most probalby, the original link, with the check, where is "timeout" was generated without certbot process, so link doesn't exist.

But if you have any idea how to check the process, what else I can do, please let me know I will try everything :frowning:

Second time, that's wrong. If the file doesn't exist, a http status 404 - Not Found is expected, not a timeout.

Timeout -> you have a blocking instance, especially, because checking / had worked.

That result - https://check-your-website.server-daten.de/?i=b4855103-0639-4de6-83d6-82031a7a2a3e - says: There is a problem with your configuration.

Compare it with other results, may be with the check of server-daten.de - https://check-your-website.server-daten.de/?q=server-daten.de#url-checks