> On Jan 21, 2018, at 3:26 PM, Danny Horne <da...@trisect.uk> wrote: > > Apologies if this has been discussed before, but currently I use > self-signed certificates on my Postfix servers for TLS negotiation, I'm > doing this mainly to keep the costs down.
The current cost of TLS certificates that chain up to broadly trusted CAs is $0. For example, from Let's Encrypt. So cost should not be your primary motivation. But read on, ... > As far as I'm aware I don't have any problems sending/receiving > email to/from the major providers, but could that change in the > future? Could the likes of Google start insisting on a chain of > trust for mail delivery? This is rather unlikely in the near term. No standards exist for meaningful use of client certificates to authenticate MTA-to-MTA email transport. So certainly you won't need a CA issued cert to send email, indeed most SMTP servers don't ask for your TLS client certificate even if you're careless enough to configure one. It is possible that at some time in the future (at least 5 or more years out) valid certificate chains might be need to receive email, but there no indication that this is looming. > I see wildcard SSL certificates are coming down in price, I use > SSL on one or two websites and am starting to consider one of these > to cover everything I do. Am I right in assuming a standard wildcard > SSL certificate will be usable on both web and email servers? You *really* should AVOID wildcard certificates, they are a magnet for both security and operational issues. Get a distinct self-signed or free CA certificate for each server. Space out certificate rotation in time for the different servers that provide redundancy for each service so as to avoid a single point of failure when certificate rotation is accidentally mishandled. Finally, for SMTP, your best security gambit is DANE, and here self-signed certificates are just as good or better than CA issued certificates. You're far less likely to mess up certificate rotation when doing it yourself than when integrating certbot and forgetting to care to pre-stage DNS TLSA record updates (3 1 1) before obtaining a new cert for the underlying public key. See: http://www.postfix.org/TLS_README.html#client_tls_limits http://postfix.1071664.n5.nabble.com/WoSign-StartCom-CA-in-the-news-td86436.html#a86444 https://www.ietf.org/mail-archive/web/uta/current/msg01498.html https://community.letsencrypt.org/t/new-certbot-client-and-csr-option/15766 https://www.internetsociety.org/deploy360/blog/2016/03/lets-encrypt-certificates-for-mail-servers-and-dane-part-2-of-2/ https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022 http://tools.ietf.org/html/rfc7671#section-8.1 http://tools.ietf.org/html/rfc7671#section-8.4 -- Viktor.
