Re: is a self signed certificate always invalid the first time
Michael Felt <michael@felt.demon.nl> 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 <jtam.home@gmail.com>
On Fri, 18 Aug 2017 00:24:39 -0700 (PDT) Joseph Tam <jtam.home@gmail.com> wrote:
Michael Felt <michael@felt.demon.nl> 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 <jtam.home@gmail.com>
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
On 18/08/17 20:05, Stephan von Krawczynski wrote:
On Fri, 18 Aug 2017 00:24:39 -0700 (PDT) Joseph Tam <jtam.home@gmail.com> wrote:
Michael Felt <michael@felt.demon.nl> 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 <jtam.home@gmail.com>
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
On Aug 18, 2017, at 4:05 AM, Stephan von Krawczynski <skraw@ithnet.com> wrote:
On Fri, 18 Aug 2017 00:24:39 -0700 (PDT) Joseph Tam <jtam.home@gmail.com> wrote:
Michael Felt <michael@felt.demon.nl> 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 <jtam.home@gmail.com>
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
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
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
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 pbw@pbw.id.au “My soul magnifies the Lord…”
On 20 Aug 2017, at 5:20 pm, Felix Zielcke <fzielcke@z-51.de> 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
On Aug 20, 2017, at 3:20 AM, Felix Zielcke <fzielcke@z-51.de> 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 <https://github.com/Neilpang/acme.sh>
The author supports running this script automatically with the docker image neilpang/acme.sh.
Kevin
On Sat, 19 Aug 2017 21:39:18 -0400 KT Walrus <kevin@my.walr.us> wrote:
On Aug 18, 2017, at 4:05 AM, Stephan von Krawczynski <skraw@ithnet.com> wrote:
On Fri, 18 Aug 2017 00:24:39 -0700 (PDT) Joseph Tam <jtam.home@gmail.com> wrote:
Michael Felt <michael@felt.demon.nl> 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 <jtam.home@gmail.com>
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
On Aug 20, 2017, at 11:52 AM, Stephan von Krawczynski <skraw@ithnet.com> wrote:
On Sat, 19 Aug 2017 21:39:18 -0400 KT Walrus <kevin@my.walr.us> wrote:
On Aug 18, 2017, at 4:05 AM, Stephan von Krawczynski <skraw@ithnet.com> wrote:
On Fri, 18 Aug 2017 00:24:39 -0700 (PDT) Joseph Tam <jtam.home@gmail.com> wrote:
Michael Felt <michael@felt.demon.nl> 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 <jtam.home@gmail.com>
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
On Sun, 20 Aug 2017 12:29:49 -0400 KT Walrus <kevin@my.walr.us> wrote:
On Aug 20, 2017, at 11:52 AM, Stephan von Krawczynski <skraw@ithnet.com> wrote:
On Sat, 19 Aug 2017 21:39:18 -0400 KT Walrus <kevin@my.walr.us> wrote:
On Aug 18, 2017, at 4:05 AM, Stephan von Krawczynski <skraw@ithnet.com> wrote:
On Fri, 18 Aug 2017 00:24:39 -0700 (PDT) Joseph Tam <jtam.home@gmail.com> wrote:
Michael Felt <michael@felt.demon.nl> 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 <jtam.home@gmail.com>
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
On 8/20/17, 12:33 PM, "dovecot on behalf of Stephan von Krawczynski" <dovecot-bounces@dovecot.org on behalf of skraw@ithnet.com> wrote:
On Sun, 20 Aug 2017 12:29:49 -0400
KT Walrus <kevin@my.walr.us> wrote:
> > On Aug 20, 2017, at 11:52 AM, Stephan von Krawczynski <skraw@ithnet.com>
> > wrote:
> >
> > On Sat, 19 Aug 2017 21:39:18 -0400
> > KT Walrus <kevin@my.walr.us> wrote:
> >
> >>> On Aug 18, 2017, at 4:05 AM, Stephan von Krawczynski <skraw@ithnet.com>
> >>> wrote:
> >>>
> >>> On Fri, 18 Aug 2017 00:24:39 -0700 (PDT)
> >>> Joseph Tam <jtam.home@gmail.com> wrote:
> >>>
> >>>> Michael Felt <michael@felt.demon.nl> 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 <jtam.home@gmail.com>
> >>>
> >>> 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,
StephanDynamic DNS Updates do it on the fly.
This is how I have acme.sh setup to do it, and my DHCP, et al.
On Aug 20, 2017, at 1:32 PM, Stephan von Krawczynski <skraw@ithnet.com> wrote:
On Sun, 20 Aug 2017 12:29:49 -0400 KT Walrus <kevin@my.walr.us> wrote:
On Aug 20, 2017, at 11:52 AM, Stephan von Krawczynski <skraw@ithnet.com> wrote:
On Sat, 19 Aug 2017 21:39:18 -0400 KT Walrus <kevin@my.walr.us> wrote:
On Aug 18, 2017, at 4:05 AM, Stephan von Krawczynski <skraw@ithnet.com> wrote:
On Fri, 18 Aug 2017 00:24:39 -0700 (PDT) Joseph Tam <jtam.home@gmail.com> wrote:
Michael Felt <michael@felt.demon.nl> 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 <jtam.home@gmail.com>
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 <https://github.com/Neilpang/acme.sh/tree/master/dnsapi>
Kevin
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. ;-)
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. ;-)
participants (10)
-
Bill Shirley
-
Felix Zielcke
-
Joseph Tam
-
KT Walrus
-
Larry Rosenman
-
Peter West
-
Ralph Seichter
-
Richard Hector
-
Ruben Safir
-
Stephan von Krawczynski