Server Ubuntu 16.04 Apache + ISPConfig 3.1.1p1 installed according to the Perfect Server tutorial perfect-server-ubuntu-16.04-with-apache-php-myqsl-pureftpd-bind-postfix-doveot-and-ispconfig I have a development server (see above) with FQDN like server2.example.com. I set up a website in ISPConfig for [www.]example.com and checked the SSL and Let's Encrypt checkboxes. This worked as expected: it installed an LE certificate package (.crt, .key, .bundle symlinks) for example.com and alternate name www.example.com, and the site works fine with https. I then created a 'Subdomain for website' – server2.example.com – and that hostname was automatically added to the original certificate, again as expected. So far, so good. I then created a 'Subdomain (Vhost)' – dev.example.com – and set up a website on it. This time LE created a new certificate package for dev.example.com, which was not what I expected, but the website seemed to work fine with https (showing the green padlock) so I assumed that this behaviour was by design. However, when I tested the domain with the Qualys SSL Server Test I found that the second certificate, for dev.example.com, was marked No SNI and produced two errors: Common names dev.example.com MISMATCH Trusted No NOT TRUSTED Everything else was the same as the first certificate, which showed no errors and was marked as TRUSTED. So, I have some questions: [1] Was the creation of a second certificate for the Vhost subdomain correct, or is it a bug? [2] Given that the dev.example.com website seems to be working fine, and the certificate is accepted, should I worry about the errors detected by the SSL Server Test? [3] Is there any way within ISPConfig of telling Let's Encrypt in advance, i.e. before creating the main domain certificate, what subdomains I will need, so that they can all be included in the certificate? Thanks in advance for your help.
It sounds like what I'd expect. When you create a vhost with its own website, it's going to have it's own VirtualHost config, pointing to the corresponding certificate/key files. Maybe features/design could be discussed for improvement, but you should end up with 2 vhosts, pointing to 2 separate ssl certificates, the first one having multiple subject alternative names, but ssl should work fine everywhere. Given it's "just your dev site" I wouldn't worry about it, but it is curious. Manual inspection of the certificate in your browser looks good? I actually have a similar scenario here (ssl site (comodo, not letsencrypt) with a dev vhost added), I'm enabling letsencrypt for dev subdomain now and will see what happens. Not really, as you add names it will push a job in the queue to request/update the certificate with new names, and that job queue is run once per minute. You could disable the cronjob and add all the names, then re-enable, and it might do the trick - but probably not worth the hassle unless you're hitting letsencrypt request limits.
My first attempt failed because I had the default Auto-subdomain: www set for my dev vhost (you'll see an error in /var/log/letsencrypt/letsencrypt.log about a DNS problem for www.dev.domain.tld). At that point, my https test showed the wrong certificate (server's default ssl site) and the wrong webpage (again default ssl site), as when letsencrypt failed, the port 443 vhost was never created. I changed the Auto-subdomain setting, enabled letsencrypt again, and all problems cleared up. The certificate that was created had CN=dev.domain.tld and SAN of dev.domain.tld only.
My certificate shows as valid and trusted when checked at https://www.ssllabs.com/ssltest/analyze.html?d=dev.domain.tld, the errors I quoted earlier only appear when it's the second certificate on checking https://www.ssllabs.com/ssltest/analyze.html?d=domain.tld. Weird!
Thanks for your full and very helpful reply. I wonder why it's necessary to create a separate certificate for the vhost subdomain. What would the problem be in adding dev.domain.tld to the main certificate and having the vhost config pointing to the main certificate? If it works, that would be a neater solution – only one certificate to maintain and renew, rather than two or more.
philgardner: it would help to actually know the real domain name in question to check out the ssl info and stuff.. a new vhost is a complete new config set. Also, LE certs are limited to 100 fqdn per certs. If you enable auto-www everywhere (and have according dns entries as well), you can "only" get 50 domains in a cert. Also you could have different needs. E.g. use 4096bit RSA on one vhost, EC-256 on a different vhost.... (not that ISPC does that this far).
I think you may have misunderstood me. I'm not suggesting putting large numbers of domains and subdomains on one certificate, even though that's theoretically possible within the 100 limit. Merely putting one domain and all its subdomains (probably fewer than ten subdomains typically) on one certificate, even if some of the subdomains have their own vhost config. I might experiment with that and see if it works without problems.
If you create a seperate vhost in ISPC, whats in your opinion wrong to have seperated ssl certs for that vhost? I see no benefit having all subdomains - if they are on seperate vhosts - in the same certs.
I'm not saying there's anything wrong with it, I just don't see the need for separate certificates. It seems to me to be simpler and neater to have one certificate per domain, but I suppose it's not important.
different vhosts - each vhost has its own settings for everything incl. ssl certs... I think that's much simpler and neater and having ssl certs spanning multiple vhosts.
Also you could have the separate vhosts on different web servers, which wouldn't be supported by the combined approach without a lot of extra (needless) back-end logic.
