On Thu, May 18, 2023 at 09:11:41AM -0400, Viktor Dukhovni via Postfix-users <postfix-users@postfix.org> wrote:
> On Thu, May 18, 2023 at 09:22:34PM +0900, Byung-Hee HWANG via Postfix-users > wrote: > > > And now i added TLSA record for only *outbond* smtp server, > > <yw-1204.doraji.xyz>. > > It is also your secondary MX host: > > https://stats.dnssec-tools.org/explore/?doraji.xyz > > the primary MX host does not yet have TLSA records. The detailed > status is: > > 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 TLSA ? ; NXDOMAIN > _25._tcp.yw-1204.doraji.xyz. IN TLSA 3 1 1 > b4b06c36727808cb3e272f438cc6f1a77ee370c50dfb24eb5774a6113e4c6c0f > yw-1204.doraji.xyz[185.17.255.72]: pass: TLSA match: depth = 0, name = > yw-1204.doraji.xyz > TLS = TLS13 with AES256GCM-SHA384,X25519,PubKeyALG_RSA > name = yw-1204.doraji.xyz > depth = 0 > Issuer CommonName = R3 > Issuer Organization = Let's Encrypt > notBefore = 2023-03-20T06:03:54Z > notAfter = 2023-06-18T06:03:53Z > Subject CommonName = yw-1204.doraji.xyz > pkey sha256 [matched] <- 3 1 1 > b4b06c36727808cb3e272f438cc6f1a77ee370c50dfb24eb5774a6113e4c6c0f > depth = 1 > Issuer CommonName = ISRG Root X1 > Issuer Organization = Internet Security Research Group > notBefore = 2020-09-04T00:00:00Z > notAfter = 2025-09-15T16:00:00Z > Subject CommonName = R3 > Subject Organization = Let's Encrypt > pkey sha256 [nomatch] <- 2 1 1 > 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d > depth = 2 > Issuer CommonName = DST Root CA X3 > Issuer Organization = Digital Signature Trust Co. > notBefore = 2021-01-20T19:14:03Z > notAfter = 2024-09-30T18:14:03Z > Subject CommonName = ISRG Root X1 > Subject Organization = Internet Security Research Group > pkey sha256 [nomatch] <- 2 1 1 > 0b9fa5a59eed715c26c1020c711b4f6ec42d58b0015e14337a39dad301c5afc3 > yw-1204.doraji.xyz[2a03:ebc0:5000:12::10]: pass: TLSA match: depth = 0, > name = yw-1204.doraji.xyz > TLS = TLS13 with AES256GCM-SHA384,X25519,PubKeyALG_RSA > name = yw-1204.doraji.xyz > depth = 0 > Issuer CommonName = R3 > Issuer Organization = Let's Encrypt > notBefore = 2023-03-20T06:03:54Z > notAfter = 2023-06-18T06:03:53Z > Subject CommonName = yw-1204.doraji.xyz > pkey sha256 [matched] <- 3 1 1 > b4b06c36727808cb3e272f438cc6f1a77ee370c50dfb24eb5774a6113e4c6c0f > depth = 1 > Issuer CommonName = ISRG Root X1 > Issuer Organization = Internet Security Research Group > notBefore = 2020-09-04T00:00:00Z > notAfter = 2025-09-15T16:00:00Z > Subject CommonName = R3 > Subject Organization = Let's Encrypt > pkey sha256 [nomatch] <- 2 1 1 > 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d > depth = 2 > Issuer CommonName = DST Root CA X3 > Issuer Organization = Digital Signature Trust Co. > notBefore = 2021-01-20T19:14:03Z > notAfter = 2024-09-30T18:14:03Z > Subject CommonName = ISRG Root X1 > Subject Organization = Internet Security Research Group > pkey sha256 [nomatch] <- 2 1 1 > 0b9fa5a59eed715c26c1020c711b4f6ec42d58b0015e14337a39dad301c5afc3 > > Since your certificate is from Let's Encrypt, you've probably configured > automatic renewal. If you haven't also implemented *monitoring* of your > DANE TLSA configuration that checks whether the TLSA records match the > certificate chain, you should do that immediately, and ideally before > publishing TLSA records for any servers carrying "non-test" traffic. > > You can publish TLSA records for some test host with a self-signed > cert, and check monitoring detects incorrect TLSA records when > mismatched TLSA records are configured (and is not complaining > when the TLSA records are correct). With my danectl program, TLSA monitoring is a cronjob: danectl check If you have done a key rollover, but you haven't updated the TLSA records yet, it'll report (in zonefile format) that the old "current" TLSA record needs to be removed from the DNS, and that the new "next" TLSA record needs to be published. Also, if your DNSSEC zones are configured to automatically rollover every so often, you need to set up monitoring for that as well, so that you can communicate the new DS record to your registrar. I'm not sure what the best method for that is. I just wrote and cronned a script to report whenever the output of the following changes: host -t dnskey $domain | sort | grep 'DNSKEY record 257'; \ host -t cds $domain | sort | grep -v 'has no'; \ host -t cdnskey $domain | sort | grep -v 'has no' With BIND, that gives you some time to communicate with your registrar before the new key takes effect. > You then also need to make sure that your certificate rollover process > is robust, and either keeps the public key unchanged, or you pre-publish > matching TLSA records for future keys alongside current keys. > > Setting up inbound DANE requires operational diligence. Do consider > implemting DANE, but not as a fashion statement, rather only because > you understand how to coordinate certificate management with DANE > TLSA record upkeep. > > -- > Viktor. > > P.S. Your certificate chain from Let's Encrypt includes a cross-cert for > the ISRG root from the expired DST root. This is obsolete, if using > "certbot", make sure your "renewal.conf" includes the "reuse_key" and > "preferred_chain" settings below in the "[renewalparams]" setction. > > [renewalparams] > reuse_key = True > preferred_chain = ISRG Root X1 > ... > > adjust accordingly if using some other ACME client. _______________________________________________ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
