Failed to Authenticate

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 run -d, --nginx --test-cert -v

It produced this output:

Plugins selected: Authenticator nginx, Installer nginx
Requesting a certificate for and
Performing the following challenges:
http-01 challenge for
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: 2606:4700:3037::ac43:a039: Invalid response from 521

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

The operating system my web server runs on is (include version):
Debian GNU/Linux 11 (bullseye)

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

The Detail bullet point in the output reports 2606:4700:3037::ac43:a039; if this is supposed to represent my server it is incorrect. Performing an nslookup locally and using tools online reports the correct addresses: and 2600:3c02::f03c:93ff:fe1f:3b9a

DNS is hosted by Cloudflare but proxy is currently turned off which should be visible via the nslookup tests. I turned off the proxy for both DNS entries with no success followed by turning on Development Mode with no success. This was done roughly 10 hours ago and is still set.

# ip addr
2: eth0:
    inet brd scope global eth0
    inet6 2600:3c02::f03c:93ff:fe1f:3b9a/64 scope global dynamic mngtmpaddr
1 Like

Welcome to the community @kyden

The "wrong" IPv6 address in the error message looks like it's Cloudflare. The Let's Encrypt server first makes an http request to your server but will follow redirects.

But, I agree right now your DNS points directly to your server and I see normal responses without any redirection.

Sorry to ask but can you confirm you see that same error right now? It's just so puzzling because I don't see anything like that.

curl -i6

HTTP/1.1 404 Not Found
Server: nginx/1.18.0
Date: Sat, 21 May 2022 16:11:09 GMT
Content-Type: text/html
Content-Length: 153
Connection: keep-alive

<head><title>404 Not Found</title></head>
<center><h1>404 Not Found</h1></center>


No worries at all! I'm happy to perform tests. I've just attempted the command again:

certbot run -d, --nginx --test-cert -v and the same IPv6 address is coming back. I've just tossed up a page at Hello! and Hello!

1 Like

Thanks. Wow, very odd. I hope some other volunteer will see something wrong because I can't explain the certbot error.

The site looks up DNS similar to Let's Encrypt server and it looks fine for A and AAAA too. (LE servers use IPv6 when AAAA is present)

The Let's Debug test site details also show good results.

Interesting that the certbot error has a 521 after the error. This was the http response to the LE server's request to your server and means "server down". This can happen when Cloudflare CDN can't connect to your origin server. But, as we see, the CDN does not seem involved right now. Very puzzling.


Thank you checking! I was not aware of the debug mode in the test site prior to now! Indeed, automated verification implies DNS records are still pointed or cached to Cloudflare but all manual look ups point to the correct addresses.

The TTL for the A and AAAA records are set to "Auto" in Cloudflare which appears to be 300 seconds which I have far exceed by now.


Scratch that! I was looking at A and AAAA records for My eyes clearly glazed over at the www CNAME which was still proxied. I greatly appreciate your time @MikeMcQ as it helped me take a step back and review the small details! I'm marking this post as the solution for future readers, but it was @MikeMcQ who got me here. :slight_smile:


So did mine apparently! :slight_smile: Funny thing is I thought I looked up both DNS anyway.


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