Securing back end with Let's Encrypt - multiple aliases [Previously: StartSSL query]

Hi All,

-original post edited following Jesse Norell's advice below-

New question ( ):

I've used Let's Encrypt in the ISPConfig GUI to secure web vhosts, but never to secure the ISPConfig back end (the ISPConfig web interface, mail, FTP, etc.).

Previously, I had an SSL certificate with multiple hostnames; which meant the certificate I used to secure the ISPConfig web interface (found at alpha.domain.tld) was also valid when mail/FTP/etc. clients connected via other aliases; it was also possible to secure the domain's main website by entering the certificate details in the ISPConfig panel.

Is it possible for me to similarly secure multiple aliases for the back end systems using Let's Encrypt? I appreciate that I'll likely have to generate multiple certificates rather than having multiple hostnames in one certificate, but I'm not sure whether that's possible or how I'd go about it without upsetting the Let's Encrypt integration for sites hosted within ISPConfig.

I'd be most grateful if someone could point me in the right direction!

Many thanks,

Rob.

 

Ah. I didn't realised they'd dropped off the trusted list. Thanks for the heads-up.

[I'll change the thread title reflecting this tangent...]

Is there any advice documentation for implementing Let's Encrypt on the back-end (ISPConfig vhost, mail, ftp etc.)?

The reason I had been using StartSSL was that I could put 10 hostnames in the certificate, which meant it was pretty straightforward to secure all the services on one machine, despite using different aliases for them.

[My main server is alpha.domain.tld, but mail clients connect with mail.domain.tld, ftp to ftp.domain, etc.]

Thanks again,

Rob.

 

That's brilliant, thanks for your help.

The sticky thread looks a good start, and I'll try to track down @sjau's script (which sounds like just the thing I need).

Thanks again and best regards,

Rob.

 

I guess this is the script you were referring to? As you say, it's from a while ago so probably not a great deal of use today, but it was certainly worth studying for clues

I've been looking at @ahrasis excellent guide, and I'm almost tempted to follow it to the letter, just always using alpha.domain.tld to connect (instead of having mail, ftp, etc. aliases) because it'd be uncluttered, and reliably managed by ISPConfig (of course with the addition of the trick cron job to remake the FTP key (which I like a lot!)); but I find myself drawn to possible alternatives whereby I could use aliases.

If I've understood correctly...

i) I could adapt ahrasis' guide by making (web)sites for each of the aliases I'd like to use, enabling Let's Encrypt on each, and symlinking services to the corresponding vhost's certificate in certbot's folders; adding the cron job to make the FTP key from the relevant vhost certificate.

ii) I could make a single (web)site for domain.tld [which I would do anyway to host a basic homepage], but instead of enabling Let's Encrypt in the ISPConfig panel, I could run certbot in webroot mode, pointing at the vhost location to create the verification files, and adding aliases (subdomains) to be included in that certificate.

In determining which way to go, I find myself mainly concerned about renewal. Of course in the first example, everything's managed by ISPConfig (with the exception of the FTP key script) so it should renew as any other hosted site would, but if I can, I'd rather avoid having vhosts configured which I don't need (and having to put 'nothing here'/redirects in place).

Would I be right in thinking that if I used method (ii), the certificate would be renewed along with any other Let's Encrypt certificates which might be set in the ISPConfig interface? That is to say, is there a scheduled renewal which ISPConfig routinely performs that would at the same time renew the certificate I'd manually generated? (Or would I need to add a separate cron job for certbot to ensure it renewed?)

Thanks again for any advice you can offer!

Rob.

 

Thanks again for your reply. I'm sure you'll be relieved to hear I think I've got my head around it enough to be forming something like a plan (I hope!)..

If I follow you correctly, the first part of your reply says that if I define a site for domain.tld in the ISPConfig panel, then in the 'subdomain for website' page, I add the aliases I'd like to use (where it's also nice & simple to set-up web redirects to domain.tld) - alpha.domain.tld, mail.domain.tld, ftp.domain.tld, etc. - I can then just enable Let's Encrypt in the panel for domain.tld, and the defined subdomains will be included in the certificate?

If so, it's back to having extraneous web 'sites', but if it can all be panel-managed - particularly proper redirects, it's no hardship.

Done that way, all that would be remaining for me to do 'by hand' would be symlinking the certificate to services, and adding the FTP script either to cron, or by appending to le.restart? (I haven't had a nosey at that one yet - is it as straightforward as the name suggests?)

Sincerest thanks again,

Rob.

 

Magic. I think this way definitely makes the most sense for simplicity of management. I'll give it a go this way.

Thanks for that; I'll give it some study.

Thanks very much for all your kind help.

Rob.

 

Btw, if you use ISPConfig also as DNS host, I do prefer now (for things outside the ISPC Interface) do use acme.sh as client. The reason is that it can use ISPC DNS API and use the DNS-01 Auth for Let's encrypt.

That allows you to request certs for (sub)domains where there is no webinterface running. E.g. ftp.domain.tld

It takes a bit longer to request a cert, because in the plugin for ispc I added a timeout of 2 minutes after altering the DNS record before the LE servers get to check.

Have a look here: https://www.howtoforge.com/communit...utomated-dns-01-challenge-for-ispc-3-1.74850/

 

Well, I've made *some* progress...

Having settled the plan, and noticed that 3.1.4 became current yesterday, I restored the image I'd [handily] made after resolving dependencies but before running the install; and set-up the basics again; including a site for domain.tld, and subdomains for services in the ISPC panel. I stuck in a quick PHP index page, and set 301s in the ISPC panel; the page appears and subdomain redirects all work.

I saved another image (it'd be rude not to!), and enabled Let's Encrypt for the site in the ISPC panel. Unfortunately, when browsing to https://domain.tld I just get SSL_ERROR_RX_RECORD_TOO_LONG - which I believe in a world of vhosts is just a red herring for no certificate offered - a theory which seems to be confirmed by requesting the certificate from Firefox's advanced options - it reports that the site doesn't offer identity information.

Scratching my head, I checked letsencrypt.log, and I can see that it's generating certificates (verified by browsing the directory); I noticed a 'silver lining', too - I can see successful DNS validations for the subdomains in the certificate generation process - it just seems that for some reason they're not being configured to the site once generated.

I'd be very(!) grateful for any suggestions regarding where I might look for clues to what's going wrong. (FWIW: netstat -anp | grep apache confirms the server is listening on 443 (and 80, 8080, 8081))

Also, I looked at the le.restart thing in 900-letsencrypt.inc.php, and unless I'm mistaken (entirely possible) that's not so much a fired-script, but a flag for delayed service restart? It appears there's a function below which can be used to execute stuff after renewal, but at a glance I'm not sure whether it'll just run whatever's entered there, or if there's further editing required elsewhere (in parent function(s)) to make it fire. Again, I may have misunderstood, but it's probably marginally simpler/more reliable to amend the 'certbot renew' command with a --renew-hook shell script. Actually, while I'm only conerned about one pureftpd instance, I'll probably just go with the incron method.

@sjau Thanks for the link; I hadn't seen that script. I can see that may well become useful if [when] I start populating other domains - downloaded and added to bookmarks - For now, my ambitions are more modest - I'll be happy if I can get the Let's Encrypt certificate I've generated to be served.
P.S. I particularly enjoyed 'vanity certificates' in that post - rolled my eyes at myself (though I suspect I'd be no better off if I was just trying to use alpha.domain.tld for everything)

Thanks and regards,

Rob.

 

well, acme.ssh isn't integrated in ISPC. You can use it instead of interagted LE support but you'd first need to activate the SSL check box and then just create random certs, so the files will be stored. Then acme.sh can be used to request certs and copy them to the proper location afterwards.

 

Indeed; I'll probably use that when I put some other domains (which have more useful subdomains) in the set-up.

For now I'd like to get the built-in functionality working (I've had it working in the past) - at the moment even for a simple site Let's Encrypt certificates aren't being served

...I just added another site - anotherdomain.tld, no subdomains, nothing fancy - waited for processing bubble to disappear, checked the letsencrypt.log (sucess), but the same error at https://anotherdomain.tld - have I missed something obvious/simple/stupid?

Thanks and regards,

Rob.

EDIT: I had a bit of a brain-wave...

I wondered if my configuration was causing a conflict between a subdomain and the server's FQDN.

What I had set:

Server FQDN: alpha.domain.tld
ISPConfig Site: domain.tld, hosted on server alpha.domain.tld
Subdomains (to be included in certificate):
alpha.
mail.
ftp.

It seems to work, until SSL is enabled.
If I remove the alpha subdomain from the ISPC panel, https://domain.tld suddenly starts working.

I imagine that if I study how to use @sjau's acme.sh method, that's the way to get around it (having all the hostnames in the certificate and only having websites enabled which are actually required).

I suppose it might work if I were to configure alpha.domain.tld as a site on its own, and separately configure domain.tld with the mail. and ftp. subdomains. Maybe I could configure the vanity hosts as aliases (rather than subdomains) of site alpha.domain.tld; and just run domain.tld as I would any other site? Anyway, I think it starts to get a bit messy this way. I think it's time to study @sjau's acme.sh!

Rob.

 

if you add an alias in ISPC to a site, it should get included in letsencrypt. Also, you need to add according entry to the dns zone file.

The advantage of DNS-01 is that you prove you have control over the dns zone file. If you are in control over the dns zone file, you can route a domain to whatever machine you want and hence request and subdomain for a domain without it needing to be accessible from the internet. And acme.sh has a dns-01 plugin for ispc which makes it easy to use.

 

Well, there were yet more twists in the tale...

When I last posted, I'd found my SSL error at https://domain.tld to be caused by alpha.domain.tld being defined as a subdomain (this is also the FQDN of the main ISPConfig server). Before I could use the DNS authentication in acme.sh to sort out the alias certificates separately I had to wait for DNS propagation (I'd been using the registrar's nameservers while fiddling with my own servers); so I decided to 'play' with some of the alternative combinations of sites & sub/alias domains in the panel.

Cutting a long story short, I did find one mix which while not perfect, was functionally OK - in so far as I was able to access https://domain.tld without error; the odd part was that the system didn't seem to differentiate between that and the separate site for alpha.domain.tld (and aliases) - I'd put up a PHP index page for domain.tld, and left the default html page in place for alpha.domain.tld - in the browser, I saw the PHP index page for both URLs. As I was going to use redirects anyway I was tempted to leave it like that; but because I'd set it all up before browsing certbot's archive to find the certificate I'd symlink to services I now had several similarly named folders (domain.tld, domain.tld-001, etc.) and it seemed like the quickest way to deal with that would be to restore my last image, checking the certbot folders between each step of adding sites in the ISPConfig panel.

I now find myself in the very confusing situation that I can't get the Let's Encrypt integration to work for any site, at all. My most recent attempt was to configure only one site for anotherdomain.tld, with nothing at all configured for domain.tld or alpha.domain.tld (having restored an image taken before any sites had been configured) - http works fine, but https gives SSL_ERROR_RX_RECORD_TOO_LONG.
[ISPConfig admin panel continues to work via https:8080 with self-signed certificate.]

letsencrypt.log shows that the certificates are being generated without error; but I'm back to them not being offered by apache. I have a grasp of the [very basic] basics, but I'm not an apache expert - I'd be grateful if someone could advise where I can check the sites as configured by ISPConfig. Should I expect to see SSL configuration in the site.vhost files? [I'm not sure how the magic which juggles certificates for vhosts happens.]

I'm going to do a complete rebuild to make sure I'm not restoring images with something broken in them, and I'll save a new image after resolving dependencies so I can check with 3.1.3 & 3.1.4 if it comes to it, but I can't see that being the problem; so if it's not something in 'my' part of the image, I'm going to be pretty stumped(!) - so any advice will be most gratefully received!

Best regards,

Rob.

P.S. The one bit of good news is that my nameserver updates have propagated now, so when [if?] I do get LE working again, I can get straight on with acme.sh for the panel/alias certificates

 

As for websites and getting LE through ISPC, I'd do:
1. remove SSL from all websites
2. Wipe the /etc/letsencrypt folder
3. Run certbot manually but let it not do anything - just let it recreate folders etc
4. enable LE from ISPC again for each website

With the -0001 it means the hostnames contained previously in the cert has changes. so it will create additional folders. Not sure how ISPC handles those. Thats why I'd start over again

 

Thanks for your reply. I've committed that refresh method to memory, but I'd decided to start from scratch again, hopefully to ensure I catch whatever the problem is. I did a fresh install, and I've added a handful of DNS zones (and email routing), but so far haven't defined any websites.

My main server is alpha.serverdomain.tld (which has ISPConfig and services), and I'll also have bravo.serverdomain.tld (which will just be secondary DNS).

For serverdomain.tld:

serverdomain.tld is set on alpha (IP .161), and there are A records configured for:
alpha.serverdomain.tld (.161)
bravo... (.162)
ftp... (.161)
mail... (.161)
ns1... (.161)
ns2... (.162)
www. (.161)

I only 'need' a website at [www.]serverdomain.tld, so my initial thinking was that I only need to define that site in the ISPConfig panel; but I notice that with nothing configured for alpha.serverdomain.tld, it shows the Debian/Apache 'It works!' page, so I'd like to do something to 'tidy up' that URL.​

What is best practice under these circumstances? Define serverdomain.tld as the site, and then alpha.serverdomain.tld as a subdomain? (This seems most logical, but when LE was working for me, it wouldn't work like this) - Or is there some preferred way? (Perhaps both as separate sites perhaps, or making use of alias domains, using a filesystem method to redirect the default site?)

Thanks again for any clarification you may be able to offer, and best regards,

Rob.

 

the server hostname is currently alpha.serverdomain.tld .... in ISPC you need now to create a website for serverdomain.tld incl. auto www subdir.

Serverhostname and Website are different things.