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-security.html

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

Reply via email to