On Wed, Nov 15, 2023 at 09:44:18PM +0900, Byung-Hee HWANG via Postfix-users wrote:
> > 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> > > Thank you for notifying us. Also i'm using 211 TLSA record. > > Honestly, 311 it was not easy to set up to me. Your TLSA record specifies the intermediate R3 issuer, not the ISRG X1 root, so you won't be affected by the upcoming change: doraji.xyz. IN MX 1871 yw-0919.doraji.xyz. doraji.xyz. IN MX 1895 yw-1204.doraji.xyz. _25._tcp.yw-0919.doraji.xyz. IN CNAME rfc7671.doraji.xyz. _25._tcp.yw-1204.doraji.xyz. IN CNAME rfc7671.doraji.xyz. rfc7671.doraji.xyz. IN TLSA 2 1 1 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d you should, however, in that case list not just the "R3" CA, but also its backup R4, and probably also E1 and E2, as recommended at the above link. Also, if you're monitoring your MTAs to regularly check that the TLSA records match the chain, and alerting someone who can fix the problem if not, then your setup is "too easy". Don't deploy DANE if you're not able to monitor it properly. See: https://mail.sys4.de/pipermail/dane-users/2018-February/000440.html You should also have code that prevents deployment of new certificate chains that don't match the published TLSA records, and instead sticks with the current chain. This works best with "3 1 1", which is not subject to expiration, though given LE automated renewal after 60 days, but a 90 day cert lifetime, you'd have 30 days to address any issues, if the mismatch for the new chain is reported to the operator. This approach is taken in: https://github.com/tlsaware/danebot which does scheduled key rollovers only once the matching TLSA RR has been in place for at least 2 days. I'm requesting early adopter help to add polish to "danebot" particularly with regard to also being able to change the list of requested domains, and run "hooks". If you're adept at writing robust "bash" shell scripts, please give it a go. Perhaps danebot could also be extended to work with not just "certbot" but also other ACME clients. -- Viktor. _______________________________________________ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
