Some challenges have failed

Hello, Let's Encrypt Community.

I executed the following command on my Ubuntu server:

sudo certbot certonly --webroot -w /var/www/my_site/.well-known/acme-challenge -d mydomain.com

(Of course, I replaced "my_site" and "mydomain.com" with the appropriate values)

However, the challenge is failing because certbot is not automatically creating the .well-known/acme-challenge/ZuGC2x8eF_cQVoAdVTj33sMPvvBZRqsz5ta84R4Yxnc challenge file. I don't have any inquiries about the HTTP challenge failure, but I'm curious: Shouldn't the certbot command create the file in the specified location before attempting to issue the certificate, right?

Thank you!

1 Like

You should use

-w /var/www/my_site/

With your flag, it’ll be including the .well-known/acme-challenge directories twice.

The --debug-challenges flag can be useful for manually inspecting the files before continuing

5 Likes

I have tried this way too, but still no success, @mcpherrinm .

I think this command should create the challenge file, but I got none on any directory I have tried...

@Leitonez can you answer this question
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):

And how it was installed too?

1 Like

Try placing a test text file in that expected ACME challenge location:

See if you then can retrieve that file from the Internet, with:
http://YourDomainName/.well-known/acme-challenge/TESTFILENAME

1 Like

@Bruce5051

My certbot version is: certbot 2.9.0

@mcpherrinm

The same command passing --debug-challenges and -v is showing at the last line:

Cleaning up challenges

So, now I can realize that challenge file is beeng created and after a http request failure, it is deleted.

In debug mode, before submit the request, I have opened my browser and pasted the entire URL that will be requested by let's encrypt. And the file was download successfully...

So I don't have any clue by now

1 Like

Locally?
Or over the Internet?

1 Like

Over the internet @rg305

hmm...

2 Likes

Please show an example of that.

Did you try the test I recommended?:

1 Like

Hey guys. I've just changed my domain to another one and everything is looking great right now.

I think let's encrypt don't issue certificate for: <my_server_name>.hstgr.cloud

But It does for: <my_server_name>.mypersonaldomain.com

Don't know why, but It is working!

Thank you!

They recently issued this cert:
[for a similar name]
image
crt.sh | 11922524624

So, it must be something within your web service.
If you are using Apache web server, I'd review the output of the command below to ensure there are no name:port overlaps:
sudo apachectl -t -D DUMP_VHOSTS

Glad to hear that you got a working cert :slight_smile:

2 Likes

When you opened this thread in the Help section, you should have been provided with a questionnaire. Maybe you didn't get it somehow (which is weird), or you've decided to delete it. In any case, all the answers to this questionnaire are required:


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

2 Likes

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