Getting unauthorized and failed to download challenge files

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. |, 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: certbot certonly --nginx --debug-challenges --domain -v --dry-run

It produced this output: Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx
Simulating a certificate request for
Performing the following challenges:
http-01 challenge for

Challenges loaded. Press continue to submit to CA.

The following URLs should be accessible from the internet and return the value

Expected value:

Press Enter to Continue
Waiting for verification...
Challenge failed for domain
http-01 challenge for

Certbot failed to authenticate some domains (authenticator: nginx). The Certificate Authority reported these problems:
Type: unauthorized
Detail: Invalid response from 404

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.

Cleaning up challenges
Some challenges have failed.
Ask for help or search for solutions at 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.20.1

The operating system my web server runs on is (include version): CentOS 7.9

My hosting provider, if applicable, is: n/a, VM on esxi

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


Probably some kind of misconfiguration in your nginx, some overlapping server blocks for example.

That said, why are you trying to get a new cert? Currently as well as have a valid certificate issued just in late May and are thus valid for more than enough time?

If you're just trying to fix some issue that was introduced between that issuance and now I can understand of course :stuck_out_tongue:


As Osiris noted, a 404 with the --nginx authenticator is usually something odd with the nginx config

We can help debug if you provide more info. One option is to upload your entire active nginx config. To do this run nginx -T >upload.txt and use this forum post upload button to upload the upload.txt file (it will be large if you use the correct capital T).

Or, make a copy of /var/log/letsencrypt/letsencrypt.log to a .txt file and upload that.

If uploading is not practical, you can copy/paste the entire output of nginx -T but please surround it with 3 backticks like:
pasted output of nginx -T


Yeah, it's on a server that doesn't have a certificate. It's a wildcard cert I'm trying to apply.

nginx.txt (8 KB)

Not a ton too it, tbh. I do have nginx stopped, currently, or certbot fails on connecting to port 80. Firewalld is stopped as well.

Two things about that:

  1. You're not requesting a wildcard certificate, so you won't get one with this command;
  2. For a wildcard the dns-01 challenge is required and the --nginx authenticator can only do the http-01 challenge. See User Guide — Certbot 2.6.0 documentation for more info about plugins and their challenges.

Is there even an nginx running at Because it seems to be sending "Squarespace" as the "Server" HTTP host header.

I'm more and more puzzled now.


I am confused by the things Osiris pointed out too. If you could explain more how nginx and squarespace work together that would help.

Just looking at your uploaded nginx config it should work fine at least for

But, nginx must be running before the certbot certonly --nginx... command you issued. I say "must" because if nginx is not running Certbot will start it but without using systemd and this often creates problems. One of which can be a 404 like you see. It can be tricky to recover from this. The easiest way is to restart your server.

It looks like you are getting certs for redirects from ormutual to oregonmutual. Nothing wrong with that but more info rather than less would be helpful.


Interestingly enough, the www subdomains of both ( and ( are a CNAME to, which has 4 different IP addresses assigned to it, from 2 separate ranges it seems. However, the base domain names and have a single IP address configured in their A RR, which is just one of the 4 IP addresses of the CNAME the www subdomains point to.

So I'm not so sure how these two domains and their www subdomains are set up. Doesn't look quite right. And clearly seem to be hosted by Squarespace with 4 separate IP addresses from the looks of it. So what OP wants to do and especially HOW they want to do something with their wildcard certificate, I dunno.

Also, looking at there seems to be a wildcard certificate for * issued by DigiCert which should be valid for 2 more months. Let's Encrypt would have refused to issue that wildcard cert by the way as almost all non-wildcard hostnames would fall under the wildcard hostname, so those would be "duplicates" cq. redundant. LE doesn't like that.


That's an understatement


So squarespace is where the main site is hosted. We migrated the majority of our traffic to ormutual, but we still have some oregonmutual stuff out there (don't ask, it's stupid, I realize, it's not my doing :slight_smile: ).

10-4 review the documentation. First rodeo with certbot, so there was bound to be issues on initial config.

But "omutual" is also hosted by SquareSpace? :thinking:


Lol I guess - not my department tbh.

BUT - I think I have it figured out with this command string:

sudo certbot certonly --manual --preferred-challenges=dns --email --server --agree-tos -d -d *

I just need to pop in the DNS validation and I should be good. Thanks for pointing me in the right direction. Sometimes a nudge is all it takes :slight_smile:

You seem to be using AWS for DNS. Please use the appropriate DNS plugin suitable for AWS (Route 53 I believe?) instead of the manual plugin, as the manual plugin cannot be automated.


For this particular server, I'm just using our on-prem DNS servers. Just setup the TXT record for auth, and waiting for it to propagate. I'll follow up if it doesn't work of course :slight_smile:

What are those "on-prem DNS servers"? As your domain is clearly served by AWS. Not sure how popping those TXT RRs on some seemingly random other DNS servers would work?


Good point :slight_smile: we have the domain both places, again, not my setup.

I'll add it to Route53 and go from there.

I could set up a local DNS server serving for the domain, but that wouldn't mean other users on the public internet can reach that DNS server :wink:


Yeah our DNS is mad confusing. We had at some point before I started here a "consulting firm" do a lot of stupid stuff.


"Successfully received certificate."

So we're solid :slight_smile:

1 Like


Remember that this certificate is only valid for 90 days. If you pursue the plugin method that @Osiris mentioned, you can give Certbot a credential to automate the renewal by automatically posting updated TXT records provided from the certificate authority. (The TXT record that needs to be posted to get a renewed certificate will be different each time, so you won't have automated renewals just by leaving the original TXT record in place or anything.)