I’m trying to understand how to best support migration of a website from one host to another.
My use case is virtual hosting: I have N (lots) of sites on host1, and for capacity reasons, I now like to move siteA from host1 to host2. Once migrated, I want host2’s certbot.timer to auto-renew the migrated site. How would I best do this?
I don’t see any official “export” and “import” functionality. (Site note: maybe there should be?)
In lieu of that, I could simply delete siteA’s existing Letsencrypt certificate on host1, and provision a new one on host2, but for various reasons I’d rather not to (e.g. if something goes wrong, I may need to do that a few times, and Letsencrypt might ban me – that has actually happened during testing and I’d like to avoid that)
So I’m thinking I can copy the files in /etc/letsencrypt/archive/<domain>/ (maybe only the ones with the highest index number?) and recreate the symlinks in /etc/letsencrypt/live/<domain>. I can also probably generate /etc/letsencrypt/renewa/<domain>.conf, but I’m unsure about the the account identifier:
For various reasons including ease of setup, host1 and host2 use, from Letsencrypt’s perspective, different accounts. I can generate the .conf file with host2’s accountid, assuming it has one already, but then: will “renew” work? I’m unclear how exactly Letsencrypt uses accounts anyway: will it, or is it liable to in the future, reject attempts to renew a cert from a different account?
Also, what else might I be missing in this use case?
You could also use --staging or --dry-run for testing (assuming that you just need to test the certificate issuance process, as opposed to creating and destroying instances of the new server in its entirety).
All three of these things are necessary, and Certbot cares about their consistency with one another. You might be able to simplify this process by using something like
rsync -a /etc/letsencrypt/{live,archive,renewal} host2:/etc/letsencrypt
Substituting a new account ID (which is present on host2) is allowable and should work properly for renewals. The Let's Encrypt CA does not require the reuse of the same account for issuing related or overlapping certificates; you can freely use different accounts.
The benefits of reusing the same account are comparatively minor, and include
you can't be affected by rate limits that limit the frequent creation of new accounts
you can be sure that warning messages from Let's Encrypt about expiring certificates will come to the original e-mail address that you specified (although if the e-mail address that you've associated with the new account is the same, there's no benefit to using one account compared to the other)
in some cases, you can skip revalidating your control over some domain names if you reissue certificates that cover those names using the same account within a short time period (I believe it's one week), because of a Let's Encrypt feature called authz reuse—this is mainly beneficial if you're going to reissue several certificates with different combinations of names in order to reorganize them, or if you have large certificates that cover many names and you want to reissue them to add or remove just a few of those names
Using a second account on the second server should be fine in all cases, including for certbot renew renewals, assuming that you do update the account identifier in the renewal configuration files in /etc/letsencrypt/renewal to refer to an account whose credentials are actually present on the new system.
I agree with @schoen (thanks!) that using two ACME accounts in this case seems very reasonable. For larger integrations (e.g. hosting providers, large corporations, etc) we recommend that folks use one shared ACME account because of one other benefit: when we grant rate limit overrides above and beyond the limits listed in our docs we typically do it by ACME account ID. Two servers won't meet the scale that requires that sort of override and shouldn't pose a problem for you.
