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

> 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

I can't see any security advantages of a self signed cert. If the keypair is
generated locally (which it should) a certificate signed by an external CA
can't be worse just by the additional signature of the external CA.

Better security can only be gained if all users are urged to remove all
preinstalled trusted CAs from their mail clients (which seems impractical). Else
an attacker could still use a fake cert signed by one of those CAs. Public key
pinning could be an (academic) alternative and would still work with a cert
signed by an external CA without restrictions.

If someone tells me to add security exceptions this rings all alarm bells. Users
who are not experts should not get used to doing this as they soon will accept
everything.

Am 10. August 2017 21:40:25 MESZ schrieb Doug Hardie <bc979 at
lafn.org>:
>
>
>> 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
-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

Having gone through the process to get "approved" certificates a few
times, I don't believe it would be all that difficult to get a certificate
with your domain name from several of the "approved" certificate
authorities.  The process some of them use to "certify" the applicant
is pretty easy to spoof.  Clearly the hackers don't see that as much of an
obstacle.

-- Doug
> On 10 August 2017, at 13:41, Frank-Ulrich Sommer <f-u.s at gmx.net>
wrote:
> 
> I can't see any security advantages of a self signed cert. If the
keypair is generated locally (which it should) a certificate signed by an
external CA can't be worse just by the additional signature of the external
CA.
> 
> Better security can only be gained if all users are urged to remove all
preinstalled trusted CAs from their mail clients (which seems impractical). Else
an attacker could still use a fake cert signed by one of those CAs. Public key
pinning could be an (academic) alternative and would still work with a cert
signed by an external CA without restrictions.
> 
> If someone tells me to add security exceptions this rings all alarm bells.
Users who are not experts should not get used to doing this as they soon will
accept everything.
> 
> Am 10. August 2017 21:40:25 MESZ schrieb Doug Hardie <bc979 at
lafn.org>:
>> 
>> 
>>> 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
> 
> -- 
> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
gesendet.

On 08/10/2017 04:41 PM, Frank-Ulrich Sommer wrote:
> I can't see any security advantages of a self signed cert. I
then you fail to understand the history, like when Microsoft's certs
were undermined because the third party authentication agency gave the
keys to 2 guys that knocked on the door and asked for them...



-- 
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com

DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com - Leadership Development in Free Software
http://www2.mrbrklyn.com/resources - Unpublished Archive
http://www.coinhangout.com - coins!
http://www.brooklyn-living.com

Being so tracked is for FARM ANIMALS and and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013

On 08/10/2017 04:41 PM, Frank-Ulrich Sommer wrote:
> add security exceptions this rings all alarm bells. 
no, but software vendors will have you believe that.  Sorry, I don't
leave my house keys with strangers


-- 
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com

DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com - Leadership Development in Free Software
http://www2.mrbrklyn.com/resources - Unpublished Archive
http://www.coinhangout.com - coins!
http://www.brooklyn-living.com

Being so tracked is for FARM ANIMALS and and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013