> On Jun 7, 2016, at 2:46 AM, Alice Wonder <al...@domblogger.net> wrote:
>
>
> Isn't generally better to use a new private key?
Not if doing so makes it impractical to maintain correct TLSA records.
Specifically, if certificate renewals are frequent and automated, it
becomes difficult to pre-stage new keys and associated TLSA records
in DNS sufficiently far in advance of the actual key rotation. It
also becomes difficult to handle changes in the issuer's public key,
that are transparently handled by retaining the original server key.
Therefore, the best practice is to keep the server key unchanged at
routine/frequent certificate updates, and to replace it less frequently,
when doing manual key rotation.
> The logic I was taught is that the longer your key is in use, the more
> likely someone has had access to it that shouldn't by one means or another.
Let's Encrypt certificates rotate every ~90 days, this is much too often
to replace the key and update the TLSA RRs in DNS each time.
The OP has a 3-year certificate. In his case, updates are likely
manual (not frequent enough for well-tested automation) and such
a key should probably be replaced each time. This complicates
the case when the issuer key is also changing, as having both
change requires DNS updates with additional TLSA RRs prior
to deployment of the new chain, rather than a simple after-the-fact
update when one of the keys is stable.
Bottom line, it's all trade-offs. For email, service availability is
typically more important than minimizing key compromise risk.
--
Viktor.
