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

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

I completely agree (having said that I'm pretty new to all this so I might
be full of it).

You should run your own CA if you have an active financial interest in your
company (say your the owner). No added benefit to have your certificate
certified by a third party, why would they care about that one client). Ofcourse
people would say "but ofcourse you would verify your own certificate"
but in that case they probably don't understand how it all works.

Ofcourse once your own company grows large you run the same risk of entropy
(incorrect documentation or records, no trained staff, no up to date procedures
etc.) large companies have to deal with. Maybe if you had one person working
full time on it, or an automated process handling things it would be more secure
and reliable.

Was diginotar the Dutch company, I think I remember that one.

Sent from my iPhone
> On 10 Aug 2017, at 08:18, Stephan von Krawczynski <skraw at
ithnet.com> wrote:
> 
> 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
>

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

I just need my internal users to download their mail, right now it's not
something I'm terribly worried about. I'm just glad I got it all working
so far :-)

Once I do my apache to SSL as well I'll probably get paid certificates or
one letsencrypt certificate for all.

Sent from my iPhone
> On 10 Aug 2017, at 12:43, Ralph Seichter <m16+dovecot at
monksofcool.net> wrote:
> 
>> 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

SvK> On Wed, 9 Aug 2017 08:39:30 -0700
SvK> 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
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
the
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
only
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, etc.]"

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
another.

Cheers!
-Greg

On Thu, 10 Aug 2017 07:53:16 -0700
Gregory Sloop <gregs at sloop.net> wrote:
> [...]
> 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. [...] Cheers!
-Greg
Let me drop all the rest and concentrate on this idea of yours.
You really do mean that someone not trusting the issuer of some web site is
_protected_ iff this very web uses a certificate from a trusted CA? How should
that work out?
If someone does not trust me or my certificate he should not use my web at
all. The signed-by-CA certificate will not improve the content of the web (or
other service) and therefore would be a fake security component anyway if
I'd
like to harm the visitor somehow.
What kind of an argument is this?
Really, the quality of the protected service is not linked in any way to the
used certificate.

-- 
Regards,
Stephan

> On 10 August 2017, at 04:37, Alef Veld <alefveld at outlook.com>
wrote:
> 
> I completely agree (having said that I'm pretty new to all this so I
might be full of it).
> 
> You should run your own CA if you have an active financial interest in your
company (say your the owner). No added benefit to have your certificate
certified by a third party, why would they care about that one client). Ofcourse
people would say "but ofcourse you would verify your own certificate"
but in that case they probably don't understand how it all works.
> 
> Ofcourse once your own company grows large you run the same risk of entropy
(incorrect documentation or records, no trained staff, no up to date procedures
etc.) large companies have to deal with. Maybe if you had one person working
full time on it, or an automated process handling things it would be more secure
and reliable.
> 
> Was diginotar the Dutch company, I think I remember that one.
> 
> Sent from my iPhone
> 
>> On 10 Aug 2017, at 08:18, Stephan von Krawczynski <skraw at
ithnet.com> wrote:
>> 
>> 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
>> 

If you use a self-signed certificate, your users either have to accept the
certificate when requested, or install your root certificate.  Installing the
root certificate is not easy to explain to non-tech users even with step-by-step
instructions with screen shots attached.  I have gone this approach ever since
the RSA patents expired and it can be a pain at times.  Users just don't
understand the obnoxious warning (panic) messages the browsers put out that are
intended to keep them from accepting self-signed certificates.  The browser
developers don't understand the certificate trust issues either.  Several
Microsoft versions did not provide a way to accept the certificates.  Those
users were forced to install your root certificate.  However, as stated before,
if you are only certifying your own certificates, then that is the most
appropriate approach.

-- Doug

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Just my humble opinion:

We had ran a self-signed CA several years.

I would claim, that in theory this is more secure than using pre-installed 
third party CAs. Using a self-signed cert per server might do for small 
numers as well. However, when it comes to user divergence (or users 
coming from a wide range of knowledge and a wide range of devices come 
into play), roll your own is nightmare of support. As stated by others, 
some clients (Web browser, systems, mail clients, ...) make it hard to 
install own certs, Android even claims that the network (all of it from 
the interpretation of users) becomes insecure, once you install your own 
root cert. It looks like that more and more clients warns *each* time you 
access a server with a self-signed cert.

In the end, the gain of security (identify servers) was torpedoed by 
support and lack of understanding *and* will, even including poeple one 
might think they understand the need of extra steps in favour of security.

IMHO, the cert hierarchie today exclude eavesdropping by normal attackers, 
but is not suitable to identify servers or clients, because you (aka I) 
cannot trust the pre-installed trusted CAs.

If your set of users and devices is small enough, you can prepare all 
devices or offer an installation packet (for home users with a fixed set 
of clients), roll your own CA is easy and I would go this way. Alas, 
clients *should* mark personally trusted CAs differently than 
vendor-trusted ones. So users can see, if they speak with the correct 
server or if the server just looks alike, e.g. example.com vs. exampel.com 
.

- -- 
Steffen Kaiser
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEVAwUBWY1RBHz1H7kL/d9rAQJQdAf/WgD+230Fon0rlXHeTsaQ2fZnn55yA+Eb
6K8RxEJ3y1EK6kgVAlAICxU92ft8smjQZGUU4vhWv/fLnXUErSaptOnXu3Nk7io2
5LqEwv+jmcLWthqxkSY2NJw3kzaNTYLcuQ8cXAVHuzwQlJO4x0MAq1WR4kVQtQh6
cP/EinFxhWjyqQElSJ7ph3EYR/UJVTx1HVFS6bBiA+vY9s07EH64SRomOSwVC3ng
ryQZrwc2+5u+9hFfOnuGnBqj76szjhqPpa2PV7fQx8cFuJpJrctVxT+zbLf2sJpF
2XDzygpEiEbQuMe1st6ugOey9N+pdRWstsouVBbUAZ3L5PckmUYYVQ==X902
-----END PGP SIGNATURE-----

I have looked at let's encrypt. Key issue for me is having to add a lot 
python stuff that would otherwise not be on any server.

Again,  All CA's like "Let's Encrypt" - and others that are
accepted by
the "majors", e.g., Windows, Mozilla make it much easier for the 
"random" user to use anything you protect with SSL (better TLS)
without
them having to grant "trust" manually. That "trust" is
indicated because
the CA that signed your certificate is recognized by a CA, that is 
recognized by CA, that is recognized by a CA in the "root-trust" list 
that the "majors" make available (e.g., the mozilla list available via
the curl site (https://curl.haxx.se/docs/caextract.html)).

Now - back to Ralph's comment:


On 8/10/2017 1:42 PM, Ralph Seichter wrote:
> 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?
Rather than make the mistake I did years ago by make "unique" 
self-signed certificates for different servers - start out with a 
self-signed certificate that you use as a signing certificate. This is 
what Ralph means when he says "have been running a CA for 15+ years" -
not that he is (though he could!) sell certificates commercially - 
rather, he is using an initial certificate to sign later certificates 
with. So, his "users" only need to add the public side of his signing 
certificate - and any certificate he has signed meets the "chain of
trust".

So, if your users are "random", i.e., can come from anywhere - you may
want a "major accepted/recognized" certificate authority so that you
do
not have to distribute your signing key. However, if your user pool is 
"select", or otherwise known - requiring them to use your
"self-signed"
CA may be a positive, rather than a negative.

Again, technically, there is no difference in a self-signed 2048-bit RSA 
key, and one signed by a "major" CA. However, in the "ease of
use" there
may be major differences.

And, Ralph, I salute you. I have never been able to be disciplined 
enough to be my own CA. :)