Letsencrypt & TLSA - automation
Viktor Dukhovni
ietf-dane at dukhovni.org
Tue Feb 21 04:38:13 CET 2017
> On Feb 20, 2017, at 2:25 AM, Mike Cardwell <dane at lists.grepular.com> wrote:
>
> How do you intend to deal with the DNS caching issues? I.e, that you
> need to renew the SSL cert and then publish it in the DNS for at least
> one TTL before actually putting the cert in to production.
Indeed this is the key issue. The certificate provided by Let's Encrypt
should not be deployed as the live certificate used by the MTA until the
DNS TLSA records have been in place for at least a couple of TTLs.
Keep in that "TTL" here means not just the TTL for the RRset, but also
the refresh time of the zone by any slave servers, since until they obtain
fresh data they may be serving stale records with the full data TTL.
The simplest approach is to not point your MTA directly at the LE certs,
but instead to update the copy used by the MTA once the LE cert and its
TLSA digest have been in place sufficiently long...
This is complicated, which is why I recommend the "3 1 1" + "2 1 1"
approach with a stable public key described in:
http://postfix.1071664.n5.nabble.com/WoSign-StartCom-CA-in-the-news-td86436.html#a86444
and also in:
https://www.internetsociety.org/deploy360/blog/2016/03/lets-encrypt-certificates-for-mail-servers-and-dane-part-2-of-2/
--
Viktor.
More information about the dane-users
mailing list