Hello all. I have a multi-server setup that I upgraded from ISPC 3.0 to 3.1. The problem is that it seems I can't enable letsencrypt for the sites on the secondary server (works ok on the primary). On both nodes I followed step 11 of "the perfect server" for Jessie. Am I missing something or id it a bug in ISPC? Tks.
I found the first problem: the last 4 levels in /usr/local/ispconfig/interface/acme/.well-known/acme-challenge were not world-executable, so the aliased path was inaccessible. Now I have that fixed and it's possible to manually generate a LE cert with /opt/certbot/certbot-auto certonly --webroot --webroot-path /usr/local/ispconfig/interface/acme -d mydomain.example.org But if I enable LE checkbox in ISPC, it returns disabled after cron run. What else can I check?
Ok. Solved. The remaining problem was that LE checks all the site domains, and I had a "www." value for auto-subdomain. The problem became obvious after looking at /var/log/ispconfig/cron.log . Sorry for the noise. Maybe some 'site specific error reporting' when an operation on a site fails could be really useful.
Do you have an A, AAAA or CNAME dns entry for the www. subdomain in your DNS? That is still required. A wildcard entry won't suffice (e.. * CNAME doman.tld.)
No. That's the second reason that prevented the cert to be created. I just removed the www auto-subdomain to fix it: it wasn't accessible anyway. I still can't understand why I had NOT to chmod o+x the path to acme-challenge on the primary server, but I suspect that it's just because I needed it only for the ISPC (default) site, not for a SuEXEC one...
It's quite an old multi-server install (wheezy was still new). I've always used "standard" certs (having some renew troubles, sometimes, for the ones that required a certificate chain, but that's a completely unrelated thing) and this is the first time I use LE on a multiserver setup. Might it be related to the fact that the virtualhost is using SuExec? IIUC, with SuExec the server process handling the request for the vhost is running as that vhost's user/group, hence it can't access something in a path with non o+x directories. But, if that's the reason, I don't understand why it works when validating SuExec sites on the primary server... Or (more probably) I haven't grasped yet how Apache handles the Alias directive... Anyway, I'd like to understand the problem, not just make it work.
The LE (certbot) command to create the cert is executed by the apache ispconfig plugin as root, so suexec should not matter here. The alias directive is in the ispconfig vhost or ispconfig conf file, it is just used to redirect the requests for LE to a central directory on the server where LE can place it's tokens.
Yep. I understood that. And that's the working part. But, once certbot contacts the CA, a request arrives for the given domain. If that request is served by a suexec vhost, it won't be able to read the file that certbot generated. Actually, you would see two different messages: - 404 if certbot placed the file in the wrong directory - 403 if the file is not accessible From error.log: [Fri Nov 25 09:18:05.267359 2016] [core:error] [pid 18684] (13)Permission denied: [client 66.133.109.36:51260] AH00132: file permissions deny server access: /usr/local/ispconfig/interface/acme/.well-known/acme-challenge/vKiU1AtGOhUTJkYzFEU6L1Og7RvBIyPbqThEvcxVctw And actually I was getting a 403. Once changed the permissions I could validate the site.
Hmm, strange. I use suexec in all sites and suexec should affect only requests to scripts, not requests to text like files that do not get interpreted.
IIUC, once Apache determines the requested host, it passes the request to the dedicated process for handling, even if it's just for a static file (else all static files would be accessible from every vhost just by adding an alias... a security nightmare: think "Alias /shadow.txt /etc/shadow" when allowing clients to add their own Apache directives...). By having vhost-specific processes, filesystem permissions are enforced.
Err... I'm at least partially wrong: static pages are served by processes owned by www-data user (not from SuExec user). That doesn't change the fact that LE generated files should be inaccessible unless from the ispconfig user since they're under directories owned by ispconfig:ispconfig that have o-x. So I can't understand how it's possible to validate any domain from LE... It works, but I'd really like to understand WHY!
Yes, that's what I mentioned in #10. The apache user is member of the ispconfig group and the ispconfig group has read permissions. If this won't be the case, then apache could not serve e.g. the css files and graphics of the ispconfig interface as these are always read by user and group apache and trough the same way, apache can read non-script files like the LE token.
Ugh! Right. Just checked on the secondary server (where the ispc interface should be disabled) and it seems OK: # grep ispc /etc/group ispconfig:x:1003:www-data The same on the primary server. Then how is it possible that it didn't work until I changed permissions? Anything else I could check? Might be a symptom of some other install problem?
