DANE: ATTENTION: Let's Encrypt drops DST X3 from default chain, breaking "depth 2" ISRG "2 1 1" TLSA records...
As of roughly the start of this month, the DANE survey at https://stats.dnssec-tools.org is seeing a steady stream of validation failures for MX hosts that rely only on:
_25._tcp.mail.domain.example. IN TLSA 2 1 1 0b9fa5a59eed715c26c1020c711b4f6ec42d58b0015e14337a39dad301c5afc3
[ Some also list a no-longer valid "3 1 1" record that broke when the unerlying EE key was rotated, because they failed to ensure that certificate renewals do not automatically rotate the key. ]
As promised by Let's Encrypt some months back, Let's Encrypt have dropped the expired DST X3 cross-certificate from the default generated "fullchain.pem" file, which now contains just the leaf (EE) certificate (depth 0) and the intermediate CA (depth 1) issuer (R3, R4, E1 or E2), the parent ISRG root CA is implicit and there's no longer a legacy cross certificate from DST for outdated Android devices.
Domains whose MX hosts relied only on the "2 1 1" record for the ISRG root CA (present in the cross certificate, but absent from the new chain) are no longer passing DANE TLSA validity checks.
My notices to these domains include the below advice:
[ Perhaps consider: https://github.com/tlsaware/danebot?
Your TLSA record designates a root CA key, but, as is common, the root CA certificate is not included in your certificate chain. It would need to be incuded to work with DANE-TA(2), but simpler to use an intermediate CA hash instead. See:
https://github.com/Mailu/Mailu/issues/2138 http://dnssec-stats.ant.isi.edu/~viktor/x3hosts.html https://dane.sys4.de/common_mistakes#4 https://datatracker.ietf.org/doc/html/rfc7671#section-5.2.3
Important information about certificate issuance changes at Let's Encrypt discussed at the links below:
https://list.sys4.de/hyperkitty/list/dane-users@list.sys4.de/message/HESAY65... https://list.sys4.de/hyperkitty/list/dane-users@list.sys4.de/message/GLRVY2C... https://list.sys4.de/hyperkitty/list/dane-users@list.sys4.de/message/X4SS2EE... ]
The issues can be resolved by removing or updating the associated DNS DANE TLSA records.
- "3 0 [12]" vs. Let's Encrypt: https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-r...
- Best practice "3 1 1" rollover methodology: https://mail.sys4.de/pipermail/dane-users/2018-February/000440.html
- Monitoring code snippet: https://list.sys4.de/hyperkitty/list/dane-users@list.sys4.de/thread/NKDBQABS...
participants (1)
-
Viktor Dukhovni