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".
--
Viktor.
