On 10.08.2017 09:18, Stephan von Krawczynski wrote:
It would be far better to use a self-signed certificate that can be checked through some instance/host set inside your domain.
I have been running a CA for 15+ years, generating certificates only for servers I personally maintain. Since my business is too small to be able to afford all the steps required to have my CA trusted by Mozilla, Apple etc., this approach leaves me with the same problem self-signed certs have: How can I make third party applications like web browsers or MUAs trust the certs I created?
For some of my customers, I can add my CA certs (root and intermediary) to their keystores, so the end user does not see a thing. For other customers, I can hand over cert fingerprints so end users can manually accept the connections after checking the fingerprint (guess how many users actually do that).
Naturally, this does not work for publicly available services, where there is currently no alternative to using well-known CAs. Of course their certs are not technically better than my own CA's or than self- signed certs, and their processes are sometimes garbage, the fuckups of Symantec being case in point. Symantec even just sold off their whole CA business to DigiCert; it seems they never really recovered from generating fake google.com certificates two years ago:
https://security.googleblog.com/2015/09/improved-digital-certificate-securit...
To get back on topic: if the OP can live with self-signed certs, that's perfectly fine. If Alef needs people to be able to connect to his Dovecot server without verifying/confirming the certificate, a CA like Let's Encrypt is a better choice. As far as Postfix is concerned, there is hardly any reason to use a well-known CA, because opportunistic TLS for SMTP does not care about trust chains.
-Ralph