Part of setting up and using Let's Encrypt is creating an account, which is really just a public keypair. When I was just starting out with LE and using it on test machines, I was careful to save (and restore) the account information when I reinstalled machines, and I worried about things like how to arrange it so that we'd use the same account on multiple machines. This seemed like the right thing to do and it's certainly what you do with many other services; you really only want to have one account registered with them, not a huge morass of separate registrations from different machines at different times and so on.

I now believe that this is a mistake. The core problem is that authorized accounts have a surprisingly large amount of power. Compromise of an account's keys means that an attacker can get 90-day certificates for any host or domain that the account is authorized for without having to prove they do or still have control over the host, for up to 60 days.

(If the attacker is reasonably clever, you will have real problems getting these certificates revoked.)

So this leads us to the standard security idea of least privilege for your Let's Encrypt accounts. In the LE context, this means that your LE account should have authorization for as few hosts as possible. The best way to get this is to not to carefully reuse LE accounts but instead to make new ones every time you can reasonably separate the security contexts of the two accounts. Do you have ten machines, each getting certificates for a different set of hosts? Then each machine should have its own account, so that compromise of the account only gives (60-day) control over certificates for that set of hosts, not all of your hosts. Are you reinstalling a machine? Deliberately destroy the old account keys, rather than saving and reusing them.

I don't think it's harmful to keep on using the same account (keys) on a single server for a long amount of time, and it's probably more friendly on Let's Encrypt's backend servers and so on. But I now feel that we definitely should not reuse accounts between different machines (including a reinstalled version of the same machine). Conveniently this makes canned setup instructions for Let's Encrypt clients easier, because you don't have to work out how to save and restore account keys; you can just let each client (re)install generate a new account, which pretty much every client is going to have good support for.

Sidebar: Accounts and certificate revocation

If I'm reading the draft protocol specification correctly, you probably don't have to preserve your account key in order to be able to revoke a certificate later. What matters is that you have an account (any account) that is currently authorized for all of the names in the certificate (or that you hold the private key for the certificate itself).

The requirement that you have authorization for all names in the certificate is perfectly reasonable, but it's also going to cause real heartburn for revoking certificates generated from stolen keys. A canny attacker will immediately authorize the account key for some completely unrelated domain, then attach this name to all of the certificates they get. This extra name will block you from revoking these certificates because while you can demonstrate authorization for your own domain(s), you can't get it for this outside domain.

(This also suggests that you should not normally get cross-domain certificates, ones for hosts from multiple (sub)domains, even if you currently control all of the domains. Get separate certificates for the separate domains, just in case, so that if you wind up transferring control of one (sub)domain you don't have certificates that need the cooperation of all parties involved to revoke.)

PS: The usual disclaimers about practical problems with certificate revocation almost certainly apply here. In practice you're probably just going to have to let those 90 days run out on the certificates before they turn off.