@jsha if I include some LE config in my server deployment scripts (cloud-init etc.), should I pass around account private keys when spooling up a new server, or is it OK to abandon them, generate new ones, and re-validate each domain?
I understand there are rate limits, but exclude this at the moment.
First, I would encourage you to separate issuance from deployment in your scripts. In other words, if you have multiple servers for the same name, each server shouldn’t issue itself a cert on spinning up: instead you should keep the most recent certificates and private keys regularly backed up, and copy them to new server instances when you deploy to them. That way, if Let’s Encrypt has an outage at the same time you need to deploy, your deploy will not be broken. Relatedly, there is no SLA on time-to-issue. While we intend to keep it low, if you make your deploys dependent on LE issuance, there may be delays during validation and issuance.
With that said: It’s somewhat OK to abandon accounts. Let’s Encrypt does not forbid it in the Subscriber Agreement, and we recognize situations where it may be convenient to create new accounts rather than hanging on to account credentials. Here are a couple of small reasons why it may be advantageous to keep, rather than abandon accounts:
If you need to change your email address, having a single account allows you to do it once rather than tracking down multiple account keys.
In the future, we may implement the Proof of Possession challenge documented in the ACME spec. In this case, using an account that already issued a certificate for a given domain name would be more convenient, because you would not need to prove possession of that certificate’s private key.