![]() 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. It doesn't really matter for the webserver (e.g. 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. 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 )Īs 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. So let me know how you go and I'm more than happy to help out if you hit any issues. 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! FWIW the env vars used there are set within the Dehydarated wrapper. ![]() 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?!Įven 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. 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. 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"?! 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). 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). 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. It appears that Postfix doesn't use "perfect forward secrecy" (what the DH params are used for) by default. 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). 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). Or via commandline like this: turnkey-make-ssl-cert -dh-params-only -dh-bits 2048 You can do that via Confconsole > Advanced > System Settings > Regenerate dhparams. Regenerating with a higher bitrate is recommended (2048 is recommended) and will likely increase score on testers such as SSL Labs. We've always been generating it on firstboot, but it defaults to an ok, but relatively low (1024) bitrate to make firstboot quicker. V16.x introduced the ability to easily regenerate the DH parameters file (/etc/ssl/private/dhparams.pem) too. The crt file is not used anywhere in particular AFAIK, but I'm actually not sure. all primary servers running on ports 80 & 443) as well as Stunnel (Webshell and Webmin). The cert.pem & cert.key files are used for Apache, Nginx, Lighty and/or Tomcat (i.e. usr/local/share/ca-certificates/cert.crt The Confconsole Let's Encrypt integration (for both v15.x & v16.x) updates and regenerates the certs/key that you can find here: TBH, I haven't played with Let's Encrypt certs with Postfix but I can't see why they wouldn't work?!
0 Comments
Leave a Reply. |