Hello,
I know that this question has been asked before, but it hasn’t gotten a clear answer and the topic is locked.
That’s why I’d like to ask if there has been any progress? We are in the process of implementing Let’s Encrypt and need to update our contingency plans but I can’t find any documentation how to handle a compromised account key.
Greetings
I don’t think there were any new proposals, and I would assume not much is going to happen in terms of implementation until after the ACME v2 API becomes available (currently scheduled for January).
You can currently somewhat mitigate this issue by either creating a new account (registration) for each certificate issuance and deactivating the account right after, or by disabling the authorizations you created after the certificate is issued. Not persisting the account key would also be good enough.
I’m not aware of any clients that operate like this or support a flag for this mode of operation. Not persisting the account key might be easy to script with some of the clients that let you provide the path to an account key combined with a RAM disk.
The Client Implementations list does contain a number of libraries in various languages, some of which support the account or authorization deactivation endpoint. Those should help if you chose to implement one of the other approaches.
Hey,
thanks for the response. We’re probably going to disable the authorizations after issuance of the certificate is completed and disable the account key if needed as you suggested.
One more thing I was wondering: Am I correct that the certificate keys do not need to be changed, if only the account key is compromised but the cert keys are safe?
Greetings
You're right. You might want to replace your certificates as a precaution anyway.
Yes, if you are certain that the account key was compromised and nothing else you don’t need to replace other keys. I can imagine this might be the case with inadvertent disclosure, e.g. an employee mistakenly uploads the key to a pastebin.
In many cases where keys are compromised there’s some sort of breach, it is hard to be certain what exactly was taken and it will usually make sense to err on the side of caution. For high security environments the certificate private keys may live in a tamper evident Hardware Security Module, with independent access controls but for most people they’re just files on disk and might be stolen by attackers even if they’re not deliberately targeted.
One thing to keep in mind is that the account key would allow the attacker to revoke your certificates, so while the certificate keys themselves might be safe, you’d want to re-issue the certificates at least to avoid a potential DoS. You could reuse the key, but at that point you might as well rotate them too.
What a thorough set of answers from @mnordhoff, @tialaramex, and @pfg! Thanks, everybody!
Thank you all for your replies! Though we’re not set on a specific solution yet, this helped a lot. 
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.