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
Did you choose "reconfigure services = yes" during ispconfig update? If not, then the letsencrypt config in the apache files will be missing.
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?
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
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
I'm not aware of anyone else having this issue. On my servers, it works fine with the default permissions that ISPConfig uses.
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.
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.
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
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