Change of server and hoster, need to regenerate all or juste copy / paste?


#1

Hello there,

Here is the thing. With your help (still very grateful for this, worked like a charm following your advice), i generated many letsencrypt certificates for a few websites hosted on a VPS with nginx.
Currently a few issues with my hoster (LWS, not to recommend them …), i will for sure change it in a few days, certainly for another VPS still on debian with nginx.
Here is the question : should i regenerate all my certificates, or can i just copy / paste them to the new server ?
Thanks for your help !
Oliv.


Change of server and hoster, what is the best way?
#2

@Olif, if your settings are otherwise exactly the same, it should work to rsync over your /etc/letsencrypt directory (also be aware about the need to create a cronjob to perform renewal, and that if you have an older version of Certbot on the new host, it might have trouble with the renewal configuration files from the old host).

However, the old host would have had access to your private keys so you could also imagine a security argument for starting from scratch with keys that only the new host can see, to reduce the number of people, organizations, and servers trusted with access to key material.


#3

Hello,
Thanks for this answer. A few more questions, so :

  • my nginx settings should be exactly the same, yes. That’s the objective, at least :wink:
  • fine for cron jobx for renewal
  • Will be same or newer certbot version, no problem on that
  • but, why rsync ? Is there obligation here, or a simple ssh transfer through a Windows computer, then send back still via ssh can make the deal ?
  • and about your last point, those certificates will be fastly deleted from old server, so no probleme here, right ?
    Both are VPS, so i have “total” contrôl over them, according to your answer and my understanding of it, might be fine on all points, yes ?
    Thx.

#4

It’s just a common tool for transfers. It uses SSH for the connection, so it’s secured. You can probably do it the way you suggested, too. The important part is to make sure that you keep the key secure when transferring it.

But does the host have access too? It comes down to how much you trust that the keys are still okay and that the hosting company won’t mess with them. One argument is that since you’ve had issues with them, it may not be the safest thing to use security keys to which they possibly had access. The other argument is that they probably won’t do anything malicious and probably don’t have the data, so it’s safe to continue use until the renewal period. The choice comes down to how paranoid you are and how cautious you want to be.


#5

Perfect, you confirm my thoughts on every point, so i’m fine.
Concerning the hoster point, i think (and hope for them) they have better things to do than stealing my certificates for bad usages … And i’m totally not paranoid (maybe even not enough), so i’ll do it this way. Thanks a lot for all these information.
Olivier.


#6

To go a bit further into the “why rsync” question, some of the files are not actual files but rather symlinks to other files in a different subdirectory of /etc/letsencrypt. Copying the files via things like ssh/scp - especially with an intermediary step on Windows - runs the risk of replacing those symlinks with the actual file contents, which would likely break your next renewal (possibly in non-obvious ways). Things like file permissions/ownerships are also highly relevant for private keys (you wouldn’t wanna make those world-readable). Using rsync -a would be the best approach here, as it preserves permissions and symlinks. If rsync -a is not a possibility in this instance, I’d personally just re-issue rather than attempt to rebuild the symlinks and permissions manually.


#7

I agree with @pfg here: if the symlinks get broken then you won’t be able to renew existing certificates with Certbot (and unfortunately, depending on the nature of the breakage, there’s a slight chance that it might even crash rather than simply moving on to other certificates).


#8

Ow yes, didn’t think of those rights and symlinks issues :slight_frown:
Good point for you.
If i decide to generate new certificates for those domains and subdomains on my new server, will i be annoyed by the Letsencrypt limitations (remembering, 5 certs a week, and so on … ) ?
Or, as those domains and subdomains yet possess certificates (on another server), will this be considerered as some sort of renewal ?


#9

@Olif, if these are your only certificates, then the renewal exemption means you will not be blocked from renewing them, as long as you don’t make more than 5 identical certificates in a single week. Getting a new certificate for identical names would count as a renewal.

These renewals can count against limits that apply to other new certificates that you get. The rate limits are described at

https://letsencrypt.org/docs/rate-limits/


#10

OK, so just to be sure to well understand what you mean, as long as i only ask certificates for existing domains / subdomains on which i already have a running certificate, no problem ?
The only problem might appear if i ask for certificates for new subdomains, and ask for more than 5 of them a week (which i won’t currently do, no need for that) ?


#11

That is true.

The 5 a week number is actually referring to something else here (copies of the same cert). A different limit applies to certificates for new subdomains.

Maybe the best thing to say is: when you do need to get certificates for new subdomains, read the rate limit documentation again to understand how it will apply to that task. :slight_smile:

If you don’t want to read the documentation, two tips for getting as many certs as possible while decreasing your likelihood of running into the problem:

  • If possible, get new certs in a different week from renewal and/or get batches of new certs in different weeks from each other
  • If possible, get new certs before renewing old certs, rather than the other way around

All of the details are spelled out in the rate limit documentation and we’re also happy to answer questions on the forum about specific scenarios.


#12

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.