Failed authorizations renew

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

It produced this output:
unauthorized (I logged in as root)
Invalid response (this has worked fine this year?)

My web server is (include version):
apache 2

The operating system my web server runs on is (include version):
Ubuntu 20.04

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

We'll need the exact command used and the entire output to see what's going on.

Seems like it might be an IPv6 problem:

If it's not that, I agree, please post the full output of

certbot renew --dry-run

I do not see where to attach a file, since the output takes many lines.

If you like, you could use something like or and provide a link.

I'm having problems on this server pasting a large number of lines, even when making the font small enough to fit on one page. I would like to upload a file.

Ah, I understand.

The most recent Certbot command you ran will have saved its debug log to /var/log/letsencrypt/letsencrypt.log.

You could:

  1. Run certbot renew --dry-run
  2. Download that log file off your server, and then upload it here or somewhere else.

I believe if you rename the file to .txt, you can upload it using this forum.


1 Like


This is the IPv6 issue I mentioned earlier:

Your domain's AAAA address is not responding to traffic, and due to some technicalities about how Let's Encrypt handles redirects, it's not able to fall back to IPv4 to complete the authorization.

Fixing the IPv6 connectivity of your server, or removing the AAAA record, should do the trick.

edit: missed the not in is not

1 Like

It's strange, since I have not changed any DNS settings in about a year, and letsencrypt has renewed previously?

The DNS may not have changed, but your IPv6 address has become inaccessible.

Maybe on your Linode, the operating system has unconfigured the IPv6 address or something.

I'll open a Support ticket on this Linode and have them check this out.


1 Like

I took all IPv6 lines out of my /etc/apache2/sites-enabled/ files and I get the same (negative) results?

If you intend to avoid the problem by not using IPv6 at all, then you would need to remove the AAAA record from your DNS.

This would prevent browsers (and Let's Encrypt) from trying to connect to your IPv6 address.

I just checked with Linode support, and they cannot see any problems with my IPv4 or IPv6 settings.

What did they say exactly?

if you can't figure out how to get IPv6 back, it's probably easier to just remove the record.

The problem is that, after years of using a strict Cloudflare cert, port 80 redirects to port 443. Letsencrypt requires 80. Unless there is another setting for LE, this will not work on my site.

This problem has nothing to do with IPv6.

Hi @lingber

that's wrong. Letsencrypt starts with port 80, but follows redirects to domain + port 443 or other domain + port 80 / port 443.


That's definitifly wrong. Your ipv6 is buggy - see

You have ipv6 and ipv4. But your ipv4 works, your ipv6 has a timeout / port 80.

Domainname Http-Status redirect Sec. G 302 Html is minified: 100,00 % 0.344 A 302 Html is minified: 100,00 % 0.344 A 2600:3c01::f03c:91ff:fe93:e6f3 -14 10.030 T
Timeout - The operation has timed out 2600:3c01::f03c:91ff:fe93:e6f3 -14 10.030 T
Timeout - The operation has timed out

Same with port 80 / 443 /.well-known/acme-challenge/random-filename.

You have

  • to fix your ipv6, so it works (or)
  • remove the AAAA entry

Checking your domain Letsencrypt prefers ipv6, so that's critical.

Thanks for that analysis. I'll work with Linode support to fix this.

I recall that I turned off ipv6 in my Ubuntu grub2 kernel. The fastest way I could correct that was to switch to Linode's latest 64-bit kernel. I rebooted and was able to renew my cert just fine.

Thanks to the people here who pointed out that I had an ipv6 problem!