dovecot - Aug 2017 - is a self signed certificate always invalid the first time?

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

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

I then have the option of trusting it.

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

Thank you.

AV> So i?m using dovecot, and i created a self signed certificate
AV> with mkcert.sh based on dovecot-openssl.cnf. The name in there matches 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 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

On 09.08.2017 17:20, Alef Veld wrote:
> So i?m using dovecot, and i created a self signed certificate with
> mkcert.sh based on dovecot-openssl.cnf. The name in there matches my
> mail server.
>
> The first time it connects in mac mail however, it says the certificate
> is invalid and another server might pretend to be me etc.
This is to be expected for self-signed certificates. The MUA (Apple Mail
in your case) cannot know that the certificate is trusted until you
confirm it.

For certificates signed by third parties, the client (or OS) performs
the same checks. If a chain of trust can be established based on the
client/OS certificate store, which comes pre-populated with well-known
third party CA certificates, allowing to verify certificate signatures,
your MUA will trust the presented certificate without you confirming it.

I recommend you look into using a free Let's Encrypt certificate (see
https://letsencrypt.org/) instead of a self-signed certificate.

-Ralph

Thanks Greg, that makes total sense.
Appreciate your reply.

On 9 Aug 2017, at 16:39, Gregory Sloop <gregs at sloop.net<mailto:gregs at
sloop.net>> wrote:




AV> So i?m using dovecot, and i created a self signed certificate
AV> with mkcert.sh based on dovecot-openssl.cnf. The name in there matches 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 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

Thanks Ralph, i?ll look into that.

I think let?s encrypt uses certbot though and it can?t do email certificates
(although i?m sure i can convert the cert i get from let?s encrypt, i?ll look
into it.
> On 9 Aug 2017, at 16:40, Ralph Seichter <m16+dovecot at
monksofcool.net> wrote:
> 
> On 09.08.2017 17:20, Alef Veld wrote:
> 
>> So i?m using dovecot, and i created a self signed certificate with
>> mkcert.sh based on dovecot-openssl.cnf. The name in there matches my
>> mail server.
>> 
>> The first time it connects in mac mail however, it says the certificate
>> is invalid and another server might pretend to be me etc.
> 
> This is to be expected for self-signed certificates. The MUA (Apple Mail
> in your case) cannot know that the certificate is trusted until you
> confirm it.
> 
> For certificates signed by third parties, the client (or OS) performs
> the same checks. If a chain of trust can be established based on the
> client/OS certificate store, which comes pre-populated with well-known
> third party CA certificates, allowing to verify certificate signatures,
> your MUA will trust the presented certificate without you confirming it.
> 
> I recommend you look into using a free Let's Encrypt certificate (see
> https://letsencrypt.org/) instead of a self-signed certificate.
> 
> -Ralph

On Wed, 9 Aug 2017 08:39:30 -0700
Gregory Sloop <gregs at sloop.net> wrote:
> AV> So i?m using dovecot, and i created a self signed certificate
> AV> with mkcert.sh 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
This was exactly the global thinking - until the day DigiNotar fell.
Since that day everybody should be aware that the true problem of a
certificate is not its issuer, but the "trusted" third party CA.
This could have been known way before of course by simply thinking about the
basics. Do you really think your certificate gets more trustworthy because
some guys from South Africa (just an example) say it is correct, running a
_business_? Honestly, that is just naive.
It would be far better to use a self-signed certificate that can be checked
through some instance/host set inside your domain. Because only then the only
one being responsible and trustworthy is yourself. And that is the way it
should be.
Everything else involving third party business is just bogus.

-- 
Regards,
Stephan