On Mon, Aug 26, 2024 at 02:01:04AM -0400, pgnd wrote:
Note also that the "ISRG X1" or "ISRG X2" root CA cert (whichever is the issuer of your intermediate CA cert) is not included in your server certificate chain file, so the TLSA records for these won't work with at least the DANE TLSA code in Postfix and Exim and likely other MTAs.
My Postfix config has
smtpd_tls_chain_files = /sec/ssl/le/deploy/deploy/${v_MY_DOM}/priv.ec.key, /sec/ssl/le/deploy/deploy/${v_MY_DOM}/fullchain.ec.crt.pem, /sec/ssl/le/deploy/deploy/${v_MY_DOM}/priv.rsa.key, /sec/ssl/le/deploy/deploy/${v_MY_DOM}/fullchain.rsa.crt.pem
where LE's fullchain certs are the usual concat of my dom's cert.pem with their intermediate cert chain. So, as said, NOT including the X1 and X2 root certs.
Right, the "fullchain" files are not as full as they could be.
My understanding of the "3 1 2" records is that the inclusion of the X1/X2 root certs is _not_ required.
Yes, matching TLSA "3 X X" records are sufficient, and don't require anything more in the chain, and are immune from certificate expiration and even matching SAN requirements. So they are the least fragile option provided your certificate rollover process keeps the keys stable, or prepublishes the next key well before rollover.
and that your warning is re: the "2 1 1" use case. correct?
Yes.
My intention is to verify i've got my "3 1 2" setup working after monkeying with it, and unpublish the "2 1 1" records.
That will improve security (avoids trust in weak DV cert issuance), and provided you have good monitoring, and a robust "3 1 1 + 3 1 1" rollover process (when changing keys), you should be all set.
thx for the reminder re: self-checking with danesmtp!
Monitoring is not optional. If you've deployed DANE TLSA records for your server, and are not monitoring them, you're not doing yourself or anyone else a favour, the records will at some point break, and both senders and your users will be unhappy.
If you make non-trivial improvements in the danesmtp() bash function, please share.