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/HESAY65XEKEW52UXYFELODTD44P25VIW/
https://list.sys4.de/hyperkitty/list/dane-users@list.sys4.de/message/GLRVY2CRHYLTBNXOBRKPG7LFZKYWF7BS/
https://list.sys4.de/hyperkitty/list/dane-users@list.sys4.de/message/X4SS2EEDGIYVQOHI2ZX65PIBYR652DPR/ ]
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-records-with-le-certificates/7022/17
- 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/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@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
<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/HESAY65XEKEW52UXYFELODTD44P25VIW/
https://list.sys4.de/hyperkitty/list/dane-users@list.sys4.de/message/GLRVY2CRHYLTBNXOBRKPG7LFZKYWF7BS/
https://list.sys4.de/hyperkitty/list/dane-users@list.sys4.de/message/X4SS2EEDGIYVQOHI2ZX65PIBYR652DPR/ ]
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-records-with-le-certificates/7022/17
- 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/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@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/