On Fri, Dec 08, 2023 at 01:59:33PM -0500, Viktor Dukhovni wrote:
It now turns out that they will also be switching to new underlying intermediate CAs. So you'll a random choice of *new* issuers.
https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/L7XoAXt_s1c/m/k_vdk9rQAwAJ - We will be generating 5 RSA and 5 ECDSA intermediates, instead of 2 each. We plan to automatically rotate issuance between multiple intermediates for improved redundancy. - We will be shortening their validity period from 5 years to 3 years, to reflect our commitment to issue new intermediates every 2 years.
So anyone relying on DANE-TA(2) (certificate usage 2) needs to closely watch for upcoming announcements from LE, and be prepared to add TLSA records for the new intemediates soon. Or stop playing their game, and switch to a robust "3 1 1" + "3 1 1" model with a stable by default key during certificate renewals.
This has now (as of 2024-06-06) taken place, and I'm starting to see Let's Encrypt certificates from R10, R11, E5 and E6, and of course one's TLSA published TLSA RRset should always include the backup issuers.
However, it is possible to publish TLSA RRs that match just the "R*" CAs when you have RSA keys, or just the "E*" CAs for ECDSA keys. But don't forget to take appropriate action before switching algorithms or choosing to have keys/certs for both algorithms.
For more details:
- https://dnssec-stats.ant.isi.edu/~viktor/x3hosts.html
It is sadly again the case that some MTA operators employ "fire and forget", with no active monitoring, and no keeping up with service announcements from Let's Encrypt. They then end up upon automated renewal with a certificate chain that does not match their TLSA records, and so a partial outage.
With a bit of care, one can instead publish TLSA records matching one of the "ISRG X1" or "ISRG X2" roots, but one then has to carefully ensure that the root CAs ore appended to the server's chain file (not the case with, e.g., certbot), so the ACME chain file may require post-processing before it is configured as the MTA's certificate chain.
Of course that's still not safe to then indefinitely ignore, even the roots are subject to occasional bitrot. Only "3 1 1" records are under your control and change only when *you* decide to switch to new keys.
Hence, my best advice is to stop playing Let's Encrypt whack-a-mole, and use "3 1 1" records with stable keys (not automatically replaced with every renewal). You should choose when to rekey, and prepublish matching TLSA records before you do so:
- https://mail.sys4.de/pipermail/dane-users/2018-February/000440.html - https://github.com/tlsaware/danebot
And of course, DO NOT forget monitoring. Perhaps via:
- https://list.sys4.de/hyperkitty/list/dane-users@list.sys4.de/thread/NKDBQABS...