Let's Encrypt Permission denied error on acme challenge

Discussion in 'Installation/Configuration' started by Shaky, Dec 5, 2016.

  1. Shaky

    Shaky New Member

    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
     
  2. till

    till Super Moderator Staff Member ISPConfig Developer

    Did you choose "reconfigure services = yes" during ispconfig update? If not, then the letsencrypt config in the apache files will be missing.
     
  3. Shaky

    Shaky New Member

    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?
     
  4. Bicet

    Bicet Member

    @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
     
  5. till

    till Super Moderator Staff Member ISPConfig Developer

    The docroot depends on the php mode that you use. I guess the second site uses still mod_php.
     
  6. Shaky

    Shaky New Member

    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).
     
    till likes this.
  7. Shaky

    Shaky New Member

    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?
     
  8. Jesse Norell

    Jesse Norell Well-Known Member

    I have debian 8 with permissions showing the same as your first post and letsencrypt works fine. I'm running certbot 0.9.3-1~bpo8+2
     
  9. Shaky

    Shaky New Member

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

    Jesse Norell Well-Known Member

    I removed standard system accounts and a few local things, but web related entries are:
    Code:
    www-data:x:33:
    sshusers:x:1000:web3,web4,web5,web6,web7,web8,web10,web12,web14,web15,web23,web32,web33,web35,web36,web37,web38,web40,web41,web42,web43,web44,web45,web46,web47,web48,web52,web53,web54,web55,web56,web57,web58,web59,web60,web61,web62,web64,web65,web66,web67,web68,web69,web70,web71,web72,web73,web74,web76,web77,web78,web79,web80,web82,web84,web85,web86,web87,web88,web89,web90,web91,web92,web93,web94,web95,web96
    ispapps:x:1001:www-data
    ispconfig:x:1002:www-data
    client2:x:1003:www-data
    client1:x:1004:www-data
    client3:x:1005:www-data
    ispconfigend:x:20000:
    client4:x:10005:www-data
    client5:x:10006:www-data
    client6:x:10036:www-data
    client8:x:10038:www-data
    client9:x:10042:www-data
    client11:x:10043:www-data
    client12:x:10044:www-data
    client14:x:10045:www-data
    client15:x:10046:www-data
    client16:x:10047:www-data
    client18:x:10052:www-data
    client19:x:10054:www-data
    client20:x:10055:www-data
    client21:x:10056:www-data
    client22:x:10057:www-data
    client23:x:10060:www-data
    client33:x:10061:www-data
    client36:x:10062:www-data
    client46:x:10064:www-data
    client48:x:10065:www-data
    client49:x:10066:www-data
    client50:x:10067:www-data
    client51:x:10069:www-data
    client53:x:10070:www-data
    client28:x:10071:www-data
    client30:x:10072:www-data
    client56:x:10073:www-data
    client39:x:10074:www-data
    client41:x:10077:www-data
    client43:x:10078:www-data
    client32:x:10079:www-data
    client57:x:10080:www-data
    client27:x:10081:www-data
    client37:x:10087:www-data
    client61:x:10088:www-data
    client60:x:10089:www-data
    client65:x:10090:www-data
    client24:x:10091:www-data
    client63:x:10094:www-data
    client25:x:10095:www-data
    client29:x:10096:www-data
    
     
  11. Shaky

    Shaky New Member

    All the same. :-(
     
  12. till

    till Super Moderator Staff Member ISPConfig Developer

    I'm not aware of anyone else having this issue. On my servers, it works fine with the default permissions that ISPConfig uses.
     
  13. KoS

    KoS Member HowtoForge Supporter

    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.
     
  14. till

    till Super Moderator Staff Member ISPConfig Developer

    Please make a bug report in the bug tracker so we can investigate it. I do not have that problem on my servers but @florian030 just send me an email today that he has one server with that problem as well.
     
  15. florian030

    florian030 ISPConfig Developer ISPConfig Developer

    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
     
  16. Brano

    Brano New Member

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

    florian030 ISPConfig Developer ISPConfig Developer

    chmod -R 755 /usr/local/ispconfig/interface/acme
     
  18. KoS

    KoS Member HowtoForge Supporter

    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.
     

Share This Page