Re: Problem with Let's Encrypt Certificate
yacinechaouche@yahoo.com writes:
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@domblogger.net> writes:
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@gmail.com>
You might want to check out this blog:
http://www.internetsociety.org/deploy360/blog/2016/03/lets-encrypt-certifica... <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:
This was exactly the type of procedure I wanted: persistent key that can be protected.
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@gmail.com>
participants (2)
-
Joseph Tam
-
KT Walrus