The DANE/DNSSEC survey (https://stats.dnssec-tools.org) has seen a recent spike in the number of MX hosts whose "2 1 1" TLSA records no longer match their certificate chain. The records in question all shar the same digest value, for various TLSA base domains:
_25._tcp.mx1.example. IN TLSA 2 1 1 0b9fa5a59eed715c26c1020c711b4f6ec42d58b0015e14337a39dad301c5afc3
I was initially puzzled as to why this might be happening, but then it occurred to me that the reason why is clear.
The above hash is the hash of the ISRG X1 root CA key, but it is also of course the key hash of its outdated **cross-certificate** issued by DST. That DST cross cert was needed for compatability with some old Android systems that did not get root CA updates (or updates of any kind).
It must be that Let's Encrypt finally stopped by default including that cross certificate in their chains. So instead of a chain that looks like:
- depth 0: EE (server) certificate - depth 1: Let's Encrypt R3/E1 issuer CA - depth 2: ISRG X1 cross cert issued by DT
with the certificate at depth 2 matching the TLSA record, they now generate just:
- depth 0: EE (server) certificate - depth 1: Let's Encrypt R3/E1 issuer CA
with the ISRG (now standalone) root CA not included in the chain!
Leaving out the root CA works fine for WebPKI, where clients need to have a locally trusted copy of the root, but not for certificate usage DANE-TA(2), which does not rely on any local CA store:
https://dane.sys4.de/common_mistakes#4 https://datatracker.ietf.org/doc/html/rfc7672#section-3.1.2
Bottom line, if you're relying on that "2 1 1" record matching the ISRG root to match your Let's Encrypt chain, you're about to be disappointed, if you aren't already. See:
http://dnssec-stats.ant.isi.edu/~viktor/x3hosts.html
for better alternatives, or switch to "3 1 1", perhaps with the aid of "danebot" (still hoping some early adopters will pitch in to further improve it, to support some additional workflows):
https://github.com/tlsaware/danebot