Unable to renew certificate "The client lacks sufficient authorization"

My domain is: api.rushilsrivastava.com

I ran this command: sudo certbot renew --dry-run

It produced this output:

Domain: api.rushilsrivastava.com
   Type:   unauthorized
   Detail: Invalid response from
   [2400:cb00:2048:1::681b:b0e0]: 404

My web server is (include version): Apache 2.4.18

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

I can login to a root shell on my machine (yes or no, or I don’t know): yes

So, I have read countless threads on similar issues, but I have been unable to find a solution. I can access the /.well-known/acme-challenge/ folder:


I have been able to renew my certificates before, this is the first time I have experienced such an issue. This issue is happening to all my domains setup via Virtual Hosts. All of them are throwing a 404 error, and I confirmed that I can access test files on each one individually (like the example link provided above). How should I go about solving this problem?

Hi @rushilsrivastava,

Can you post the contents of /etc/letsencrypt/renewal/api.rushilsrivastava.com.conf?

Sure thing:

# renew_before_expiry = 30 days
version = 0.21.1
archive_dir = /etc/letsencrypt/archive/api.rushilsrivastava.com
cert = /etc/letsencrypt/live/api.rushilsrivastava.com/cert.pem
privkey = /etc/letsencrypt/live/api.rushilsrivastava.com/privkey.pem
chain = /etc/letsencrypt/live/api.rushilsrivastava.com/chain.pem
fullchain = /etc/letsencrypt/live/api.rushilsrivastava.com/fullchain.pem

# Options used in the renewal process
account = 68b506bc20e0cf8407a444422cd00648
installer = apache
authenticator = apache

Thanks! Could you also post the log file generated when you attempt to renew (from /var/log/letsencrypt)?

Tried uploading the log file here, but it seems that filetype is not allowed. Since it is fairly long, and I was unsure what parts you needed, you can find the file here:

Hi @rushilsrivastava,

Could you please show the output of this command?.

namei -l /var/lib/letsencrypt/*

Because maybe your issue is related to this:

Here the open bug issue:


Sure thing. Here is my output for that command:

f: /var/lib/letsencrypt/backups
drwxr-xr-x root root /
drwxr-xr-x root root var
drwxr-xr-x root root lib
drwxr-xr-x root root letsencrypt
drwxr-xr-x root root backups
f: /var/lib/letsencrypt/http_challenges
drwxr-xr-x root root /
drwxr-xr-x root root var
drwxr-xr-x root root lib
drwxr-xr-x root root letsencrypt
drwxr-xr-x root root http_challenges

@bmw it looks like this is a recent Certbot trying to do HTTP-01 with --apache behind CloudFlare. It creates some rules related to /.well-known/acme-challenge in a virtual host, but CloudFlare sends a 301 for HTTP → HTTPS and then the origin server apparently serves a default CMS page rather than the challenge file. I don’t know if it might have worked but for the redirect? Maybe the rules that the Apache plugin created only apply to the HTTP virtual host and not the HTTPS one… does that make sense?

(I also don’t know if the 301 redirect was originally triggered by the origin server or by some kind of CloudFlare configuration, because I don’t think CloudFlare explains exactly why it’s redirecting you.)

1 Like

I guess the temporary solution was embedded in that. I disabled Cloudflare and was able to manually renew the certificates.

This isn’t how it is supposed to work though, right?

Right, it’s possible that this is a slightly obscure bug in Certbot which is only noticeable in cases where someone uses CloudFlare or another reverse proxy CDN this way. Let’s see what @bmw thinks about it.

I’m glad you were able to find a way to renew your certificate.

What’s going on here is Certbot knows nothing about your external redirect so it sets things up to serve the challenge over HTTP but that request never comes because Cloudflare is redirecting the request to HTTPS. This is a bit hard for us because I’m unaware of a way for us to reliably detect configuration outside of Apache like this, but I created https://github.com/certbot/certbot/issues/5763 to consider just always modifying HTTPS vhosts as well which would work around this problem.


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