yacinechaouche at yahoo.com writes:> Interesting. Is there any particular benefit in having only one file > for both certificate and private key ? I find that putting private key > in a separate file feels more secure.It's convenient to have key and cert in one place if you don't need the certificate to be publically readable. Keeping it in separate files would add slightly more security (defense in depth), that would protect from, for example, an admin fumble or bug in the SSL library. "Michael A. Peters" <mpeters at domblogger.net> writes:>> 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.It's on my to-do list, but I think you can use dehydrated in signing mode. --signcsr (-s) path/to/csr.pem Sign a given CSR, output CRT on stdout (advanced usage) In this way, you can reuse private key, as well as making it more secure by removing a privileged operations (private key acces) allowing dehydrated to be run as a non-privilged/separate user. Joseph Tam <jtam.home at gmail.com>
> On Feb 20, 2017, at 4:01 PM, Joseph Tam <jtam.home at gmail.com> wrote: > > yacinechaouche at yahoo.com writes: > >> Interesting. Is there any particular benefit in having only one file >> for both certificate and private key ? I find that putting private key >> in a separate file feels more secure. > > It's convenient to have key and cert in one place if you don't need > the certificate to be publically readable. Keeping it in separate > files would add slightly more security (defense in depth), that would > protect from, for example, an admin fumble or bug in the SSL library. > > "Michael A. Peters" <mpeters at domblogger.net> writes: > >>> 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. > > It's on my to-do list, but I think you can use dehydrated in signing > mode. > > --signcsr (-s) path/to/csr.pem Sign a given CSR, output CRT on stdout (advanced usage) > > In this way, you can reuse private key, as well as making it more > secure by removing a privileged operations (private key acces) allowing > dehydrated to be run as a non-privilged/separate user.You might want to check out this blog: http://www.internetsociety.org/deploy360/blog/2016/03/lets-encrypt-certificates-for-mail-servers-and-dane-part-2-of-2/ <http://www.internetsociety.org/deploy360/blog/2016/03/lets-encrypt-certificates-for-mail-servers-and-dane-part-2-of-2/> The author outlines a procedure for using DANE and Let?s Encrypt automatically generated certs in production. I don?t really know much about DANE, but those wanting to implement it with free certs might want to check out this blog. Kevin
On Thu, 23 Feb 2017, KT Walrus wrote:>> It's on my to-do list, but I think you can use dehydrated in signing >> mode. >> >> --signcsr (-s) path/to/csr.pem Sign a given CSR, output CRT on stdout (advanced usage) >> >> In this way, you can reuse private key, as well as making it more >> secure by removing a privileged operations (private key acces) allowing >> dehydrated to be run as a non-privilged/separate user. > > You might want to check out this blog: > > http://www.internetsociety.org/deploy360/blog/2016/03/lets-encrypt-certificates-for-mail-servers-and-dane-part-2-of-2/This was exactly the type of procedure I wanted: persistent key that can be protected.> The author outlines a procedure for using DANE and Let?s Encrypt > automatically generated certs in production. I don?t really know much > about DANE, but those wanting to implement it with free certs might > want to check out this blog.I don't use DANE either, but it looks fraught with stale-cache peril. If DANE with rotating keys is your thing, I would lower the DANE record TTL to something small like 60s one TTL period before cert renewal, then set it back after cert renewal. Some DNS software will auto-decrement TTL to expire at a certin time, then transition to the new definition. Joseph Tam <jtam.home at gmail.com>