Victor, thank you for your two helpful replies. I do intend to read through the approaches you suggested, and most likely implement them. My high-priority was to get the mail flowing again, which your first helpful reply let me do. Indeed, I postponed replying because I wanted to read the items you suggested before I did so.
I should point out that this problem arose from a bug in one of my scripts that generates both the certificates and the DNS entries. I failed to use my new subroutine in one place to select the certificate to publish in DNS when I went from self-signed to Let's Encrypt (it was used in postfix main.cf, but not the named zone file), so it was still publishing the self-signed certificate. I thought all was OK after the changeover because https://www.checktls.com and openssl s_client both said so. -Earl On 2/16/20 19:16, Viktor Dukhovni wrote: > On Sun, Feb 16, 2020 at 01:41:16PM -0500, Viktor Dukhovni wrote: > >> ; Suggested more robust TLSA record management approaches can be found >> via: >> >> >> https://github.com/internetstandards/toolbox-wiki/blob/master/DANE-for-SMTP-how-to.md >> https://mail.sys4.de/pipermail/dane-users/2018-February/000440.html >> >> https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022/17 >> https://mail.sys4.de/pipermail/dane-users/2017-August/000417.html >> >> https://github.com/baknu/DANE-for-SMTP/wiki/2.-Implementation-resources > No matter how hard I try, it seems people are just too distracted to > heed (or read) sound advice (e.g. the 3rd link above). A band-aid has > been applied and the published TLSA record is now: > > @maple.killian.com.[199.165.155.8] > @pine.killian.com.[35.167.26.164] > _25._tcp.maple.killian.com. TLSA 3 0 1 > CA2BE3CF3E0F13FEC3860BC6A54A21F3D51DEEA640FE8695C83C9FD817DE02A6 > > which does match the certificate just at the moment, but will promptly > break in ~60 days when the next Let's Encrypt certificate rollover > happens. > >> depth = 0 >> Issuer CommonName = Let's Encrypt Authority X3 >> Issuer Organization = Let's Encrypt >> notBefore = 2020-02-12T23:29:02Z >> notAfter = 2020-05-12T23:29:02Z >> Subject CommonName = smtp.killian.com >> cert sha256 [nomatch] <- 3 0 1 >> ca2be3cf3e0f13fec3860bc6a54a21f3d51deea640fe8695c83c9fd817de02a6 >> pkey sha256 [nomatch] <- 3 1 1 >> b7f1cd36893e5a884a3c4c70853e87089ea8b65e07c9c7996181d1b3b48ceb39 > This is why the right TLSA RR type to use with Let's Encrypt is "3 1 1" > (pinning the key, not the certificate), and by using > > certbot renew --reuse-key > > the "3 1 1" record continues to work across certificate rollovers, > but even then, before implementing DANE: > > 1. Impelement monitoring, so that if your setup breaks, you'll > know it before I do. > > 2. Automate a robust cert/key rollover process. See suggested > "3 1 1 + 3 1 1" approach or "3 1 1 + 2 1 1". >
