On 02/19/2017 05:39 AM, KT Walrus wrote:>> That's one of the reasons I don't like Let's Encrypt, with one year certs it is easier to look at the certs and see what is going to expire in the coming month needing a new private key. > > I use dehydrated (with Cloudflare DNS challenges) and as far as I know, it seems to generate a new private key every time.Yeah that would be a problem for me because I implement DANE. Every time I change the private key - A) I have to make a TLSA record for the new key B) I have to let that key propagate in DNS while the old cert is active. I use 8 hour TTL for DNS records, so that takes 16 hours (twice the TTL) C) Then I can switch to the new key / cert in the server. I use TLSA records for everything TLS, even dovecot - despite the fact I am not aware of any IMAP clients that will validate via DANE - because it is the right thing to do and sooner or later IMAP clients will support DNSSEC and DANE. Having to do that every three months for every service I run, I really do not see what real world benefit I or my users would gain.
On 02/19/2017 08:39 PM, Michael A. Peters wrote:> Every time I change the private key - > > A) I have to make a TLSA record for the new keyYou're actually expected to pin the CA in your TLSA record, not your own key. https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022 http://www.internetsociety.org/deploy360/blog/2016/01/lets-encrypt-certificates-for-mail-servers-and-dane-part-1-of-2/ https://www.internetsociety.org/deploy360/blog/2016/03/lets-encrypt-certificates-for-mail-servers-and-dane-part-2-of-2/ I had the privilege of being auto-yelled at by Viktor Dukhovni over forgetting to adjust my TLSA after changing certificates for SMTP. I would however prefer to automate the process of pushing new TLSA records, waiting out twice the TTL and then pushing the certificate. Going through this every time would ensure I have valid records every time, without having to worry about the CA key changing. This is on my to-do list, for SMTP, XMPP, IMAP etc.
What is the motivation behind using a new pair of keys and CSR ?
On 02/20/2017 01:32 AM, chaouche yacine wrote:> What is the motivation behind using a new pair of keys and CSR ? >Every now and then, a bug in the OpenSSL API is found that leaked the private key under certain conditions. By replacing the private key once a year with a new one, you are at lower risk of having a private key that is exposed by such a bug even if the bug isn't published and only a few know about it. heartbleed was one such bug, DROWN was another. Obviously when a bug of that type is found and reported and your server was potentially vulnerable you change right away - but when you use the same private key for a long time, you risk a scenario where the NSA knew about it, you stopped using the protocol or cipher before it became public, it becomes public several years later but you aren't worried because you haven't run that protocol or cipher suite in quite some time - yet the NSA already has your private key from years ago. That's why I always generate new private key once a year. It just reduces exploitable exposure in the unlikely but possible scenario that the private key was compromised and I did not know it. That's also why I only allow ciphers that use forward secrecy for connections from mail clients.