Webroot plugin : The client lacks sufficient authorization


Hello there.

I get an issue with the webroot plugin. I have debian 8. I have the same issue on another debian 7.

Apache plugin working properly (on my debian 8), cert is correctly generated and installed.
For some reasons, i wan’t to try the webroot plugin, in certonly, but there i get an issue.
Here’s my command :

./letsencrypt-auto --webroot -w /var/www/domain.com/web/ --text -d domain.com -d www.domain.com certonly --email myemail@email.fr

When it run, i see that the folder /.well-known/acme-challenge/ is properly created in /var/www/domain.com/web/.
My server is configured to serve files in hidden folders.

Here’s the issue prompted in the terminal :

Failed authorization procedure. domain.com (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://domain.com/.well-known/acme-challenge/WGxhr3iZhB23UIbOqyfQp0z-uadvqKShPADfDgCsV2E []: 403, www.domain.com (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://www.domain.com/.well-known/acme-challenge/ErhDvsRaDilMBwU-x4CXYra9Ni5TCwWFnpZ6lkfw_Gk []: 403

 - The following 'urn:acme:error:unauthorized' errors were reported by
   the server:

   Domains: domain.com, www.domain.com
   Error: The client lacks sufficient authorization 

Any idea ?

Certbot http-01 challenge fails for non-www pages

The only time I’ve seen that one was when I didn’t have /.well-known present, but you have that.

The only other thing I can think of is that the permissions are wrong, so even though the files/directories are there they are not accessible. Could your umask be configured in such a way that when the directories or files are created the user/group apache is using cannot read them?

If you create a dummy file under /well-known/acme-challenge can you retrieve it over http from the outside world?


It’s an interessant idea, but not seems to be the solution.
For info, my websites a generated throught ISP Config panel.

I juste tried to check owner / permissions, but everything songs good :

drwx--x--x 11 web6 client2 4096 déc. 4 13:10 . drwxr-xr-x 9 root root 4096 nov. 5 09:57 .. drwxr-xr-x 2 web6 client2 4096 nov. 5 10:01 css drwxr-xr-x 2 web6 client2 4096 nov. 5 09:57 error drwxr-xr-x 2 web6 client2 4096 nov. 5 10:01 gestion -rwxr-xr-- 1 web6 client2 26 nov. 5 09:57 .htaccess drwxr-xr-x 2 web6 client2 4096 nov. 5 10:01 img drwxr-xr-x 4 web6 client2 4096 nov. 5 10:01 inc -rw-r--r-- 1 web6 client2 11392 nov. 5 10:03 index.php drwxr-xr-x 4 web6 client2 4096 nov. 5 10:01 js drwxr-xr-x 17 web6 client2 4096 nov. 5 10:01 newsletter -rw-r--r-- 1 web6 client2 14 nov. 5 10:01 robots.txt drwxr-xr-x 2 root root 4096 déc. 4 00:30 stats drwxr-xr-x 3 root root 4096 déc. 4 13:10 .well-known

Si i assume that letsecnrypt-auto generate files and folders as root:root.
And when i generate a test file as root:root in /.well-known/acme-challenge/ it’s readable via http. I can access it via my browser.



I think you’re right.
I juste tried a chmod 0777 on the /.well-known/ directory, and then retry to generate cert vie webroot plugin, and then… it’s work !

So it’s definitivly a folder permission issue.


That’s odd, unless there’s something in your apache to restrict that. Just checked mine & its the same as your’s originally:

drwxr-xr-x 3 root root 4096 Nov 18 11:50 .well-known

& that one’s working. It’s not a good idea to use 0x777 as thats now globally writable but at least it’s pointing you in the right direction.



However , the folder .well-known/acme-challenge/ has other right :

drwxr-xr-x 3 root root 4096 déc. 4 16:34 . drwx--x--x 11 web6 client2 4096 déc. 4 16:34 .. drwx--x--x 2 web6 client2 4096 déc. 4 16:34 acme-challenge

The “other” user can’t read it.
If the files created inside have the same rights, then apache can’t read it, because file are created as root, am i right ?

That could be the source of the problem no ?


Sort of.

With acme-challenge being executable only for group & other then you can still get at those directories - just can’t list or create new ones.

As long as the files are readable by apache then it should still be able to read them - so if apache is in the client2 group then it will be able to serve them.

Hence why I asked earlier about the umask when you run the LE client. if that’s too restrictive then it would apply the wrong perms to those files hence apache being unable to read them.



I have the same issue with the latest client (got it from git at 12.04.2015 - 6PM) the folders are beeing created under the server root, the files are beeing created and have the content. But they get created with pretty useless rights on themselves:

-rw---x--- 1 web1 client3   87 Dez  4 18:25 D5T6yEvvbdWa6SbbjhNFkk-cTWuNK2-AK9ouHOrIs10
-rw---x--- 1 web1 client3   87 Dez  4 18:25 ec0R-UUQXCtVhNmvo8rpl45jCJrili3Qk0HZS3dmfoc

So the files can not be read by apache as the server is in the client3 group but running as the user www-data and not web1; Is there a way to make the letsencrypt client create the files with rw-r–r-- instead of that pointless x for group?

the folder acme-challenge has the same wired permissions
drwx--x--- 2 web1 client3 4,0K Dez 4 18:25 acme-challenge

So as I changed the rights on acme-challenge manually to be drwxr-x— it works! No need to allwo everyone full access on the .well-known folder


Out of interest, as root what do you get if you run umask?

On the machine I run the client on:
root@bestia:~# umask 0022

On my machine (client was updated about 2100GMT last night Dec 3) I didn’t have any problems at all, so I’m wondering if locally you’ve got set differently?

That’s presuming nothing odd changed in the client in the last 20 hours or so.


That’s what I get:
root@server:~# umask

Those rights are absolutely needed so that it works:
drwxr-xr-x 3 root root 4,0K Dez 4 18:18 .well-known

drwxr-x--- 2 web1 client3 4,0K Dez 4 18:43 acme-challenge

When I set them to this right the files get created with g=rx and thus the server can read them and I get my certificate


That’s really odd then.

What I’ve just tried was I created a brand new cert on a domain I’ve not used before, first removing the acme-challenge directory, so there was just the .well-known directory in existence.

I then ran the client as usual & it’s simply recreated the acme-challenge directory with the correct permissions:

drwxr-xr-x 2 root root 4096 Dec 4 17:50 acme-challenge

Now that directory exists does it stay with the correct permissions? I’m wondering if there is a difference in the clients?


If I create the directories (have a view domains I am trying) in advance and set them to the above mentioned permissions it works right away. The client does create the folders with wrong permissions… at least when used with separated users for ispconfig managed server.


I am having the same issue. I get the same error as lsccommunication.

I am running CentOS 7 and WHM/cPanel, so I am not using the Apache plugin. I installed LE from the instructions at:

I am trying to create a certificate by following a post on the cPanel forums with the following command:
./letsencrypt-auto certonly --webroot --webroot-path /home/cpaneluserid/public_html/ -d domain.com -d www.domain.com

Of course, cpaneluserid and domain.com are set to the correct values.

I have followed the foregoing posts in this thread with interest and tried everything mentioned, without achieving any success.

I am running from a remote client via ssh, logged in as root.

LE is creating the folder structure:

The users/groups and permissions:
drwxr-xr-x 3 root root 4096 Dec 5 11:12 /home/cpaneluserid/public_html/.well-known/
drwxr-x— 2 cpaneluserid nobody 4096 Dec 5 11:13 /home/cpaneluserid/public_html/.well-known/acme-challenge/

There is nothing in acme-challenge. It creates the folders, but there are no files created.

When I put a test html file in acme-challenge I can reach it from a browser over http.

umask gives:

I have tried lots of combinations of users, groups and permissions without success, despite what works for Th3Z0ne. Even 777 won’t work for me.

I am at your mercy and would be grateful for any help or ideas.


Try to stop your web server!
I used to run into the same trounbe until I stopped apache and nginx.
Please write back to see if it helped=)


No metro2030, that doesn’t help. I forgot to mention that I’d already tried that, but I tried again without success. Exact same error.

Thanks anyway.


Have you installed EPEL repo?


I don’t even know what that is. Reading up on it now. How will it help with LE?



It is obligatory to install in RHEL/CentOS.
Try reading here: http://fedoraproject.org/wiki/EPEL


Yep. Seems I already have EPEL.


Then, I am at a loss =(