> On Apr 25, 2017, at 4:59 PM, G. Schlisio <[email protected]> wrote:
>
>> It is also possible to avoid DANE TLSA changes while rolling over
>> Let's Encrypt keys:
>>
>>
>> http://postfix.1071664.n5.nabble.com/WoSign-StartCom-CA-in-the-news-td86436.html#a86444
>> https://community.letsencrypt.org/t/new-certbot-client-and-csr-option/15766
>>
>> https://www.internetsociety.org/deploy360/blog/2016/03/lets-encrypt-certificates-for-mail-servers-and-dane-part-2-of-2/
>>
>> https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022
>>
>
> Thank you for your hints and sorry for the late followup. busy and stuff.
> thank you for your suggestions, I was aware of the csr-option but wanted
> to avoid this, since it does not well automate with certbot.
Sine "--csr" is a certbot option I am surprised to hear you say that
"it does not automate well". My expectation is that this is fairly
easy to automate. Just generate the CSR from a fixed private key,
and use it instead of having certbot generate a new key and the
corresponding CSR. Perhaps you need help running "openssl req"
in non-interactive batch scripts?
> I came up with another idea, which is pinning the intermediate
> certificate with a 2 1 1 TLSA entry.
That's exactly what I recommend to LE users.
> Even though this is not totally correct (2 means private CA, which is
> not true in this case) it seemed to work.
Actually it is completely correct. Usage DANE-TA(2) just lifts the
requirement of pre-existing client trust of the designated CA. It
is completely valid for the CA in question to also be a public CA
trusted by some clients.
> Do you see any issues with doing this?
None, provided you trust Let's Encrypt to be your CA and to not
issue certificates for your domain to the wrong party.
--
Viktor.
