[SOLVED] Let's Encrypt Permission denied error on acme challenge

Hi there,
I recently updated from ISPConfig 3.0 to ISPConfig 3.1 (3.1.1p1), mostly because of the build in Let's Encrypt feature and the Vhost Aliases. But I can't get Let's Encrypt to work. I always receive the error "WARNING - Let's Encrypt SSL Cert for: XXXXXXXX could not be issued." via e-mail. Tried to nail it down but I'm stuck now.

The Apache logs are showing the following:
access.log

Code:

XXX.XXX.XXX.XXX- - [04/Dec/2016:18:44:41 +0100] "GET /.well-known/acme-challenge/4O0uSa17HEVeT16UQscTkDXQq2WngxweaxWEhGJNvGA HTTP/1.1" 403 2102 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0"

error.log

Code:

[Sun Dec 04 18:44:41.187536 2016] [core:error] [pid 7908] (13)Permission denied: [client XXX.XXX.XXX.XXX:60784] AH00132: file permissions deny server access: /usr/local/ispconfig/interface/acme/.well-known/acme-challenge/4O0uSa17HEVeT16UQscTkDXQq2WngxweaxWEhGJNvGA

I can see that the acme challenge file is successfully written to the directory "/usr/local/ispconfig/interface/acme/.well-known/acme-challenge/". Of course it is removed after the validation fails, but it is there for some seconds. Owner: root:ispconfig, rights: 0644.
These are the rights for the whole path (namei -mo /usr/local/ispconfig/interface/acme/.well-known/acme-challenge):

Code:

drwxr-xr-x root  root  /
drwxr-xr-x root  root  usr
drwxrwsr-x root  staff  local
drwxr-sr-x root  root  ispconfig
drwxr-s--- ispconfig ispconfig interface
drwxr-s--- ispconfig ispconfig acme
drwxr-s--- ispconfig ispconfig .well-known
drwxr-s--- ispconfig ispconfig acme-challenge

Software versions:
Debian GNU/Linux 8 (jessie)
Linux version 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19)
ISPConfig 3.1.1p1
certbot 0.9.3

 

Yes I did. Which configs do belong to letsencrypt? Is it just the Alias in 000-ispconfig.conf?

Code:

Alias /.well-known/acme-challenge /usr/local/ispconfig/interface/acme/.well-known/acme-challenge
<Directory /usr/local/ispconfig/interface/acme/.well-known/acme-challenge>
         Require all granted
     </Directory>

This is working, otherwise Apache wouldn't log the "Permission denied" error.

Are my file access rights okay? Could you please post a "namei -mo" from a working installation?

 

@till
I've many different hosts on an ispconfig 3 server updated from ispconfig2.
I've as well noted that for some hosts I can make the certificates, for some other not.

An extract from the 2 vhosts

Code:

<Directory /var/www/workingdomain.com>
        AllowOverride None
                Require all denied
        </Directory>

<VirtualHost *:80>
        DocumentRoot /var/www/clients/clienX/webXX/web

Code:

<Directory /var/www/notworkingdomain.org>
        AllowOverride None
                Require all denied
        </Directory>

<VirtualHost *:80>
DocumentRoot /var/www/notworkingdomain.org/web

Do you know why the document root is so different and why in the first case it works and doesn't work on the second

 

I've set the execute bit on all directories in the path and it works now. The new rights:

Code:

drwxr-xr-x root  root  /
drwxr-xr-x root  root  usr
drwxrwsr-x root  staff  local
drwxr-sr-x root  root  ispconfig
drwxr-s--x ispconfig ispconfig interface
drwxr-s--x ispconfig ispconfig acme
drwxr-s--x ispconfig ispconfig .well-known
drwxr-s--x ispconfig ispconfig acme-challenge

I doesn't seem to be a security issue as there is no other directory in /usr/local/ispconfig/interface with execute or read rights for everyone (others).

 

Today I updatet ISPConfig to v3.1.2 and the file access rights have reverted to the ones I've stated in the first post. And of course Let's Encrypt did not work until I changed the rights.
This is a big issue. Am I the only one experiencing this?

 

Thank you. I'm using the same here.
Could you please post or send me your /etc/group file?

 

All the same. :-(

 

I have had exactly the same issue as Shaky. I had previously manually chmoded the directory and after upgrade to 3.1.2 the access rights have been reverted and let's encrypt authentication stopped working. After a manual chmod to fix the permissions it works again.

• debian wheey, using backports and dotdeb for php55
• apache2 -> 2.2.22-13+deb7u7

i have other machines with the same config where i can show you the original, problematic permissions etc if needed.

 

I had the problem with nginx. To solve this, you can set the permissions for all folders to /usr/local/ispconfig/interface/acme/.well-known/acme-challenge to 755. Otherwise nginx (at least on my server) is not able to read a file. I did not see this problems on my web-servers running apache 2.4.
You can test if LE can reach .well-known/acme-challenge:
touch /usr/local/ispconfig/interface/acme/.well-known/acme-challenge/a
http://example.com/.well-known/acme-challenge/a

And do not use
location ~ /\. { deny all;}
inside the nginx-directives

 

I got same issue on client's server where using mod_php. Not solved yet.

 

chmod -R 755 /usr/local/ispconfig/interface/acme

 

does NOT resolve the issue, only after chmod 755 the interface directory the files in acme-challenge are accessible from the URL.

this issue has hit me again after upgrading to ISPconfig 3.1.3.
Wasn't that fixed? Shall I create a new issue in https://git.ispconfig.org/ to finally resolve that issue? Thanks.

 

any news on this?
I'm experiencing the same with ubuntu 16.04.2 + isp 3.1.6
29.08.2017-10:10 - DEBUG - mkdir failed: /usr/local/ispconfig/interface/acme/.well-known/acme-challenge/
29.08.2017-10:10 - WARNING - Could not verify domain XXX.hu, so excluding it from letsencrypt request.
29.08.2017-10:10 - WARNING - Could not verify domain www.XXX.hu, so excluding it from letsencrypt request.
29.08.2017-10:10 - WARNING - Let's Encrypt SSL Cert for: XXX.hu could not be issued.
29.08.2017-10:10 - WARNING -

 

OK, I've found out MY problem.
this server is behind a NAT firewall and can't access this webpage on it's original public IP address - design fail.
that's why ISP can't check the certificate file generated and won't allow LE to be enabled