Comment by shakow 2 days ago
There is no security hole if I am singing my own certificate for my own mails on my own server; it would mean that I do not trust... myself?
Now if I were to provide this as a commercial service, sure, my customers may be worried.
> Most people would click trust and get MITM'ed
So accept self signed on first connection with a detailed panel showing the certificate fingerprint. Then after that require a more involved process to accept a new certificate.
> do you really maintain every certificate both on it's application and on everything which needs to connect to it?
These are client certificates, and in some cases, they're actually pretty awesome.
> than signing all your PKI with an internal CA
That's a single layer of abstraction away from a self signed certificate, because, your CA _is_ a self signed certificate in this scenario. You've taken any defense in depth and thrown it right out the window.
The purpose of software is to make things possible not enforce random pedantry.
>"This is good enough because I don't expect anyone other than me will use it" is lazy
is both a mischaracterisation of the argument, and wrong. It's not lazy, it's a choice with pros and cons. Just because you don't like it does not mean it is lazy. Again, issuing your own certificates is a choice.
Allowing self signed certificates does not "significant lower the bar". Did you know that all root certificates are self signed?
The management of multiple trusted certificates is basic administration for large private networks. Yes, TLS and certificate management can be complex, but that is not a good argument for disallowing it, and the idea that managing your own certificate trust is against "best practices" is ludicrous.
Why would this oblige the client to trust any self-signed cert as opposed to trusting all certificates whose chain of trust can be established using the system's trust store? The reporter isn't asking for mail to automatically trust untrusted certificates, they have added them to the trust store.
Please keep in mind that a self-signed certificate is quite different from a certificate that is signed using a private CA.
The self-signed certificate has no link to a trust anchor. So it’s easy for Mallory to replace it with her own malicious certificate. It’s much harder for Mallory to replace a certificate that is tied to a CA.
"This is good enough because I don't expect anyone other than me will use it" is lazy
What would happen if you connected to your mail client today and you got prompted "Trust this certificate?" showing a certificate with the same subject as the one you generated? Most people would click trust and get MITM'ed
Allowing self signed certificates significantly lowers the bar when it comes to generating a new certificate which can closely resemble an existing certificate
Beyond that, the management of multiple trusted certificates creates all sorts of room for confusion in an environment. Presumably most services that you run, run over TLS, do you really maintain every certificate both on it's application and on everything which needs to connect to it? That's a huge amount more effort than signing all your PKI with an internal CA, the configuring your connecting applications to trust that CA