On Fri, Jan 31, 2020 at 11:06:43AM +0100, Stephan Seitz wrote:
> Since I’m having now DNSSEC I want to use DANE as well.
>
> I have found Viktor’s article
> https://mailarchive.ietf.org/arch/msg/uta/SR2EKnnj8749AtVeIvjEEEXz7fg
> (about web.de) with other links.
>
> My postfix has two certificates/keys (RSA and ECDSA) from Let’s encrypt.
See:
https://mail.sys4.de/pipermail/dane-users/2017-August/000417.html
> It says in the article:
>
> mx.example. IN TLSA 3 1 1 <digest of server public key>
> mx.example. IN TLSA 2 1 1 <digest of immediate issuer public key>
A parallel "3 1 1" is required for each algorithm. More reading material:
https://github.com/internetstandards/toolbox-wiki/blob/master/DANE-for-SMTP-how-to.md
https://mail.sys4.de/pipermail/dane-users/2018-February/000440.html
https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022/17
https://mail.sys4.de/pipermail/dane-users/2017-August/000417.html
https://github.com/baknu/DANE-for-SMTP/wiki/2.-Implementation-resources
> My questions:
> 1. Can I have two „3 1 1” records for RSA and ECDSA?
Yes. And you can also publish dual (current plus next) "3 1 1" RRs for
each algorithm and avoid trusting a 3rd-party CA, with generally weak
domain control validation processes. Which works best for you depends
on what sort of process you feel comfortable implementing.
Whatever you do, implement monitoring first. Unmonitored security is
(or should be) an oxymoron. Then when your monitoring is working and
tested, implement (automate) your preferred key/cert management
approach. The simplest is to just keep using the same key indefinitely,
until you carefully manually replace it some day (3 1 1 + 3 1 1 at that
time).
# certbot renew --reuse-key
> 2. Is „digest of immediate issuer public key” the CA from Let’s encrypt
> Or the „Digital Signature Trust” CA?
The Let's Encrypt one. Most users don't including the root CA in their
server's chain file, and that would be required for "2 1 1" to work for
the root CA (the complete Let's encrypt chain is just leaf + LE + root).
> Would be nice if someone could help me.
I think I'm someone...
--
Viktor.
