[pfx] Re: TAKE NOTE: "2 1 1" TLSA records vs. apparent change of Let's Encrypt default certificate chain

[Byung-Hee HWANG via Postfix-users]

Ralph Seichter via Postfix-users  writes:

> * Byung-Hee HWANG via Postfix-users:
>
>> Honestly, 311 it was not easy to set up to me.
>
> These days, one is a bit spoiled for choice when it comes to software
> which handles this automatically. LetsDNS (https://letsdns.org) is what
> I use and recommend, unsurprisingly, because it is robust and easy to use.

If i have some trouble with 211, someday far later, i will check it.
Thanks Ralph ^^^


Sincerely, Byung-Hee

-- 
^고맙습니다 _布德天下_ 감사합니다_^))//
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: TAKE NOTE: "2 1 1" TLSA records vs. apparent change of Let's Encrypt default certificate chain

[Ralph Seichter via Postfix-users]

* Byung-Hee HWANG via Postfix-users:

> Honestly, 311 it was not easy to set up to me.

These days, one is a bit spoiled for choice when it comes to software
which handles this automatically. LetsDNS (https://letsdns.org) is what
I use and recommend, unsurprisingly, because it is robust and easy to use.

-Ralph
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: TAKE NOTE: "2 1 1" TLSA records vs. apparent change of Let's Encrypt default certificate chain

[Byung-Hee HWANG via Postfix-users]

Hellow raf,

> As Viktor pointed out, you're not affected,

Welcome! And thanks a lot for confirmation.

> but if you want to use "3 1 1",
> and you use certbot for your LetsEncrypt certificates, as well as Viktor's
> danebot program (https://github.com/tlsaware/danebot), my danectl program
> makes it easy (https://github.com/raforg/danectl).
>
> With danectl, you still have to publish/remove the DNS records it tells you 
> to,
> but it comes with a couple of DNS output adapters to help (for Bind9 zonefiles
> and for nsupdate). I'm happy to add more DNS output adapters if anyone needs
> them (and can supply it or help me write and test it).
>
> It seems there's another danebot program (https://github.com/stuvusIT/danebot)
> that (only) works with nsupdate. I don't know enough about it to recommend it
> or not.

If i have some problem with 211, then i will try again to 311.

Many many thanks!

Sincerely, Byung-Hee

-- 
^고맙습니다 _布德天下_ 감사합니다_^))//
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: TAKE NOTE: "2 1 1" TLSA records vs. apparent change of Let's Encrypt default certificate chain

[raf via Postfix-users]

On Wed, Nov 15, 2023 at 09:44:18PM +0900, Byung-Hee HWANG via Postfix-users 
 wrote:

> Thank you for notifying us. Also i'm using 211 TLSA record.
> 
> Honestly, 311 it was not easy to set up to me.
> 
> Sincerely, Byung-Hee

As Viktor pointed out, you're not affected, but if you want to use "3 1 1",
and you use certbot for your LetsEncrypt certificates, as well as Viktor's
danebot program (https://github.com/tlsaware/danebot), my danectl program
makes it easy (https://github.com/raforg/danectl).

With danectl, you still have to publish/remove the DNS records it tells you to,
but it comes with a couple of DNS output adapters to help (for Bind9 zonefiles
and for nsupdate). I'm happy to add more DNS output adapters if anyone needs
them (and can supply it or help me write and test it).

It seems there's another danebot program (https://github.com/stuvusIT/danebot)
that (only) works with nsupdate. I don't know enough about it to recommend it
or not.

cheers,
raf

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: TAKE NOTE: "2 1 1" TLSA records vs. apparent change of Let's Encrypt default certificate chain

[Viktor Dukhovni via Postfix-users]

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):
> >
> >
> 
> 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

[pfx] Re: TAKE NOTE: "2 1 1" TLSA records vs. apparent change of Let's Encrypt default certificate chain

[Geert Hendrickx via Postfix-users]

On Wed, Nov 15, 2023 at 10:29:41 -0500, James Cloos via Postfix-users wrote:
> LE announced a while back that they would not renew the cross cert.


Yes, but dropping the cross-signed X1 root cert from the default chain
last week was an accident:
https://community.letsencrypt.org/t/shortening-the-lets-encrypt-chain-of-trust/201580/2

They plan to stop providing the cross-signed "long chain" by default
in February 2024, and completely in June, as the cross-sign expires
in September.  Dropping it last week was unintended.


Geert


> Their root was expiring and they chose not to pay for a cross for
> the replacement.
> 
> -JimC
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: TAKE NOTE: "2 1 1" TLSA records vs. apparent change of Let's Encrypt default certificate chain

[James Cloos via Postfix-users]

LE announced a while back that they would not renew the cross cert.

Their root was expiring and they chose not to pay for a cross for
the replacement.

-JimC
-- 
James Cloos  OpenPGP: 0x997A9F17ED7DAEA6
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: TAKE NOTE: "2 1 1" TLSA records vs. apparent change of Let's Encrypt default certificate chain

[Byung-Hee HWANG via Postfix-users]

Hellow Viktor,

Viktor Dukhovni via Postfix-users  writes:

> The DANE/DNSSEC survey () has seen a
> recent spike in the number of MX hosts whose "2 1 1" TLSA records no
> longer match their certificate chain.  The records in question all
> shar the same digest value, for various TLSA base domains:
>
> _25._tcp.mx1.example. IN TLSA 2 1 1 
> 0b9fa5a59eed715c26c1020c711b4f6ec42d58b0015e14337a39dad301c5afc3
>
> I was initially puzzled as to why this might be happening, but then
> it occurred to me that the reason why is clear.
>
> The above hash is the hash of the ISRG X1 root CA key, but it is also of
> course the key hash of its outdated **cross-certificate** issued by DST.
> That DST cross cert was needed for compatability with some old Android
> systems that did not get root CA updates (or updates of any kind).
>
> It must be that Let's Encrypt finally stopped by default including that
> cross certificate in their chains.  So instead of a chain that looks
> like:
>
> - depth 0: EE (server) certificate
> - depth 1: Let's Encrypt R3/E1 issuer CA
> - depth 2: ISRG X1 cross cert issued by DT
>
> with the certificate at depth 2 matching the TLSA record, they now
> generate just:
>
> - depth 0: EE (server) certificate
> - depth 1: Let's Encrypt R3/E1 issuer CA
>
> with the ISRG (now standalone) root CA not included in the chain!
>
> Leaving out the root CA works fine for WebPKI, where clients need to
> have a locally trusted copy of the root, but not for certificate usage
> DANE-TA(2), which does not rely on any local CA store:
>
> https://dane.sys4.de/common_mistakes#4
> https://datatracker.ietf.org/doc/html/rfc7672#section-3.1.2
>
> 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):
>
>

Thank you for notifying us. Also i'm using 211 TLSA record.

Honestly, 311 it was not easy to set up to me.


Sincerely, Byung-Hee

-- 
^고맙습니다 _布德天下_ 감사합니다_^))//
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org