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>
--
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@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
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>
--
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@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/