SvK> On Wed, 9 Aug 2017 08:39:30 -0700
SvK> Gregory Sloop <> wrote:

>> AV> So i’m using dovecot, and i created a self signed certificate
>> AV> with based on dovecot-openssl.cnf. The name in there matches
>> AV> my mail server.  

>> AV> The first time it connects in mac mail however, it says the
>> AV> certificate is invalid and another server might pretend to be me etc.  

>> AV> I then have the option of trusting it.  

>> AV> Is this normal behaviour? Will it always be invalid if it’s not signed
>> AV> by a third party?  

>> Yes.
>> The point of a trusted CA signing your cert is that they have steps to
>> "verify" who you are and that you're "authorized" to issue certs for the
>> listed FQDNs. Without that, ANYONE could create a cert, and sign it and then
>> present it to people connecting to your mail server [perhaps using a MITM
>> style attack.] The connecting party would have no way to tell if your cert
>> vs the attackers cert was actually valid.

>> It would be like showing up at the bank and having this exchange: 

>> You: "Hey, I'm Jim Bob - can I take money out of his account?"
>> Bank: "Do you have some ID?"
>> You: "Yeah! See, I have this plastic card with my picture and name, that I
>> ginned up in the basement."

>> Now does the bank say: "Yeah, that looks fine." or do they say "You know we
>> really need ID [a certificate] that's authenticated and issued [signed] by
>> the state [third-party/trusted CA.]."

>> I think it's obvious that accepting your basement produced ID would be a
>> problem. [Even if we also admit that while the state issued ID (or trusted
>> CA signed certs) has some additional value, it isn't without potential
>> flaws, etc.]

>> The alternative would be to add your CA cert [the one you signed the server
>> cert with] to all the connecting clients as a trusted CA. This way your self
>> signed cert would now be "trusted."

>> [The details are left as an exercise to the reader. Google is your friend.] 

>> -Greg

SvK> This was exactly the global thinking - until the day DigiNotar fell.
SvK> Since that day everybody should be aware that the true problem of a
SvK> certificate is not its issuer, but the "trusted" third party CA.
SvK> This could have been known way before of course by simply thinking about 
SvK> basics. Do you really think your certificate gets more trustworthy because
SvK> some guys from South Africa (just an example) say it is correct, running a
SvK> _business_? Honestly, that is just naive.
SvK> It would be far better to use a self-signed certificate that can be checked
SvK> through some instance/host set inside your domain. Because only then the 
SvK> one being responsible and trustworthy is yourself. And that is the way it
SvK> should be.
SvK> Everything else involving third party business is just bogus.

I'm really not interested in hashing out this argument - it's endless [we might 
as well discuss religion or politics too, while we're at it] - but I will 
address a couple of points.

1) You'll note that I *specifically* noted "[Even if we also admit that while 
the state issued ID (or trusted
CA signed certs) has some additional value, it isn't without potential flaws, 

Clearly there *are* issues with trusted CA's. But they also offer some value 
you can't get with a self-signed cert - especially to people who would connect 
to your servers, but who have no real relationship with you and thus no reason 
to have any trust for you or your certificates. 

2) Certificate revocation is a another very tricky situation where a self 
signed certificate system struggles.

So, in summary: the trusted CA's and their certificate "authentication" have 
some problems [perhaps more than some] - but also offer some benefits in spite 
of those problems. IMO, it's incredibly naive to say "would be far better to 
use a self-signed certificate..." - sure there might be some areas where it's 
better, but many others where it's not. It's not an "all good" or "all bad" 
kind of thing. As they say - the only secure computer is one encased in 
concrete at at the bottom of the deepest ocean trench, unpluged and unconnected 
- and even then I'm not completely sure. 

Everything in life and security is a trade off of one set of factors against 


Reply via email to