On Feb 19, 2017, at 2:02 PM, Damien Goutte-Gattat wrote:

---8<--- m4_define(SPKI_DGST, `m4_esyscmd(openssl x509 -in $1 -pubkey -noout | \ openssl rsa -pubin -outform DER | \ openssl dgst -sha256 -binary | \ openssl enc -base64)')

_443._tcp.example.com. IN TLSA 3 1 1 SPKI_DGST(/path/to/web/cert) _25._tcp.mail.example.com. IN TLSA 3 1 1 SPKI_DGST(/path/to/mail/cert) --->8---

Are you sure that base64 works in this context??? The presentation format for TLSA records is hex encoded. I use: hexdump -ve '/1 "%02X"' where you're using "openssl enc -base64"

(The manual for GNU M4 contains a warning that M4 can be "fairly addictive" and that its users tend to use it everywhere; I'm afraid that's true.)

Long ago I too was an m4 addict, but then I kicked the habit... :-) That said, this implementation looks sensible. -- Viktor.

On Feb 20, 2017, at 2:25 AM, Mike Cardwell 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... -- Viktor.

On Feb 20, 2017, at 11:38 PM, Phil Pennock wrote:

This is why I just use DANE on the CA certs, with a spare CA entry, so that I don't need to coordinate grace periods around updating DNS on each renewal.

For exim.org, it's just LE. I ended up dropping down to just X3 and X4.

For my own domains, it's LE and my private CAs.

Thanks for that note. If one is willing to issue leaf certs from a private CA, that's by far the most robust option for port 25, where having a public trusted CA in the chain is not particularly useful. By all means, use LE on ports 587/465 for submission from mass-market MUAs, but MTAs will either be opportunistic unauthenticated, or verify private EE/private TA certs. I'll probably add some code to Postfix 3.3 to make it easy to create a TA key/cert + EE key/cert issued by said TA. And code to roll these as described in the various messages I keep posting links to. Updating the DNS will require a user-provided hook. -- Viktor.