I'm preparing to migrate the website for the following domain, and need to understand the renewal process for the certificate once it's migrated to the new server.
My tentative plan is to manually copy the existing certificates to /etc/letsencrypt/archive/gnmonlineseminars.com/ et al and make the corresponding symlinks in /live/ to get the webserver delivering the correct certs per usual configuration.
However I'm unclear on the renewal process, and how to ensure auto-renewals take place from the new location. Also in two other cases (gnminstitute.com and edu.gnminstitute.com) I may not have access to the original LetsEncrypt certs in advance of the approaching website migration.
Provided I have the certs in place already, can I simply do sudo certbot renew and expect it will work properly and be setup for future auto-renewals? What if I don't have the original certs from the prior hosting?
My web server is (include version):
old hosting: nginx
new hosting: Apache2
The operating system my web server runs on is (include version):
old hosting: CentOS Linux 7 (Core)
new hosting: Debian GNU/Linux 12
My hosting provider, if applicable, is:
old hosting: Cirrushosting
new hosting: Infomaniak
I can login to a root shell on my machine (yes or no, or I don't know):
yes
I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
old hosting: Plesk
new hosting: command-line (certbot)
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
old hosting: Can't locate version due to Plesk's obfuscation
new hosting: 2.1.0
Why not the entire /etc/letsencrypt/ directory while making sure symlinks are preserved? Is it just a partial migration? I would recommend backing up/copying the relevant /archive/ and /live/ directories and the corresponding renewal configuration file in /renewal/ in one go. Note that the symlinks are relative, so it wouldn't even matter if you'd use a different destination (although I would recommend using /etc/letsencrypt/ as that directory is hardcoded in the renewal configuration file).
What's unclear exactly? If you migrate the relevant files in /etc/letsencrypt/, you could simply continue using the certbot renew command?
Unless you have hundreds of separate certificates for e.g. hundreds of subdomains, you could simply get new certs in the new situation. There is a rate limit of 5 duplicate certs per week, so simply issuing a new (single) cert just once wouldn't be a big deal.
If you migrate /etc/letsencrypt/ correctly (i.e.: don't mess up the symlinks, don't forget the renewal configuration file) and the method of installing your Certbot automatically installs a cronjob/systemd timer: yes. In fact, with a systemd timer/cronjob in place and working certificates migrated over, you wouldn't need to run anything manually. Although I'd recommend running sudo certbot renew --dry-run to make sure everything works correctly.
Just get a new cert, making sure you don't hit rate limits.
The old server is setup using Plesk which doesn't seem to place files all in the same directory structure as is typical of a usual certbot installation. Plesk stores everything under a modules directory and is setup to use it's own internal plugin system. I was only able to locate the certs themselves after a bunch of dead ends and laborious internet searching. I'm not familiar enough with the layout and configuration differences to just copy from one to the other blindly. However I do know that provided I have the correct certificate/chain I can just drop those files into the usual spot and it will work at least until the certs expire. My problem is how to avoid that final outcome.
PS. When you say just get a new cert and make sure to avoid rate limits, do you mean like sudo certbot certonly ....? That will work? Doesn't there have to be a DNS switch first though, and that would leave the site without a valid cert until the re-issue/renewal happens? Is there any way to avoid that?
For Certbot to work, you'd also need to have the renewal configuration files. I'm assuming Plesk doesn't have those? Does Plesk even use Certbot under the hood?
Otherwise the most efficient method would be simply to get new certs on the new hosting to initialize Certbot. You'd need to migrate the Plesk certs/private keys too of course to prevent downtime while the DNS is changed, but that could simply be a temporary location. And when Certbot got the new certs, you could change the webserver configuration to use the new certs. Or use the --apache installer to do all the installing if you're comfortable with that.
Yes, or different Certbot command. Doesn't need to be the certonly subcommand. Whatever you fancy.
Depending on the challenge used it would also work before or indeed only after DNS has been changed to the new server. The dns-01 challenge wouldn't require a webserver, just access to the DNS zone. But the http-01 and tls-alpn-01 challenge would indeed require DNS already set to the new server. See my remark about migrating the Plesk certs/private keys to a temporary location too above to prevent downtime.
Thus far my familiarity ends at shutting down the web-server and running certbot with --standalone. DNS functionality wasn't available when I first began using it. So if it's not too much trouble, would you please provide an example of the DNS challenge command for certbot so I can test on a subdomain I have access to? I will have access to the DNS zones for these sites in advance of migration, so that would ultimately be the ideal registration/renewal method. Especially if it will make the migration process seamless.
Incidentally, it doesn't appear I can obtain the renewal configuration files. So far just the certs. Also in the case of the other two domains, I may not have even that. So I'd like to get the process understood fully before I flip the switch on migrating these sites.
Well, I would if I could, but to be honest, the dns-01 challenge works nicely IF your DNS provider has an API which Certbot can use. Certbot itself doesn't have that much DNS plugins (it does have quite a lot if you´d ask me, but there are unfortunately a LOT more DNS providers out there, so relatively speaking Certbot doesn't have that much plugins..), but a member of the Community and Certbot team has developed a Certbot DNS plugin (certbot-dns-multi) which uses a different ACME client under the hood (lego) which does have a LOT of DNS provider support. Including InfoManiak, which appears to be the DNS providers of one of your sites. The other site you mentioned seems to use "Duplika" which I didn't see on the lego provider list unfortunately.
You could attempt to get a brand new certificate for those sites using the manual plugin using Certbot if automatic use of the dns-01 challenge isn't an option. That would require you to manually put the challenge file on the existing website as a file or manually in the DNS zone (assuming you have manual controle over it). Once you got the certificate on your new host, you could use that to "bootstrap" your new server, including TLS. Once you're satisfied everything works and you change the DNS from old to new, you can reconfigure Certbot to use an automated authenticator plugin (e.g. --apache or --webroot). Note that you need Certbot 2.3.0 or higher to have the reconfigure subcommand and preferably 2.9.0 because there was a bug in reconfigure before. 2.9.0 is the latest version.
Thanks. That's more or less what my experience had been. The Infomaniak support would be helpful, but I think in this case using a container isn't the best situation if at all avoidable. Same with upgrading certbot and maintaining a different installation/version. Also time constraints. So will have to accept the HTTP method by the look of it.
Is there any concern about differing username/email credentials in the case that there was a new registration or renewal from the new location (VPS @ Infomaniak)? Once the DNS changes, will LetsEncrypt just drop the old cert and create a new one from scratch for the new system? I'm not totally clear on the difference between "a brand new certificate" (ie. via certonly?) vs a renewal (presumably of existing/copied certs)? How does LetsEncrypt behave in respect to these situations? I know in the past I've come up against a few quirks like frequency limits (eg. in case of incorrect command/options/etc), and other things which could easily throw a wrench in the wheels.
Basically I guess the process would be something like...
Copy the certs into the right place on the new system.
Configure/test the webserver accordingly.
Change the DNS to the new hosting.
Since renewal is fast pending, then just certbot renew from the new location?
Am I missing something? And if I don't have the certs, can I just certbot certonly as per usual from the new location to create a new cert without any issue?
My understanding is if I use the --manual option, renewals won't be setup for future. If that's true, how would I set them up as usual?
PS. Sorry to pester with so many questions. It's just not something I deal with every day at the moment.
Only if your current account has some "special rights" with regard to rate limit exemptions or the ECDSA allow list.
Not automatically. Certificates can't be "dropped" from a Let's Encrypt point of view: Let's Encrypt has no clue what happens to the issued certificate. Maybe it has been copied thousands of times, maybe it got deleted, the LE ACME server wouldn't be able to know.
And YOU are responsible for getting a new certificate. How would LE be able to do that?
There's technically no difference. Renewals are brand new certificates, but just with the same set of hostnames as a previously issued one. It's just a definition of a cert with specific "rules" we humans have defined. But technically a renewal is nothing more than just a new certificate just like any other. Why would we call something a renewal? So we know what we're talking about (thus a certificate has already been issued once before and the ACME client proooobably still knows how to do that..) and for rate limits.
Rate limits.
Testing should be done on the staging environment to prevent hitting rate limits on the production environment.
In broad terms, sure. With the remarks discussed earlier of course, this is just the big picture. Earlier we've discussed details like copying from non-Certbot to Certbot and the problems with that.
We've also talked about this above already. That depends if the DNS is already set to the new server, which challenge is being used et cetera.
I already mentioned the reconfigure command above.
In respect to registration vs renewal, I just meant how certbot determines that it can issue a new certificate for the same domain name which already has one on another system. I presume if the DNS matches and the cert is close to renewal, it wouldn't matter, but if there's already a valid cert on another host, wouldn't that preclude renewing it on a new host (absent the account/renewal configuration)? For instance with the latter two websites, I may not have the cert to copy to the new hosting, so how could I renew a cert I don't have access to? And if I'm registering it anew for the same domain from the same CA, I'd guess that would implicitly make the old cert invalid would it not? Bottom line is I don't want to fumble and issue the wrong commands when the time comes for lack of understanding certbot/LE's process and safeguards or how to operate certbot properly in the given situations.
For gnmonlineseminars.com , I have the fullchain.pem, chain.pem, cert.pem, and privkey.pem used by Plesk, to my knowledge. For the other two sites, probably nadda.
Without the renewal configurations, I just want to be clear that if I drop those certs in their usual place in /archive/ & /live/ respectively, then do certbot renew that it will work and be setup for future renewals? If there's a process of a couple steps involved, or some specific certbot options needed or other weirdness, I have to be clear on it. It's not my website, so accidental downtime isn't a luxury I can afford in this case.
On my own systems I've generally only had to do this once, and basically set-it-and-forget-it. Ideally I'd like the same situation to be the end result in this case, as I'm just doing what should be a simple website migration and can't be responsible to maintain certs over a longer period.
Unless you copy over configuration files, Certbot X had no clue about any certificate issued by Certbot Y or Certbot Z. Unless you hit a rate limit, Certbot X can issue all the certs it wants, regardless of what was issued elsewhere.
You simply issue a new certificate with the same set of hostnames. To the new Certbot it would be a new cert, to LE it would be a renewal.
...from the new location (as I would usually when creating a new cert), without worrying about having prior certs from old hosting, and it would setup a new cert with auto renewals on the new hosting in perpetuity. And with the other domains likewise.
Is that correct?
If so, would anything about that process be changed by me placing the certs I do have in place temporarily before creating the new cert (ie. to avoid invalid cert during DNS change)?
Yes, it would setup a conf file in /renewal folder for the renew command to use.
Since you chose --standalone that is also saved in the /renewal conf file. So, the renew command will again use --standalone which requires exclusive use of port 80. That is, no other web service can be listening during the certbot renew.
I think --standalone is a poor choice if you plan to run Apache anyway
As for "in perpetuity" ... that's optimistic
Depends how you plan to "bootstrap" Apache. I'd personally copy the cert with chain and private key files to a temp location on new system. A secure one because it has the private key but just not in any /etc/letsencrypt related folder.
Configure Apache to use that temp location for the SSLCertificate statements. Apache won't start with faulty statements and you need something in place to handle HTTPS. If you copy "fresh" certs you will have ample time for the remaining work.
Then use sudo certbot certonly --webroot -w (path) ... instead of --standalone. The webroot method will use your running Apache system to handle HTTP port 80 challenge. Once you have all your new certs and certbot renew --dry-run works then adjust your Apache config to use the /etc/letsencrypt/live folder for the SSLCertificate statements
Will LetsEncrypt add it's own configuration? I know it has in the past when I've tried this years back. Not sure if the same command precisely though.
Presumably if not I can just add the following to the apache2 vhost, but I'd prefer it not monkey with configs unless I tell it to.
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/gnmonlineseminars.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/gnmonlineseminars.com/privkey.pem
I really appreciate everyone's help with this. Please help me confirm I've got the right idea. Thanks again!
Edit: PS. Looking at old letsencrypt renewal conf on my own domain, I see I was using pre/post hooks to stop/start apache2 before/after the --standalone renewal process. I vaguely recall having some snafu with apache2 configs and just found that easier at the time. Years ago now and had forgotten about it cuz it worked fine ever since on my for all intents and purposes, single-user website.
Ah. I did use certbot with a apache2 some years back and it would add it's own configuration to the relevant apache2 virtualhost configuration automatically on first run. It's been a while since I tried doing it that way, so wasn't sure if certbot would try to configure apache2 itself or presume I already had it setup. Perhaps in this case it only worries about access to /.well-known/ and doesn't care about the apache2 configuration?
Incidentally, if that's not what you would do? What would you do? Am I doing something wrong there? Or leaving something important out?
The /etc/letsencrypt folders should be thought of as reserved for Certbot. Do not manually place files there or manually adjust them. Updates should only be done with Certbot commands. You can refer to these files of course but do not manually modify them.
I suggested using a temp location for your copied certs from your old system. You will have to manually update your Apache accordingly
Ah yes. Sorry for any miscommunication. If I understood you correctly, I'll do as follows.
Place the existing certs in a non-standard temporary/secure location and configure the vhost accordingly.
Change the DNS.
Issue the following command. sudo certbot certonly --webroot -w /path/to/gnmonlineseminars.com/public_html -d gnmonlineseminars.com,www.gnmonlineseminars.com
Change the apache2 configuration to point to the new certs via the SSL configuration I cited previously.
I'd guess in the case I don't have the old certs before the DNS change, then I'd have to expect a window of time without a cert until the new one can be created. Do I have that right?
I would test all the domains / VHosts after step 2. They should all work using the temp certs. You could switch the DNS back to your old hoster if you run into problems on the new system. Converting from nginx to Apache is likely to have some surprises.
I'd set the TTL on all your domains to a small value now and keep that until you finalize on your new hosting service.
You can get the new certs as time permits there is no urgency.
For VHosts where you don't have cert files to copy, leave the DNS for those on the old system until the new system is proven with ones you do have. You could setup just a port 80 HTTP VHost for them to test that much but yes until you have a cert on the new system you won't be able to make a VHost for HTTPS for those.
I mainly use apache2 so I'm familiar with a standard setup for that. With the prior hosting it was managed via Plesk setup by someone else. I'll be happy if the certs I was able to copy are the correct ones, but otherwise it looks like it won't be a major problem apart from the window between DNS update and new cert creation.
For VHosts where you don't have cert files to copy, leave the DNS for those on the old system until the new system is proven with ones you do have. You could setup just a port 80 HTTP VHost for them to test that much but yes until you have a cert on the new system you won't be able to make a VHost for HTTPS for those.
This got me a little confused. Are you saying I can get new certs via certbot on the new VPS prior to making the DNS change for the associated domain? I wasn't aware that was a possibility (I thought it depended in part on matching the IP the DNS resolves to). Would I do the same as above (minus step 1&2) to create that new/additional certificate, or is there a different set of steps/commands involved?
