Up until quite recently, I would have confidently told you that I understood the broad flow of how Let's Encrypt's authorization process for getting certificates worked (although not the fine details). It went something like this:

1. you registered an account with Let's Encrypt, giving them a public key along with your ritual agreement to their TOS and perhaps an email address for eg account recovery.

2. using your registered account, you asked Let's Encrypt for a certificate for host or domain X.
3. Let's Encrypt said 'okay, prove that you control domain X' with one of their various challenges.
4. when you'd satisfied the challenge, Let's Encrypt gave you a 90-day certificate back.

When you wanted to renew the certificate, you repeated the second through fourth steps.

It turns out that this is not how the process actually works, and how the process works has some implications. The actual process is clearly documented by Let's Encrypt (and then there's always the more formal version). Instead of the above, the actual process is:

1. register an account with Let's Encrypt.
2. assert to Let's Encrypt that your account controls one or more domains.
3. Let's Encrypt challenges you to prove this, and you satisfy the challenges. Your account is now authorized for those domains.

4. ask Let's Encrypt for a certificate for domains that you're authorized for. Let's Encrypt gives you your 90-day certificate.

When you want to renew a certificate, you repeat step 4 alone.

The important difference is as long as your authorization for a domain remains valid, you don't have to re-prove your control of that domain. Let's Encrypt doesn't require you to go through a challenge, it'll just give you a certificate. Also, the lifetime of the resulting certificates are not limited by the lifetime of the authorization; if you request a new certificate or renew an old one on the last day that an authorization is valid, you still get a 90-day certificate.

(Ask one day later, and you'd have to re-prove your control to create a new authorization before you could get a certificate.)

This means that a compromised account key gives an attacker the ability to get certificates for all domains the account is authorized for, and to do so for as long as those authorizations remain valid. The protocol allows for authorizations to be deactivated (cf), but the clients I looked at don't expose support for this. There's also deactivating an entire account, which is what the current protocol draft recommends in reaction to compromise of the account's key, but the clients I looked at don't seem to support this either.

(There are some indications that this is not yet implemented in LE's server even though it's in the protocol, which would explain why even the official client doesn't support doing this. Possibly LE is rethinking and iterating how they want to do this.)

At the moment, Let's Encrypt appears to be using a 60 day lifetime on domain authorizations (the expiry time is returned in the protocol and at least acmetool saves this information in its on-disk state). The net effect of this is that if you renew certificates after just short of 60 days (when they have just over 30 days left), you will only be challenged to prove domain control once every other certificate renewal, or roughly about once every 120 days. Or maybe less. My own server logs say that I was challenged only twice this year for my personal site, once in February and once in December.

(It's possible that Let's Encrypt shortened the authorization expiry recently.)

I have opinions about what this means for managing Let's Encrypt client setups across multiple machines in your fleet, but that's for another entry.