On Fri, Dec 08, 2023 at 02:01:30PM -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/NKDBQABSTAAWLTHSZKC7P3HALF7VE5QY/
--
Viktor.
--
## subscription configuration (requires account):
##
https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@???
## Exim details at
http://www.exim.org/
## Please use the Wiki with this list -
http://wiki.exim.org/
