Challenge failed for domain while creating certbot. Tried common solutions

Help
1

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: http://udaraw.com

I ran this command: sudo certbot --nginx -d udaraw.com

It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for udaraw.com
Waiting for verification...
Challenge failed for domain udaraw.com
http-01 challenge for udaraw.com
Cleaning up challenges
Some challenges have failed.

IMPORTANT NOTES:

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

The operating system my web server runs on is (include version): ubuntu 16.04

I can login to a root shell on my machine: YES

I'm using a control panel to manage my site: NO

The version of my client is : certbot 1.9.0

I tried uploading a file at http://udaraw.com/.well-known/acme-challenge/1234 and it's downloadable via browser. So I'm not sure why it can't access that file

1 Like
2

Welcome to the Let's Encrypt Community, Udara :slightly_smiling_face:

When using the nginx authenticator, you don't create the .well-known folder because the nginx authenticator adds an exception to your webserver configuration.

Screenshot_20201104-184637_Samsung Internet
Screenshot_20201104-184637_Samsung Internet1393×1545 914 KB

2 Likes
3

Does this help at all?

sudo certbot --nginx -d udaraw.com --nginx-sleep-seconds 10 --dry-run
2 Likes
4

@_az

For some reason the link to 1234 has me downloading 1234.bin. Any thoughts?

1 Like
5

I think that's just nginx and the browser being unable to sniff out the content type of the file (because it's 0 bytes and has no file extension).

So the browser sees application/octet-stream and decides, I can't display this as text, so I'll display a download popup.

2 Likes
6

Makes complete sense. Thanks brother. :slightly_smiling_face:

1 Like
7

@_az

Screenshot_20201104-184637_Samsung Internet
Screenshot_20201104-184637_Samsung Internet1393×1545 914 KB

why

Why certbot no give IPv6 error!?

1 Like
8

You can sometimes get away with having a broken IPv6 address.

Usually this is when the IPv6 address just times out and does not respond at all. In these cases, Let's Encrypt will fall back to the IPv4 address, if available.

However, broken IPv6 addresses will definitely cause trouble if an error occurs at any moment after a connection is successfully established, or if the IPv4 address does any form of HTTP redirect.

In general, yes, the OP should fix their IPv6 address, but I'm skeptical on whether it's the root cause here.

2 Likes
9

I concur in thinking it is not the root cause, which is why I overlooked checking for a functioning IPv6 in the first place. :wink:

1 Like
10

For what it's worth I only tried enabling ipv6 because I read in some other threads that I might need to enable it to fix this issue. So it was failing before as well. I'll fix up the ipv6 configuration today, but don't think that's the root cause either :disappointed:

1 Like
11

Try _az's first suggestion. It's only a starting point to test a theory, I think. If it doesn't help, I'm suspecting that something in your nginx configuration may possibly be interfering with the exception being placed by certbot.

You might want to delete the .well-known directory.

1 Like
12

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