Failed authorization procedure. The client lacks sufficient authorization

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: sudo certbot

It produced this output:

Type: unauthorized
Detail: Invalid response from
[]: 403

My web server is (include version): LAMP

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

My hosting provider, if applicable, is: CONTABO (VPS)

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 0.31.0

I’m trying to get a SSL certificate for the domain hosted on my VPS as Virtual Host. I followed same procedure for the others Virtual Host hosted on my VPS, but for some reason I’m getting the error as per details above. The DNS is correct (record A). This is what the let’s encrypt log is showing:

certbot.errors.FailedChallenges: Failed authorization procedure. (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from []: 403, (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from []: 403

Thank you in advance for your support.

Welcome to the Let’s Encrypt Community, Carlo :slightly_smiling_face:

The Good:
I’ve noticed an extensive autorenewal history of certificates at, including one that is still valid until November 16.

The Bad:
I’ve noticed some very concerning redirects and responses, including a 403 Forbidden response that will make renewal impossible. Your webserver configuration is in desperate need of repair. There are several people here who can most likely help you resolve this. Sadly, I am not one of them.


Rudy, you up for another bout? redirects to, which returns 403 Forbidden. does not respond at all. temporarily redirects to, which redirects to, which redirects to, which returns valid content 200 OK.

He clearly said www in the domain.
[the non-www is a whole other can of worms (not asked to be opened here)]

The non-www redirects to the www.

Not for me, it doesn’t:

curl -Iki
HTTP/1.1 403 Forbidden
Date: Sat, 19 Sep 2020 20:34:46 GMT
Server: Apache/2.4.29 (Ubuntu)
Content-Type: text/html; charset=iso-8859-1

It returns 403.
And so does any/all other folders and paths under that name (all 403 forbidden).

Look at my first image, brother… :slightly_smiling_face:

Look at my curly q’s sista - rofl

I don’t doubt your mad skills, but I’m pretty sure the top redirect checker on Google isn’t broken.

I find it hilarious that it returns:

403 Forbidden

CONGRATULATION Everything seems to be fine.


Its all about source IP then…
Cuz I see this:

So there must be some GeoLocomotion action in play.

This is cute too:

Addresses:  2a02:c205:0:891::1


You seriously don’t get redirected from to

You first image has no www - look at his domain and then at your first image again.

I know that. LOL. I was just being thorough. :laughing:

Ignore the non-www - that is NOT in question here.
Start at the www and use HTTP.
Follow that leader…
It goes nowhere fast.

Straight into the 403 then :raised_hand:

1 Like

OK then we need to know what’s going on inside:
Server: Apache/2.4.29 (Ubuntu)
at IP:
When asked for site:
via: HTTP

Q1: Output of: sudo apachectl -S


As always seems to be the case when we chat, I need to eat now. Been up for 8 hours doing mostly manual labor and haven’t eaten anything yet. See you soon, brother.


You’re in the best of hands with Rudy.

Dang, I got to label paint cans now - rofl
[and then eat too]

But we do have one (initial) pending question waiting to be answered…

1 Like

*:443 is a NameVirtualHost
default server (/etc/apache2/sites-enabled/
port 443 namevhost (/etc/apache2/sites-enabled/
port 443 namevhost (/etc/apache2/sites-enabled/
port 443 namevhost (/etc/apache2/sites-enabled/
port 443 namevhost (/etc/apache2/sites-enabled/
port 443 namevhost (/etc/apache2/sites-enabled/
*:80 is a NameVirtualHost
default server (/etc/apache2/sites-enabled/000-default.conf:1)
port 80 namevhost (/etc/apache2/sites-enabled/000-default.conf:1)
port 80 namevhost (/etc/apache2/sites-enabled/
port 80 namevhost (/etc/apache2/sites-enabled/
port 80 namevhost (/etc/apache2/sites-enabled/
port 80 namevhost (/etc/apache2/sites-enabled/
port 80 namevhost (/etc/apache2/sites-enabled/roundcube.conf:1)
port 80 namevhost (/etc/apache2/sites-enabled/
ServerRoot: “/etc/apache2”
Main DocumentRoot: “/var/www/html”
Main ErrorLog: “/var/log/apache2/error.log”
Mutex ssl-stapling: using_defaults
Mutex ssl-cache: using_defaults
Mutex default: dir="/var/run/apache2/" mechanism=default
Mutex mpm-accept: using_defaults
Mutex watchdog-callback: using_defaults
Mutex rewrite-map: using_defaults
Mutex ssl-stapling-refresh: using_defaults
PidFile: “/var/run/apache2/”
User: name=“www-data” id=33
Group: name=“www-data” id=33

Good luck gentlemen. :slightly_smiling_face: