On Feb 20, 2017, at 2:25 AM, Mike Cardwell dane@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....
and also in:
https://www.internetsociety.org/deploy360/blog/2016/03/lets-encrypt-certific...