LetsEncrypt for Postfix Email Relay Configuration

TBH, I haven't played with Let's Encrypt certs with Postfix but I can't see why they wouldn't work?!

The Confconsole Let's Encrypt integration (for both v15.x & v16.x) updates and regenerates the certs/key that you can find here:

/usr/local/share/ca-certificates/cert.crt
/etc/ssl/private/cert.pem
/etc/ssl/private/cert.key

The cert.pem & cert.key files are used for Apache, Nginx, Lighty and/or Tomcat (i.e. all primary servers running on ports 80 & 443); as well as Stunnel (Webshell and Webmin). The crt file is not used anywhere in particular AFAIK, but I'm actually not sure.

v16.x introduced the ability to easily regenerate the DH parameters file (/etc/ssl/private/dhparams.pem) too. We've always been generating it on firstboot, but it defaults to an ok, but relatively low (1024) bitrate to make firstboot quicker. Regenerating with a higher bitrate is recommended (2048 is recommended) and will likely increase score on testers such as SSL Labs. You can do that via Confconsole >> Advanced >> System Settings >> Regenerate dhparams. Or via commandline like this:

turnkey-make-ssl-cert --dh-params-only --dh-bits 2048

The data from the DH parameters file (/etc/ssl/private/dhparams.pem) is also included in the cert.pem (as is the data from the cert.key as well). We do it like that so that a single set up "just works" across multiple different webservers that all seem to do things a little differently (some use separate individual files, others use a consolidated file; those that expect separate files ignore irrelevant data).

It appears that Postfix doesn't use "perfect forward secrecy" (what the DH params are used for) by default. So it's security could be improved by configuring that, although I've not played with it at all, so I'm not sure how that would go. FWIW you'll find a good starting point relevant to the v16.x compatible config via the Mozilla SSL Configuration Generator (the URL should have the right versions of Postfix and OpenSSL).

The cert/key that Postfix uses by default are /etc/ssl/certs/ssl-cert-snakeoil.pem & /etc/ssl/private/ssl-cert-snakeoil.key (set in /etc/postfix/main.cf and regenerated on firstboot). I had a quick peek at the defaults and on face value, it appears that just reconfiguring Postfix to use the cert.pem & cert.key in /etc/ssl/private would probably "just work"?!

I did try doing that (just our self signed cert; not a "proper" Let's Encrypt one) on a v16.0 server I happen to be working on ATM (but no other tweaks as suggested above) and restarted Postfix and it didn't cause any issues on face value. However, I have not properly tested it actually sending mail so can't comment at all on how effective it might be in reality! Having said that, I don't see any reason why it wouldn't work?!

Even if it's doesn't for some reason, I would imagine that creating/writing a postfix compatible cert via the dehydrated hook script should be fairly straight forward. FWIW the env vars used there are set within the Dehydarated wrapper.

In fact, if you can confirm that it works (improved Postfix config and/or certificate generation), then I think that we should look to add that into the Postfix setup and/or Let's Encrypt integration by default!

So let me know how you go and I'm more than happy to help out if you hit any issues. I certainly don't consider myself expert on Postfix (or certs or SSL even for that matter) but I have some basic knowledge and intimately know TurnKey ;)

As your probably aware, as per convention, Linux daemons tend to load config related stuff into memory at start time only; so restart is required to apply config changes. I would consider a certificate essentially a "config" file (at least for the purposes of my point), so I'd expect that a restart would be required to load new certificate data from the filesystem.

It doesn't really matter for the webserver (e.g. Apache), because the way we work around the different webservers (and their different config), is that we stop the webserver, and serve the ACME (Let's Encrypt protocol) challenge via a super simple custom http server. So the webserver needs to be (re)started as a matter of course. We also explicitly restart Stunnel.

If you wanted to also restart Postfix, then in theory that should be fairly straight forward, simply adding the required service(s) that need restarting to the relevant line. E.g. change this:

    restart_servers $WEBSERVER $STUNNEL

To something like this:

    restart_servers $WEBSERVER $STUNNEL postfix postfix@-

Although actually looking a bit closer, the "postfix" service actually appears to be a dummy service, "postfix@-" appears to be the proper service. I have no idea why it's like that. Although the '@' in the service name means that it's provided by a template (so there could potentially be multiple postfix services running from a single template). FWIW that's how I configured things to put Webmin and Webshell/shellinabox behind their own Stunnel instance. So with that in mind, it might be best to collect the name of any/all enabled services that start with "postfix" - as I do for stunnel (in the 2 lines just above the one the one I quoted above). I.e. something like this:

    POSTFIX=$(systemctl list-units --type=service --state=active \
        | grep postfix | cut -d' ' -f1)
    restart_servers $WEBSERVER $STUNNEL $POSTFIX

Hope that makes sense. Let me know how you go! It'd be awesome to add it in to the default set up. :)

Whilst I did answer the question I thought you were asking (and probably then some), I just noticed that I didn't actually explicitly answer the question you asked (at least not succinctly). So let me try again:

Can you clarify which TKLX appliance features from the following list currently get configured / reconfigured on a LetsEncrypt connection / renewal?

1. Apache - yes (and in other cases; Nginx, LigHTTPd and Tomcat too)
2. Webmin - no (bound to localhost via http; port 12321 is provided via stunnel)
3. Stunnel - yes (for both 12320 - Webshell/shellinabox & 12321 - Webmin)
4. Postfix - no