Re: is a self signed certificate always invalid the first time

[Bill Shirley]

I already have bind setup to allow DHCP to update.  Sometimes I need to
tweak things so I use nsupdate.  No 'rndc reload' required.
nsupdate.txt:
delete Zeratul.lan.example.com A
send
delete 90.6.168.192.in-addr.arpa PTR
send
add Zeratul.lan.example.com 902 A 192.168.6.89
send
add 89.6.168.192.in-addr.arpa 902 PTR Zeratul.lan.example.com
send
Command:
nsupdate -k /etc/named/DHCP_UPDATER.key nsupdate.txt

This could be used for a TXT record.

Bill

On 8/20/2017 3:59 PM, Ralph Seichter wrote:

On 20.08.2017 19:50, KT Walrus wrote:


I use Cloudflare (free DNS) and DNS Made Easy (paid DNS). I would never
run my own DNS service except for communicating between my Docker
services internally

I run my own nameservers for various reasons, not the least of them
being DNSSEC. My zones' signing keys never leave my hands.


If you run your own public DNS service (for your Dovecot domains), you
should pick one that has an API for updating the DNS records from a
script like acme.sh or simply write your own custom hook for acme.sh
to use.

Nameservers like BIND or Unbound can use text based config files (zone
files), which can be generated on the fly with scripts. Add "rndc
reload" to the mix, and changes can be made instantaneously, without any
special APIs.

What can be a bother is when TTL values are set too high and changes in
the zones take too long to propagate, but that's a general issue, and
when running your own nameservers you can set these values as low as you
require.

-Ralph

P.S.: All this sure is interesting, but way off-topic in regards to
Dovecot. ;-)

Re: is a self signed certificate always invalid the first time

[Ralph Seichter]

On 20.08.2017 19:50, KT Walrus wrote:

> I use Cloudflare (free DNS) and DNS Made Easy (paid DNS). I would never
> run my own DNS service except for communicating between my Docker
> services internally

I run my own nameservers for various reasons, not the least of them
being DNSSEC. My zones' signing keys never leave my hands.

> If you run your own public DNS service (for your Dovecot domains), you
> should pick one that has an API for updating the DNS records from a
> script like acme.sh or simply write your own custom hook for acme.sh
> to use.

Nameservers like BIND or Unbound can use text based config files (zone
files), which can be generated on the fly with scripts. Add "rndc
reload" to the mix, and changes can be made instantaneously, without any
special APIs.

What can be a bother is when TTL values are set too high and changes in
the zones take too long to propagate, but that's a general issue, and
when running your own nameservers you can set these values as low as you
require.

-Ralph

P.S.: All this sure is interesting, but way off-topic in regards to
Dovecot. ;-)

Re: is a self signed certificate always invalid the first time

[KT Walrus]

> On Aug 20, 2017, at 1:32 PM, Stephan von Krawczynski  wrote:
> 
> On Sun, 20 Aug 2017 12:29:49 -0400
> KT Walrus  wrote:
> 
>>> On Aug 20, 2017, at 11:52 AM, Stephan von Krawczynski 
>>> wrote:
>>> 
>>> On Sat, 19 Aug 2017 21:39:18 -0400
>>> KT Walrus  wrote:
>>> 
> On Aug 18, 2017, at 4:05 AM, Stephan von Krawczynski 
> wrote:
> 
> On Fri, 18 Aug 2017 00:24:39 -0700 (PDT)
> Joseph Tam  wrote:
> 
>> Michael Felt  writes:
>> 
 I use acme.sh for all of my LetsEncrypt certs (web & mail), it is
 written in pure shell script, so no python dependencies.
 https://github.com/Neilpang/acme.sh  
>>> 
>>> Thanks - I might look at that, but as Ralph mentions in his reply -
>>> Let's encrypt certs are only for three months - never ending
>>> circus.  
>> 
>> I wouldn't characterize it as a circus.  Once you bootstrap your first
>> certificate and install the cert-renew cron script, it's not something
>> you have to pay a lot of attention to.  I have a few LE certs in use,
>> and I don't think about it anymore: it just works.
>> 
>> The shorter cert lifetime also helps limit damage if your certificate
>> gets compromised.
>> 
>> Joseph Tam 
> 
> Obviously you do not use clustered environments with more than one node
> per service.
> Else you would not call it "it just works", because in fact the renewal
> is quite big bs as one node must do the job while all the others must be
> _offline_.
> 
> -- 
> Regards,
> Stephan
 
 I use DNS verification for LE certs. Much better since generating certs
 only depends on access to DNS and not your HTTP servers. Cert generation
 is automatic (on a cron job that runs every night looking for certs that
 are within 30 days of expiration). Once set up, it is pretty much
 automatic. I do use Docker to deploy all services for my website which
 also makes things pretty easy to manage.
 
 Kevin
 
>>> 
>>> DNS verification sounds nice only on first glimpse.
>>> If you have a lot of domains and ought to reload your DNS for every
>>> verification of every single domain that does not look like a method with a
>>> small footprint or particularly elegant.  
>> 
>> I don’t understand what you are trying to say. I have over 170 domains that
>> I generate certs for automatically using the acme.sh script. It is all
>> automatic and requires no “reload your DNS” by me. The script just updates
>> the DNS with a record that Let’s Encrypt checks before issuing the
>> certificate. After Let’s Encrypt verifies that you can update the DNS for
>> your domain with the record, the script removes the record.
>> 
>> This actually works much better than HTTP especially for domains like for
>> email servers that don’t have an HTTP server deployed for them.
>> 
>> Kevin
> 

> You can't update a record without reloading configs in bind. I guess you are
> using some other DNS service...

I use Cloudflare (free DNS) and DNS Made Easy (paid DNS). I would never run my 
own DNS service except for communicating between my Docker services internally 
(Docker has its own internal DNS for this and there are many pre-built docker 
images to provide a public DNS service, if required). But, Let’s Encrypt 
requires you update the public DNS used by the domains you are generating certs 
for. If you run your own public DNS service (for your Dovecot domains), you 
should pick one that has an API for updating the DNS records from a script like 
acme.sh or simply write your own custom hook for acme.sh to use.

See this page for all the DNS services that acme.sh supports: 

https://github.com/Neilpang/acme.sh/tree/master/dnsapi 


Kevin

Re: is a self signed certificate always invalid the first time

[Larry Rosenman]

On 8/20/17, 12:33 PM, "dovecot on behalf of Stephan von Krawczynski" 
 wrote:

On Sun, 20 Aug 2017 12:29:49 -0400
KT Walrus  wrote:

> > On Aug 20, 2017, at 11:52 AM, Stephan von Krawczynski 
> > wrote:
> > 
> > On Sat, 19 Aug 2017 21:39:18 -0400
> > KT Walrus  wrote:
> >   
> >>> On Aug 18, 2017, at 4:05 AM, Stephan von Krawczynski 

> >>> wrote:
> >>> 
> >>> On Fri, 18 Aug 2017 00:24:39 -0700 (PDT)
> >>> Joseph Tam  wrote:
> >>>   
>  Michael Felt  writes:
>    
> >> I use acme.sh for all of my LetsEncrypt certs (web & mail), it is
> >> written in pure shell script, so no python dependencies.
> >> https://github.com/Neilpang/acme.sh  
> > 
> > Thanks - I might look at that, but as Ralph mentions in his reply -
> > Let's encrypt certs are only for three months - never ending
> > circus.  
>  
>  I wouldn't characterize it as a circus.  Once you bootstrap your 
first
>  certificate and install the cert-renew cron script, it's not 
something
>  you have to pay a lot of attention to.  I have a few LE certs in use,
>  and I don't think about it anymore: it just works.
>  
>  The shorter cert lifetime also helps limit damage if your certificate
>  gets compromised.
>  
>  Joseph Tam 
> >>> 
> >>> Obviously you do not use clustered environments with more than one 
node
> >>> per service.
> >>> Else you would not call it "it just works", because in fact the 
renewal
> >>> is quite big bs as one node must do the job while all the others must 
be
> >>> _offline_.
> >>> 
> >>> -- 
> >>> Regards,
> >>> Stephan
> >> 
> >> I use DNS verification for LE certs. Much better since generating certs
> >> only depends on access to DNS and not your HTTP servers. Cert 
generation
> >> is automatic (on a cron job that runs every night looking for certs 
that
> >> are within 30 days of expiration). Once set up, it is pretty much
> >> automatic. I do use Docker to deploy all services for my website which
> >> also makes things pretty easy to manage.
> >> 
> >> Kevin
> >>   
> > 
> > DNS verification sounds nice only on first glimpse.
> > If you have a lot of domains and ought to reload your DNS for every
> > verification of every single domain that does not look like a method 
with a
> > small footprint or particularly elegant.  
> 
> I don’t understand what you are trying to say. I have over 170 domains 
that
> I generate certs for automatically using the acme.sh script. It is all
> automatic and requires no “reload your DNS” by me. The script just updates
> the DNS with a record that Let’s Encrypt checks before issuing the
> certificate. After Let’s Encrypt verifies that you can update the DNS for
> your domain with the record, the script removes the record.
> 
> This actually works much better than HTTP especially for domains like for
> email servers that don’t have an HTTP server deployed for them.
> 
> Kevin

You can't update a record without reloading configs in bind. I guess you are
using some other DNS service...

-- 
Regards,
Stephan

Dynamic DNS Updates do it on the fly.

This is how I have acme.sh setup to do it, and my DHCP, et al. 

Re: is a self signed certificate always invalid the first time

[Stephan von Krawczynski]

On Sun, 20 Aug 2017 12:29:49 -0400
KT Walrus  wrote:

> > On Aug 20, 2017, at 11:52 AM, Stephan von Krawczynski 
> > wrote:
> > 
> > On Sat, 19 Aug 2017 21:39:18 -0400
> > KT Walrus  wrote:
> >   
> >>> On Aug 18, 2017, at 4:05 AM, Stephan von Krawczynski 
> >>> wrote:
> >>> 
> >>> On Fri, 18 Aug 2017 00:24:39 -0700 (PDT)
> >>> Joseph Tam  wrote:
> >>>   
>  Michael Felt  writes:
>    
> >> I use acme.sh for all of my LetsEncrypt certs (web & mail), it is
> >> written in pure shell script, so no python dependencies.
> >> https://github.com/Neilpang/acme.sh  
> > 
> > Thanks - I might look at that, but as Ralph mentions in his reply -
> > Let's encrypt certs are only for three months - never ending
> > circus.  
>  
>  I wouldn't characterize it as a circus.  Once you bootstrap your first
>  certificate and install the cert-renew cron script, it's not something
>  you have to pay a lot of attention to.  I have a few LE certs in use,
>  and I don't think about it anymore: it just works.
>  
>  The shorter cert lifetime also helps limit damage if your certificate
>  gets compromised.
>  
>  Joseph Tam 
> >>> 
> >>> Obviously you do not use clustered environments with more than one node
> >>> per service.
> >>> Else you would not call it "it just works", because in fact the renewal
> >>> is quite big bs as one node must do the job while all the others must be
> >>> _offline_.
> >>> 
> >>> -- 
> >>> Regards,
> >>> Stephan
> >> 
> >> I use DNS verification for LE certs. Much better since generating certs
> >> only depends on access to DNS and not your HTTP servers. Cert generation
> >> is automatic (on a cron job that runs every night looking for certs that
> >> are within 30 days of expiration). Once set up, it is pretty much
> >> automatic. I do use Docker to deploy all services for my website which
> >> also makes things pretty easy to manage.
> >> 
> >> Kevin
> >>   
> > 
> > DNS verification sounds nice only on first glimpse.
> > If you have a lot of domains and ought to reload your DNS for every
> > verification of every single domain that does not look like a method with a
> > small footprint or particularly elegant.  
> 
> I don’t understand what you are trying to say. I have over 170 domains that
> I generate certs for automatically using the acme.sh script. It is all
> automatic and requires no “reload your DNS” by me. The script just updates
> the DNS with a record that Let’s Encrypt checks before issuing the
> certificate. After Let’s Encrypt verifies that you can update the DNS for
> your domain with the record, the script removes the record.
> 
> This actually works much better than HTTP especially for domains like for
> email servers that don’t have an HTTP server deployed for them.
> 
> Kevin

You can't update a record without reloading configs in bind. I guess you are
using some other DNS service...

-- 
Regards,
Stephan

Re: is a self signed certificate always invalid the first time

[KT Walrus]

> On Aug 20, 2017, at 11:52 AM, Stephan von Krawczynski  
> wrote:
> 
> On Sat, 19 Aug 2017 21:39:18 -0400
> KT Walrus  wrote:
> 
>>> On Aug 18, 2017, at 4:05 AM, Stephan von Krawczynski 
>>> wrote:
>>> 
>>> On Fri, 18 Aug 2017 00:24:39 -0700 (PDT)
>>> Joseph Tam  wrote:
>>> 
 Michael Felt  writes:
 
>> I use acme.sh for all of my LetsEncrypt certs (web & mail), it is
>> written in pure shell script, so no python dependencies.
>> https://github.com/Neilpang/acme.sh
> 
> Thanks - I might look at that, but as Ralph mentions in his reply -
> Let's encrypt certs are only for three months - never ending circus.
 
 I wouldn't characterize it as a circus.  Once you bootstrap your first
 certificate and install the cert-renew cron script, it's not something
 you have to pay a lot of attention to.  I have a few LE certs in use,
 and I don't think about it anymore: it just works.
 
 The shorter cert lifetime also helps limit damage if your certificate
 gets compromised.
 
 Joseph Tam   
>>> 
>>> Obviously you do not use clustered environments with more than one node per
>>> service.
>>> Else you would not call it "it just works", because in fact the renewal is
>>> quite big bs as one node must do the job while all the others must be
>>> _offline_.
>>> 
>>> -- 
>>> Regards,
>>> Stephan  
>> 
>> I use DNS verification for LE certs. Much better since generating certs only
>> depends on access to DNS and not your HTTP servers. Cert generation is
>> automatic (on a cron job that runs every night looking for certs that are
>> within 30 days of expiration). Once set up, it is pretty much automatic. I
>> do use Docker to deploy all services for my website which also makes things
>> pretty easy to manage.
>> 
>> Kevin
>> 
> 
> DNS verification sounds nice only on first glimpse.
> If you have a lot of domains and ought to reload your DNS for every
> verification of every single domain that does not look like a method with a
> small footprint or particularly elegant.

I don’t understand what you are trying to say. I have over 170 domains that I 
generate certs for automatically using the acme.sh script. It is all automatic 
and requires no “reload your DNS” by me. The script just updates the DNS with a 
record that Let’s Encrypt checks before issuing the certificate. After Let’s 
Encrypt verifies that you can update the DNS for your domain with the record, 
the script removes the record.

This actually works much better than HTTP especially for domains like for email 
servers that don’t have an HTTP server deployed for them.

Kevin

Re: is a self signed certificate always invalid the first time

[Stephan von Krawczynski]

On Sat, 19 Aug 2017 21:39:18 -0400
KT Walrus  wrote:

> > On Aug 18, 2017, at 4:05 AM, Stephan von Krawczynski 
> > wrote:
> > 
> > On Fri, 18 Aug 2017 00:24:39 -0700 (PDT)
> > Joseph Tam  wrote:
> >   
> >> Michael Felt  writes:
> >>   
>  I use acme.sh for all of my LetsEncrypt certs (web & mail), it is
>  written in pure shell script, so no python dependencies.
>  https://github.com/Neilpang/acme.sh
> >>> 
> >>> Thanks - I might look at that, but as Ralph mentions in his reply -
> >>> Let's encrypt certs are only for three months - never ending circus.
> >> 
> >> I wouldn't characterize it as a circus.  Once you bootstrap your first
> >> certificate and install the cert-renew cron script, it's not something
> >> you have to pay a lot of attention to.  I have a few LE certs in use,
> >> and I don't think about it anymore: it just works.
> >> 
> >> The shorter cert lifetime also helps limit damage if your certificate
> >> gets compromised.
> >> 
> >> Joseph Tam   
> > 
> > Obviously you do not use clustered environments with more than one node per
> > service.
> > Else you would not call it "it just works", because in fact the renewal is
> > quite big bs as one node must do the job while all the others must be
> > _offline_.
> > 
> > -- 
> > Regards,
> > Stephan  
> 
> I use DNS verification for LE certs. Much better since generating certs only
> depends on access to DNS and not your HTTP servers. Cert generation is
> automatic (on a cron job that runs every night looking for certs that are
> within 30 days of expiration). Once set up, it is pretty much automatic. I
> do use Docker to deploy all services for my website which also makes things
> pretty easy to manage.
> 
> Kevin
> 

DNS verification sounds nice only on first glimpse.
If you have a lot of domains and ought to reload your DNS for every
verification of every single domain that does not look like a method with a
small footprint or particularly elegant.

-- 
Regards,
Stephan

Re: is a self signed certificate always invalid the first time

[KT Walrus]

> On Aug 20, 2017, at 3:20 AM, Felix Zielcke  wrote:
> 
> Am Samstag, den 19.08.2017, 21:39 -0400 schrieb KT Walrus:
>> 
>> I use DNS verification for LE certs. Much better since generating
>> certs only depends on access to DNS and not your HTTP servers. Cert
>> generation is automatic (on a cron job that runs every night looking
>> for certs that are within 30 days of expiration). Once set up, it is
>> pretty much automatic. I do use Docker to deploy all services for my
>> website which also makes things pretty easy to manage.
>> 
>> Kevin
> 
> Hi Kevin,
> 
> what software do you use for DNS based verification? I read with the
> official certbot from LE it's not possible to do this fully automated.
> Currently I use the http based method, but would like to switch to DNS
> based.
> 
> Greetings
> Felix

I use the acme.sh script: https://github.com/Neilpang/acme.sh 


The author supports running this script automatically with the docker image 
neilpang/acme.sh.

Kevin

Re: is a self signed certificate always invalid the first time

[Peter West]

Hi Felix,

I use getssl, which is a bash script, for LE certs.  For certs on one server I 
use http, for the other DNS.

The DNS method depends on your DNS provider.  Many providers have an API for 
updating DNS. getssl provides scripts for a small number of popular providers. 
Acme.sh provides a greater range of DNS provider APIs.

I added my own linode dns scripts in preference to those provided by getssl.  
Linode’s 15 minute DNS update delay has to be accounted for.

--
Peter West
p...@pbw.id.au
“My soul magnifies the Lord…”

> On 20 Aug 2017, at 5:20 pm, Felix Zielcke  wrote:
> 
> Am Samstag, den 19.08.2017, 21:39 -0400 schrieb KT Walrus:
>> 
>> I use DNS verification for LE certs. Much better since generating
>> certs only depends on access to DNS and not your HTTP servers. Cert
>> generation is automatic (on a cron job that runs every night looking
>> for certs that are within 30 days of expiration). Once set up, it is
>> pretty much automatic. I do use Docker to deploy all services for my
>> website which also makes things pretty easy to manage.
>> 
>> Kevin
> 
> Hi Kevin,
> 
> what software do you use for DNS based verification? I read with the
> official certbot from LE it's not possible to do this fully automated.
> Currently I use the http based method, but would like to switch to DNS
> based.
> 
> Greetings
> Felix





signature.asc
Description: Message signed with OpenPGP

Re: is a self signed certificate always invalid the first time

[Felix Zielcke]

Am Samstag, den 19.08.2017, 21:39 -0400 schrieb KT Walrus:
> 
> I use DNS verification for LE certs. Much better since generating
> certs only depends on access to DNS and not your HTTP servers. Cert
> generation is automatic (on a cron job that runs every night looking
> for certs that are within 30 days of expiration). Once set up, it is
> pretty much automatic. I do use Docker to deploy all services for my
> website which also makes things pretty easy to manage.
> 
> Kevin

Hi Kevin,

what software do you use for DNS based verification? I read with the
official certbot from LE it's not possible to do this fully automated.
Currently I use the http based method, but would like to switch to DNS
based.

Greetings
Felix

Re: is a self signed certificate always invalid the first time

[Ruben Safir]

On 08/19/2017 09:39 PM, KT Walrus wrote:
> I use DNS verification for LE certs.


what is that?


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

Re: is a self signed certificate always invalid the first time

[KT Walrus]

> On Aug 18, 2017, at 4:05 AM, Stephan von Krawczynski  wrote:
> 
> On Fri, 18 Aug 2017 00:24:39 -0700 (PDT)
> Joseph Tam  wrote:
> 
>> Michael Felt  writes:
>> 
 I use acme.sh for all of my LetsEncrypt certs (web & mail), it is
 written in pure shell script, so no python dependencies.
 https://github.com/Neilpang/acme.sh  
>>> 
>>> Thanks - I might look at that, but as Ralph mentions in his reply -
>>> Let's encrypt certs are only for three months - never ending circus.  
>> 
>> I wouldn't characterize it as a circus.  Once you bootstrap your first
>> certificate and install the cert-renew cron script, it's not something
>> you have to pay a lot of attention to.  I have a few LE certs in use,
>> and I don't think about it anymore: it just works.
>> 
>> The shorter cert lifetime also helps limit damage if your certificate
>> gets compromised.
>> 
>> Joseph Tam 
> 
> Obviously you do not use clustered environments with more than one node per
> service.
> Else you would not call it "it just works", because in fact the renewal is
> quite big bs as one node must do the job while all the others must be
> _offline_.
> 
> -- 
> Regards,
> Stephan

I use DNS verification for LE certs. Much better since generating certs only 
depends on access to DNS and not your HTTP servers. Cert generation is 
automatic (on a cron job that runs every night looking for certs that are 
within 30 days of expiration). Once set up, it is pretty much automatic. I do 
use Docker to deploy all services for my website which also makes things pretty 
easy to manage.

Kevin

Re: is a self signed certificate always invalid the first time

[Richard Hector]

On 18/08/17 20:05, Stephan von Krawczynski wrote:
> On Fri, 18 Aug 2017 00:24:39 -0700 (PDT)
> Joseph Tam  wrote:
> 
>> Michael Felt  writes:
>>
 I use acme.sh for all of my LetsEncrypt certs (web & mail), it is
 written in pure shell script, so no python dependencies.
 https://github.com/Neilpang/acme.sh  
>>>
>>> Thanks - I might look at that, but as Ralph mentions in his reply -
>>> Let's encrypt certs are only for three months - never ending circus.  
>>
>> I wouldn't characterize it as a circus.  Once you bootstrap your first
>> certificate and install the cert-renew cron script, it's not something
>> you have to pay a lot of attention to.  I have a few LE certs in use,
>> and I don't think about it anymore: it just works.
>>
>> The shorter cert lifetime also helps limit damage if your certificate
>> gets compromised.
>>
>> Joseph Tam 
> 
> Obviously you do not use clustered environments with more than one node per
> service.
> Else you would not call it "it just works", because in fact the renewal is
> quite big bs as one node must do the job while all the others must be
> _offline_.
> 

Couldn't the others just proxy to the one, for the .well-known
directory? They can continue serving up the rest of the site fine, surely?

I've worked with clusters, and with LE/certbot, but not yet both together.

Richard

Re: is a self signed certificate always invalid the first time?

[Ralph Seichter]

On 18.08.2017 09:12, voy...@sbt.net.au wrote:

> for a public web server where https is becoming mandatory, I'd still
> need a certificate from a recognized publisher, to avoid users geting
> 'warnings', is that so ?

For a certificate to be reported as "valid", an unbroken chain of
cryptographic signatures is required. Browsers are released with a set
of Root CA and Intermediate CA certificates, as are operating systems.
Some use the Mozilla CA Certificate Store[1], for example, others come
with their own CA stores, like macOS[2].

[1] 
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/
[2] https://support.apple.com/en-us/HT202858

Unless your web server certificate's signature chain originates from one
of the CAs delivered with a web browser or OS, the end user connecting
to your site will either have to manually add the required CAs, or add
your server certificate, or be presented with a warning/error message.

One could argue that relying on certificate stores is placing personal
security concerns in other people's hands. Of course, it would be a
potentially funny thing to try and verify the validity of your online
banking server's certificate by asking them to send you a letter
containing the certificate fingerprint...

-Ralph

Re: is a self signed certificate always invalid the first time?

[Ralph Seichter]

On 18.08.2017 08:58, Michael Felt wrote:

> as Ralph mentions in his reply - Let's encrypt certs are only for
> three months - never ending circus.

I don't consider the 90-day-lifespan a "circus". It is meant as a
security feature[1], and Let's Encrypt suggests using automation for
certificate renewal. Also, with ACME v2 on the horizon[2], I imagine
that more automation tools will become available.

[1] https://letsencrypt.org/2015/11/09/why-90-days.html
[2] https://letsencrypt.org/2017/06/14/acme-v2-api.html

Let's not forget that Let's Encrypt is still a young service, and that
it is free.

-Ralph

Re: is a self signed certificate always invalid the first time?

[Noel Butler]

On 18/08/2017 17:12, voy...@sbt.net.au wrote:

> BUT, for a public web server where https is becoming mandatory, I'd still
> need a certificate from a recognized publisher, to avoid users geting
> 'warnings', is that so ?
> 
> (I'm currently using self issued for both mail and web)
> 
> thanks,
> 
> V

It depends on what you're uses are, self signed certs are OK for
smtp/pop3/imap, since most people are just concerned with "encryption"
in that case, but a different story if its web content, in particular,
shopping carts and the like, If you have clients content, definitely use
a real cert, maybe in 10 years letsencrypt might make the grade, but
until every bit of software and OS supports it and they offer insurance
levels like the bi boys do, you might as well be using a self signed
cert,  comodo are pretty cheap with basic insurance level on even the
most basic of their offerings. Do your research, though if using a paid
service, since some others are soon to be un-trusted. 

-- 
Kind Regards, 

Noel Butler 

This Email, including any attachments, may contain legally 
privileged
information, therefore remains confidential and subject to copyright
protected under international law. You may not disseminate, discuss, or
reveal, any part, to anyone, without the authors express written
authority to do so. If you are not the intended recipient, please notify
the sender then delete all copies of this message including attachments,
immediately. Confidentiality, copyright, and legal privilege are not
waived or lost by reason of the mistaken delivery of this message. Only
PDF [1] and ODF [2] documents accepted, please do not send proprietary
formatted documents 

 

Links:
--
[1] http://www.adobe.com/
[2] http://en.wikipedia.org/wiki/OpenDocument

signature.asc
Description: OpenPGP digital signature

Re: is a self signed certificate always invalid the first time

[Joseph Tam]

Obviously you do not use clustered environments with more than one node
per service.  Else you would not call it "it just works", because in
fact the renewal is quite big bs as one node must do the job while all
the others must be _offline_.


I'm not sure how you have set up your clustered service, but why do
your nodes have to go offline?  If these other nodes are using an older
certificate, it should still work as the previous/renewed certificate
usually have overlapping active begin/expiration dates.

Joseph Tam 

Re: is a self signed certificate always invalid the first time?

[Steffen Kaiser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, 18 Aug 2017, voy...@sbt.net.au wrote:


BUT, for a public web server where https is becoming mandatory, I'd still
need a certificate from a recognized publisher, to avoid users geting
'warnings', is that so ?


As Michael wrote already, it's the same vor all SSL certificates, because 
the underlying mechanism is the same.


- -- 
Steffen Kaiser

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEVAwUBWZakenz1H7kL/d9rAQLV7ggAqgiz+7ttcsu4/JAHExarvu+aovhNk+Lp
OqzdlME8tSnEzKUfeHmkgXR2AMAOiET4HvsU0HWsm9zwyZ24Lgxo+mJ2lN6317H2
/nlNuQDImgDB8BLTarUpucVpp7R2ppXeuy+8TPyAmagZo6kR8okkFHoMzQSDHleG
gPjoBDVHq0FH6WYq25u2ts7l6L+FKEinX5T/b2hcIqnTgM129E/ak1gYZWmQm9+S
bM29aHNnpV/B8uPhACXruTV3DFWW2s9wIgopgHKA0XH4g7p3DYeiXFUTyZ+e9kNN
oabc56sQSd4QASpEBjsOPd8Sx3pZtiXzxZnb3yLIhjyCilwNLZA8xw==
=Phs1
-END PGP SIGNATURE-

Re: is a self signed certificate always invalid the first time

[Stephan von Krawczynski]

On Fri, 18 Aug 2017 00:24:39 -0700 (PDT)
Joseph Tam  wrote:

> Michael Felt  writes:
> 
> >> I use acme.sh for all of my LetsEncrypt certs (web & mail), it is
> >> written in pure shell script, so no python dependencies.
> >> https://github.com/Neilpang/acme.sh  
> >
> > Thanks - I might look at that, but as Ralph mentions in his reply -
> > Let's encrypt certs are only for three months - never ending circus.  
> 
> I wouldn't characterize it as a circus.  Once you bootstrap your first
> certificate and install the cert-renew cron script, it's not something
> you have to pay a lot of attention to.  I have a few LE certs in use,
> and I don't think about it anymore: it just works.
> 
> The shorter cert lifetime also helps limit damage if your certificate
> gets compromised.
> 
> Joseph Tam 

Obviously you do not use clustered environments with more than one node per
service.
Else you would not call it "it just works", because in fact the renewal is
quite big bs as one node must do the job while all the others must be
_offline_.

-- 
Regards,
Stephan

Re: is a self signed certificate always invalid the first time?

[Michael Felt]

On 8/18/2017 9:12 AM, voy...@sbt.net.au wrote:

On Fri, August 18, 2017 5:02 pm, Michael Felt wrote:

On 8/11/2017 1:29 PM, Ralph Seichter wrote:

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

I encourage you to look into the subject again.


I actually have been, which is why I could give a near sensible reply.
Thanks for the encouragement!


With the advent of Let's
Encrypt, free certs for the masses have become a thing, but if you need
more than 3 months validity, want to create certs for Intranet-devices
(routers, local servers), or just want maximum control over all certs,
setting up your own CA is rewarding. While you're at it, no gentleman
should not be without DNSSEC, DKIM and DANE these days. ;-)

I should know all three, but, sadly, only one: two things to add to my
list of things to research.


I have been reading this with some interest (while trying to migrate
Dovecot, Postfix etc..)

BUT, for a public web server where https is becoming mandatory, I'd still
need a certificate from a recognized publisher, to avoid users geting
'warnings', is that so ?

(I'm currently using self issued for both mail and web)

Above - Ralph added:

I also made my CA
certs available for public download, so tech-savvy users can import the
CA certs manually.
Depending on your site-popularity (aka number of "random" users) you 
could also instruct them how to access your signing key. Once they had 
that, they would auto-magically, recognize any other keys you signed 
with your CA "roots".


In other words, if the work to you to instruct users to use your CA is 
more expensive than using a commercial CA - save money and use a 
commercial CA. Before spending any money on a commercial CA - look at 
alternatives such as Let's Encrypt. I am also looking at 
http://www.cacert.org/ (That might be something for you Ralph!)




thanks,

V

Re: is a self signed certificate always invalid the first time

[Joseph Tam]

Michael Felt  writes:


I use acme.sh for all of my LetsEncrypt certs (web & mail), it is
written in pure shell script, so no python dependencies.
https://github.com/Neilpang/acme.sh


Thanks - I might look at that, but as Ralph mentions in his reply -
Let's encrypt certs are only for three months - never ending circus.


I wouldn't characterize it as a circus.  Once you bootstrap your first
certificate and install the cert-renew cron script, it's not something
you have to pay a lot of attention to.  I have a few LE certs in use,
and I don't think about it anymore: it just works.

The shorter cert lifetime also helps limit damage if your certificate
gets compromised.

Joseph Tam 

Re: is a self signed certificate always invalid the first time?

[voytek]

On Fri, August 18, 2017 5:02 pm, Michael Felt wrote:
> On 8/11/2017 1:29 PM, Ralph Seichter wrote:

>>> And, Ralph, I salute you. I have never been able to be disciplined
>>> enough to be my own CA.
>> I encourage you to look into the subject again.
>>
> I actually have been, which is why I could give a near sensible reply.
> Thanks for the encouragement!
>
>> With the advent of Let's
>> Encrypt, free certs for the masses have become a thing, but if you need
>> more than 3 months validity, want to create certs for Intranet-devices
>> (routers, local servers), or just want maximum control over all certs,
>> setting up your own CA is rewarding. While you're at it, no gentleman
>> should not be without DNSSEC, DKIM and DANE these days. ;-)
> I should know all three, but, sadly, only one: two things to add to my
> list of things to research.


I have been reading this with some interest (while trying to migrate
Dovecot, Postfix etc..)

BUT, for a public web server where https is becoming mandatory, I'd still
need a certificate from a recognized publisher, to avoid users geting
'warnings', is that so ?

(I'm currently using self issued for both mail and web)

thanks,

V

Re: is a self signed certificate always invalid the first time?

[Michael Felt]

On 8/11/2017 1:29 PM, Ralph Seichter wrote:

On 11.08.2017 11:36, Michael Felt wrote:


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.

Actually, I do sell certificates to my customers. :-) In small numbers,
and only for servers to which I have administrative access.

So, not really "selling", but an additional service.

I created a
root CA and two intermediate CAs (one each for client and server certs,
respectively).

It would be great to have my CAs added to Mozilla's NSS root certificate
store, but alas, the effort to get there is massive. Where possible, I
will add my CA certs to the customers' keystores. I also made my CA
certs available for public download, so tech-savvy users can import the
CA certs manually.


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.

In 2015 I rolled out an updated CA which I have used ever since, with
4096 bit keys for root and intermediary CA certs. I also only generate
4096 bit keys for servers these days, so my cert chain is "stronger"
than those of some commercial CAs. Also, it is good to know that these
certs have never been touched by anybody but myself. I even install my
own CA cert chain on my iOS devices.


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

I encourage you to look into the subject again.
I actually have been, which is why I could give a near sensible reply. 
Thanks for the encouragement!

With the advent of Let's
Encrypt, free certs for the masses have become a thing, but if you need
more than 3 months validity, want to create certs for Intranet-devices
(routers, local servers), or just want maximum control over all certs,
setting up your own CA is rewarding. While you're at it, no gentleman
should not be without DNSSEC, DKIM and DANE these days. ;-)
I should know all three, but, sadly, only one: two things to add to my 
list of things to research.

-Ralph

Re: is a self signed certificate always invalid the first time?

[Michael Felt]

On 8/11/2017 11:44 AM, Florian Beer wrote:

On 2017-08-11 11:36, Michael Felt wrote:

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.



I use acme.sh for all of my LetsEncrypt certs (web & mail), it is 
written in pure shell script, so no python dependencies.

https://github.com/Neilpang/acme.sh
Thanks - I might look at that, but as Ralph mentions in his reply - 
Let's encrypt certs are only for three months - never ending circus.

Re: is a self signed certificate always invalid the first time?

[Frank-Ulrich Sommer]

Am 11. August 2017 12:46:46 MESZ schrieb Ruben Safir :
>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

Of course I know about this risk. But the only way to reduce it is to remove 
all preinstalled root CAs from all devices you use. It's more important whoom 
your client trusts than who signed your cert.

Using a self signed cert alone and still using a client with a huge list of 
preinstalled root CAs will be exactly as vulnerable as using a regular cert 
with this client. The client will accept a spoofed cert that was fraudulently 
obtained from one of those root CAs in both cases.

If you configure your client such that it only accepts certs that you manually 
added you could (theoretically and from a security standpoint) still use certs 
signed by an external CA that you add manually without compromising security. 
It's only important that you don't let someone else (e.g. the CA because it's 
easier...) generate your key pair but that you generate it yourself and only 
submit a certificate signing request.

Re: is a self signed certificate always invalid the first time?

[Ralph Seichter]

On 11.08.2017 11:36, Michael Felt wrote:

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

Actually, I do sell certificates to my customers. :-) In small numbers,
and only for servers to which I have administrative access. I created a
root CA and two intermediate CAs (one each for client and server certs,
respectively).

It would be great to have my CAs added to Mozilla's NSS root certificate
store, but alas, the effort to get there is massive. Where possible, I
will add my CA certs to the customers' keystores. I also made my CA
certs available for public download, so tech-savvy users can import the
CA certs manually.

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

In 2015 I rolled out an updated CA which I have used ever since, with
4096 bit keys for root and intermediary CA certs. I also only generate
4096 bit keys for servers these days, so my cert chain is "stronger"
than those of some commercial CAs. Also, it is good to know that these
certs have never been touched by anybody but myself. I even install my
own CA cert chain on my iOS devices.

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

I encourage you to look into the subject again. With the advent of Let's
Encrypt, free certs for the masses have become a thing, but if you need
more than 3 months validity, want to create certs for Intranet-devices
(routers, local servers), or just want maximum control over all certs,
setting up your own CA is rewarding. While you're at it, no gentleman
should not be without DNSSEC, DKIM and DANE these days. ;-)

-Ralph

Re: is a self signed certificate always invalid the first time?

[Ruben Safir]

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

Re: is a self signed certificate always invalid the first time?

[Ruben Safir]

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

Re: is a self signed certificate always invalid the first time?

[Florian Beer]

On 2017-08-11 11:36, Michael Felt wrote:

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.



I use acme.sh for all of my LetsEncrypt certs (web & mail), it is 
written in pure shell script, so no python dependencies.

https://github.com/Neilpang/acme.sh

Re: is a self signed certificate always invalid the first time?

[Michael Felt]

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. :)

pre-installed CA (was: is a self signed certificate always invalid the first time?)

[Steffen Kaiser]

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

Re: is a self signed certificate always invalid the first time?

[Doug Hardie]

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  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 :
>> 
>> 
>>> On 10 August 2017, at 04:37, Alef Veld  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 
>> wrote:
 
 On Wed, 9 Aug 2017 08:39:30 -0700
 Gregory Sloop  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 

Re: is a self signed certificate always invalid the first time?

[Frank-Ulrich Sommer]

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 :
>
>
>> On 10 August 2017, at 04:37, Alef Veld  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 
>wrote:
>>> 
>>> On Wed, 9 Aug 2017 08:39:30 -0700
>>> Gregory Sloop  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 

Re: is a self signed certificate always invalid the first time?

[Stephan von Krawczynski]

On Thu, 10 Aug 2017 07:53:16 -0700
Gregory Sloop  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

Re: is a self signed certificate always invalid the first time?

[Gregory Sloop]

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

Re: is a self signed certificate always invalid the first time?

[Alef Veld]

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

Re: is a self signed certificate always invalid the first time?

[Ralph Seichter]

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

Re: is a self signed certificate always invalid the first time?

[Alef Veld]

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  wrote:
> 
> On Wed, 9 Aug 2017 08:39:30 -0700
> Gregory Sloop  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
> 

Re: is a self signed certificate always invalid the first time?

[Stephan von Krawczynski]

On Wed, 9 Aug 2017 08:39:30 -0700
Gregory Sloop  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

Re: is a self signed certificate always invalid the first time?

[Alef Veld]

Great, i’ll try that out.
> On 9 Aug 2017, at 17:20, Larry Rosenman  wrote:
> 
> Yes, yes, and yes. 
> 
> This is what I do for https://webmail.lerctr.org, imap.lerctr.org, 
> smtp.lerctr.org, et al. 
> 
> 
> -- 
> Larry Rosenman http://www.lerctr.org/~ler
> Phone: +1 214-642-9640 E-Mail: larry...@gmail.com
> US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106
> 
> 
> On 8/9/17, 11:19 AM, "dovecot on behalf of Alef Veld" 
>  wrote:
> 
>Cheers Remko and Ralph. I think there was some mention in the lets encrypt 
> FAQ that certbot doesn't do email.
> 
>But I understand I can use their generated very for dovecot, postfix and 
> https? That would be good indeed.
> 
>Anyone know of any manual, or can I just replace the certs in the dovecot 
> and postfix locations with theirs? Do dovecot, postfix and apache all support 
> .pem format?
> 
>Sent from my iPhone
> 
>> On 9 Aug 2017, at 17:07, Ralph Seichter  wrote:
>> 
>>> On 09.08.2017 17:49, Alef Veld wrote:
>>> 
>>> 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.
>> 
>> I'm not sure what you mean by "can’t do email certificates"? In any
>> case, Let's Encrypt issues certificates that can be used by Dovecot
>> for IMAP and simultaneously by Apache or nginx for HTTPS and Postfix
>> for SMTP. The certificates are issued for servers, not for specific
>> software or protocols.
>> 
>> -Ralph
> 
> 
> 

Re: is a self signed certificate always invalid the first time?

[Alef Veld]

Thank you Ralph. I’ll have a look around myself first, don’t want others to 
waste their time on my homework.

Sorry for some reason i get replies from every individual , so when i reply it 
sends it to both.
I would expect replies to come from dovecot@dovecot.org as well.

I will strip the individual emails out and just reply to dovecot.
> On 9 Aug 2017, at 17:30, Ralph Seichter  wrote:
> 
> On 09.08.2017 18:18, Alef Veld wrote:
> 
>> Anyone know of any manual, or can I just replace the certs in the
>> dovecot and postfix locations with theirs? Do dovecot, postfix and
>> apache all support .pem format?
> 
> Google "dovecot letsencrypt" is your friend. ;-) If you have questions
> about details, we can discuss them of course. Also, please limit your
> replies to my messages to the mailing list; you keep triggering my spam
> protection.
> 
> -Ralph

Re: is a self signed certificate always invalid the first time?

[Ralph Seichter]

On 09.08.2017 18:18, Alef Veld wrote:

> Anyone know of any manual, or can I just replace the certs in the
> dovecot and postfix locations with theirs? Do dovecot, postfix and
> apache all support .pem format?

Google "dovecot letsencrypt" is your friend. ;-) If you have questions
about details, we can discuss them of course. Also, please limit your
replies to my messages to the mailing list; you keep triggering my spam
protection.

-Ralph

Re: is a self signed certificate always invalid the first time?

[Larry Rosenman]

Yes, yes, and yes. 

This is what I do for https://webmail.lerctr.org, imap.lerctr.org, 
smtp.lerctr.org, et al. 


-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: larry...@gmail.com
US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106
 

On 8/9/17, 11:19 AM, "dovecot on behalf of Alef Veld" 
 wrote:

Cheers Remko and Ralph. I think there was some mention in the lets encrypt 
FAQ that certbot doesn't do email.

But I understand I can use their generated very for dovecot, postfix and 
https? That would be good indeed.

Anyone know of any manual, or can I just replace the certs in the dovecot 
and postfix locations with theirs? Do dovecot, postfix and apache all support 
.pem format?

Sent from my iPhone

> On 9 Aug 2017, at 17:07, Ralph Seichter  
wrote:
> 
>> On 09.08.2017 17:49, Alef Veld wrote:
>> 
>> 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.
> 
> I'm not sure what you mean by "can’t do email certificates"? In any
> case, Let's Encrypt issues certificates that can be used by Dovecot
> for IMAP and simultaneously by Apache or nginx for HTTPS and Postfix
> for SMTP. The certificates are issued for servers, not for specific
> software or protocols.
> 
> -Ralph

Re: is a self signed certificate always invalid the first time?

[Alef Veld]

Cheers Remko and Ralph. I think there was some mention in the lets encrypt FAQ 
that certbot doesn't do email.

But I understand I can use their generated very for dovecot, postfix and https? 
That would be good indeed.

Anyone know of any manual, or can I just replace the certs in the dovecot and 
postfix locations with theirs? Do dovecot, postfix and apache all support .pem 
format?

Sent from my iPhone

> On 9 Aug 2017, at 17:07, Ralph Seichter  wrote:
> 
>> On 09.08.2017 17:49, Alef Veld wrote:
>> 
>> 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.
> 
> I'm not sure what you mean by "can’t do email certificates"? In any
> case, Let's Encrypt issues certificates that can be used by Dovecot
> for IMAP and simultaneously by Apache or nginx for HTTPS and Postfix
> for SMTP. The certificates are issued for servers, not for specific
> software or protocols.
> 
> -Ralph

Re: is a self signed certificate always invalid the first time?

[Ralph Seichter]

On 09.08.2017 17:49, Alef Veld wrote:

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

I'm not sure what you mean by "can’t do email certificates"? In any
case, Let's Encrypt issues certificates that can be used by Dovecot
for IMAP and simultaneously by Apache or nginx for HTTPS and Postfix
for SMTP. The certificates are issued for servers, not for specific
software or protocols.

-Ralph

Re: is a self signed certificate always invalid the first time?

[Remko Lodder]

Alef,

Certbot creates regular certificates that can be used by dovecot to get a 
“validated” connection to the mailserver.
You obviously need to do the certbot walk to gain the certificate, but if you 
have it, you can use it for dovecot.

Just refer to it in the configuration and you should be fine..

Cheers
Remko

> On 9 Aug 2017, at 17:49, Alef Veld  wrote:
> 
> 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  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
> 



signature.asc
Description: Message signed with OpenPGP

Re: is a self signed certificate always invalid the first time?

[Alef Veld]

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

Re: is a self signed certificate always invalid the first time?

[Alef Veld]

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

On 9 Aug 2017, at 16:39, Gregory Sloop 
> 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

Re: is a self signed certificate always invalid the first time?

[Gregory Sloop]

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

Re: is a self signed certificate always invalid the first time?

[Ralph Seichter]

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

is a self signed certificate always invalid the first time?

[Alef Veld]

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.