2023-01-15
Some weird effects you can get from shared Let's Encrypt accounts
Recently on the Fediverse I said:
How Let's Encrypt (well, the ACME protocol) handles proving 'you' have control over a domain when you request a TLS certificate involving it has some interesting potential effects if you move your websites from one machine to another.
(Authorization is tied to a LE account, not a host, and at least used to last for 60 days. If a LE account is shared between hosts, all of them are fishing in the same authorization pool, regardless of who has the website.)
(Per Matthew McPherrin, how long authorizations last is now down to 30 days and may drop further.)
To get TLS certificates from Let's Encrypt, you must create and register an 'account', which is really a keypair and some associated information. The normal practice is to have a separate LE account for each machine that you use to get TLS certificates, and I think this is a good idea, because authorization to issue TLS certificates for a given name is tied to the account, not to a host. If you move a (HTTPS) website from one host to another, there are two interesting effects that can happen.
(I'm supposing here that the old server still keeps operating with some websites.)
Sometimes the easiest approach is to copy /etc/letsencrypt (or the equivalent if you're not using Certbot) from your old multi-website server to the new server that will have some of those websites. This results in your two hosts sharing the same account, which means that each of them can probably get TLS certificates for the merged collection of websites. If you moved website X from host A to host B, host A can't directly get authorized for X any more, but once B gets the shared account authorized, A will be able to renew its TLS certificate for X. If renewals for the TLS certificates are close enough (as they probably will be if you just copied the TLS certificates over), A may fail an initial authentication attempt, but then B will do one and A's attempt to renew the TLS certificate will now work.
(You can also have weirder situations. For example, suppose that you're using the DNS authorization method, and host A has the appropriate permissions to trigger the necessary DNS updates but host B doesn't. In this case it's host B's renewal that may initially fail, then succeed the next time around, after A has authorized the shared account even though it no longer holds the website.)
If you have different Let's Encrypt accounts on the two hosts, you can still potentially have some issues. Back in the days of extended authorization periods (60 days or more), you could get a situation where the old host might be able to automatically renew the moved TLS certificate once, because its authorization was still (just) valid. These days that's harder to contrive in an automatic renewal, but with the right timing you might be able to manually renew or re-issue the TLS certificate for the moved website on the old host for a while after the move.
(For instance, suppose that you force an out of cycle certificate renewal just before the move, which as a side effect gets you a 30 authorization on the old host.)
Both of these cases are of interest to system administrators because they make it look like things are working when in fact they aren't. You just won't find out about the problems for a little while longer (or you're passing the problems off as 'LE renewal glitches, nothing to worry about since they cure themselves in a few days'). Generally if you have separate Let's Encrypt accounts you're more likely to notice real problems, whether those are that host A is still trying to renew the TLS certificate for the moved website or that host B doesn't have the necessary setup to actually prove control.