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

Discussion in 'Installation/Configuration' started by FactionOne, Jun 20, 2017.

  1. FactionOne

    FactionOne Member

    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,

    Last edited: Jun 20, 2017
  2. Jesse Norell

    Jesse Norell Well-Known Member

    FactionOne likes this.
  3. FactionOne

    FactionOne Member

    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,

  4. Jesse Norell

    Jesse Norell Well-Known Member

    There are a lot of posts/info here in the forums on it. This post is pinned to the top of the tips & tricks forum: and I've posted a few (one on mail server, I think one for the control panel and maybe ftp), and @sjau posted a script to handle the request with hard-coded list of servernames to include. Some folks like to create website domains/aliases within ispconfig and just click the "Let's Encrypt" checkbox to get the certificates setup, but you may prefer to just come up with your own list and request the certificate manually.

    I believe letsencrypt allows 100 names in each cert.
    FactionOne likes this.
  5. FactionOne

    FactionOne Member

    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,

  6. Jesse Norell

    Jesse Norell Well-Known Member

    iirc, @sjau's script would be in some of the earliest forum posts on letsencrypt, possibly with ispconfig version 3.0 (before it had native letsencrypt support). If you request the certificate manually once with all names included, it will get renewed the same way - all you have to handle at that point is rebuilding the ftpd cert file and restarting services.
  7. FactionOne

    FactionOne Member

    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!

  8. Jesse Norell

    Jesse Norell Well-Known Member

    If you're creating a website in ispconfig and adding aliases as additional names (which will all be included in the certificate), just enable the checkbox and let ispconfig request the certificate. If you do request a certificate manually, you do use webroot mode, but you don't point at the vhost location for the files, you need to point at /usr/local/ispconfig/interface/acme (ispconfig's webserver config will point all verification requests under there). Eg. here is the exact command that ISPConfig 3.1.2 uses:
    # grep acme /usr/local/ispconfig/server/plugins-available/
                        $success = $this->_exec($letsencrypt . " certonly -n --text --agree-tos --expand --authenticator webroot --server --rsa-key-size 4096 --email postmaster@$domain --domains $lddomain --webroot-path /usr/local/ispconfig/interface/acme");
    Yes, /usr/local/ispconfig/server/lib/classes/cron.d/ runs 'certbot -n renew' which will check all certificates to see if they need renewed, so your manual request will be handled with all the others.

    On a related note, it looks like that cronjob now has a hook to run /usr/local/ispconfig/server/le.restart on restart, so you should be able to use that to recreate your pure-ftpd cert file (which will get done for every certificate the server renews, not just the one it needs, but is probably harmless).
    FactionOne likes this.
  9. FactionOne

    FactionOne Member

    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,

  10. Jesse Norell

    Jesse Norell Well-Known Member

    Yes, that sounds correct. Make sure your DNS is setup and pointing to your server for each of those subdomains or the certificate request will fail (you can just setup some names now and add others later on - it will request a new certificate including all the names).


    The file does not exist by default, and it is called vi certbot '--post-hook' - looks like a simple shell script (well tested :) should do it - see
    FactionOne likes this.
  11. FactionOne

    FactionOne Member

    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.

  12. sjau

    sjau Local Meanie Moderator

    Btw, if you use ISPConfig also as DNS host, I do prefer now (for things outside the ISPC Interface) do use 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:
    FactionOne likes this.
  13. FactionOne

    FactionOne Member

    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, 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,

  14. sjau

    sjau Local Meanie Moderator

    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 can be used to request certs and copy them to the proper location afterwards.
    FactionOne likes this.
  15. FactionOne

    FactionOne Member

    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,


    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):

    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 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!

    Last edited: Jun 21, 2017
  16. sjau

    sjau Local Meanie Moderator

    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 has a dns-01 plugin for ispc which makes it easy to use.
    FactionOne likes this.
  17. FactionOne

    FactionOne Member

    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 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,


    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 for the panel/alias certificates :)
    Last edited: Jun 23, 2017
  18. sjau

    sjau Local Meanie Moderator

    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 :)
    FactionOne likes this.
  19. FactionOne

    FactionOne Member

    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,

  20. sjau

    sjau Local Meanie Moderator

    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.
    FactionOne likes this.

Share This Page