Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
My web server is (include version): Apache/2.4.68 (Debian)
The operating system my web server runs on is (include version): Debian 12
My hosting provider, if applicable, is: AlphaVPS
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): no
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): certbot 5.7.0
I want to run on the new server by copying over all letsencrypt files and pointing the domain to the new IP.
However, the keys in /etc/letsencrypt/live have filenames containing the CNAME of the old server. My new server name if it's set will be the domain name.
Will this give warnings in browsers visiting the site? I want to avoid moving the domain A record and then having a period when visitors can't verify my site.
I don't think it is wise to use the Certbot directories from the old machine on the new machine. At least not how they look today.
For one, your old machine does not have a valid cert for your apex domain so HTTPS requests to it fail (see below).
Second, the cert contains a domain related specifically to your old machine. That cert won't be able to be renewed from the new machine. Well, probably not it depends how you did that exactly. But, even still it would be best not to have it involved in your new machine.
Here is the existing cert
X509v3 Subject Alternative Name:
DNS: 46-43-20-32.no-reverse-dns-set.bytemark.co.uk
DNS: www.thebookguide.info
What you should have is a cert that contains two names: thebookguide.info and its www subdomain.
If you make requests to that bytemark domain that won't work on your new machine. Do you actually need that for some reason?
If you want to copy Certbot from your old machine you will need to redo the certs and possibly your Apache before copying it. But, I think generally you'd be better off setting up Certbot fresh on your new machine.
We can look at fixing your old machine. What do these commands show?
And, please show the contents of the .conf file in below directory. You can redact the account name if you wish
/etc/letsencrypt/renewal
Example of request to your apex name failing today:
curl -i https://thebookguide.info
curl: (60) SSL: no alternative certificate subject name matches target host name 'thebookguide.info'
More details here: https://curl.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it.
# renew_before_expiry = 30 days
version = 5.7.0
archive_dir = /etc/letsencrypt/archive/46-43-20-32.no-reverse-dns-set.bytemark.co.uk
cert = /etc/letsencrypt/live/46-43-20-32.no-reverse-dns-set.bytemark.co.uk/cert.pem
privkey = /etc/letsencrypt/live/46-43-20-32.no-reverse-dns-set.bytemark.co.uk/privkey.pem
chain = /etc/letsencrypt/live/46-43-20-32.no-reverse-dns-set.bytemark.co.uk/chain.pem
fullchain = /etc/letsencrypt/live/46-43-20-32.no-reverse-dns-set.bytemark.co.uk/fullchain.pem
# Options used in the renewal process
[renewalparams]
account = [redacted]
authenticator = apache
installer = apache
server = https://acme-v02.api.letsencrypt.org/directory
renew_hook = /usr/local/bin/certbot_after_renew.sh
key_type = rsa
[acme_renewal_info]
ari_retry_after = 2026-08-29T15:24:20
I only copied the certs because it was suggested elsewhere. The problem as I see it is that I imagine I can't create the new certs until thebookguide.info resolves to the new server, and then the site will be unverified until I've done it.
Is there a document that lists the steps needed to start from scratch on the new server?
I don't need to fix the old server, which works for my purposes and which I want to leave in the next day or two. I do want to have correct working certs for the new domain on the new server, and anything I can do before the domain resolves to it would be a help. I certainly don't want to keep the Bytemark name anywhere in the new certs.
You also asked for the output of apache2ctl -t -D DUMP_VHOSTS on the old server
VirtualHost configuration:
*:443 is a NameVirtualHost
default server 46-43-20-32.no-reverse-dns-set.bytemark.co.uk (/etc/apache2/sites-enabled/000-default-le-ssl.conf:2)
port 443 namevhost 46-43-20-32.no-reverse-dns-set.bytemark.co.uk (/etc/apache2/sites-enabled/000-default-le-ssl.conf:2)
port 443 namevhost www.thebookguide.info (/etc/apache2/sites-enabled/000-default-le-ssl.conf:64)
port 443 namevhost thebookguide.info (/etc/apache2/sites-enabled/000-default-le-ssl.conf:109)
port 443 namevhost www.thebookguide.co.uk (/etc/apache2/sites-enabled/000-default-le-ssl.conf:116)
port 443 namevhost thebookguide.co.uk (/etc/apache2/sites-enabled/000-default-le-ssl.conf:123)
*:80 is a NameVirtualHost
default server 46-43-20-32.no-reverse-dns-set.bytemark.co.uk (/etc/apache2/sites-enabled/000-default.conf:1)
port 80 namevhost 46-43-20-32.no-reverse-dns-set.bytemark.co.uk (/etc/apache2/sites-enabled/000-default.conf:1)
port 80 namevhost www.thebookguide.info (/etc/apache2/sites-enabled/000-default.conf:54)
port 80 namevhost thebookguide.info (/etc/apache2/sites-enabled/000-default.conf:102)
port 80 namevhost thebookguide.co.uk (/etc/apache2/sites-enabled/000-default.conf:107)
port 80 namevhost www.thebookguide.co.uk (/etc/apache2/sites-enabled/000-default.conf:112)
and sudo certbot certificates
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Attempting to parse the version 5.7.0 renewal configuration file found at /etc/letsencrypt/renewal/46-43-20-32.no-reverse-dns-set.bytemark.co.uk.conf with version 0.31.0 of Certbot. This might not work.
Cannot process OCSP host from URL () in cert at /etc/letsencrypt/live/46-43-20-32.no-reverse-dns-set.bytemark.co.uk/cert.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Found the following certs:
Certificate Name: 46-43-20-32.no-reverse-dns-set.bytemark.co.uk
Domains: 46-43-20-32.no-reverse-dns-set.bytemark.co.uk www.thebookguide.info
Expiry Date: 2026-10-31 07:48:31+00:00 (VALID: 62 days)
Certificate Path: /etc/letsencrypt/live/46-43-20-32.no-reverse-dns-set.bytemark.co.uk/fullchain.pem
Private Key Path: /etc/letsencrypt/live/46-43-20-32.no-reverse-dns-set.bytemark.co.uk/privkey.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
I don't understand the huge certbot version mismatch.
Your self-signed certs for the co.uk domain are not working as well as you might think. Same issue for your apex .info domain which I showed a curl example for.
Whether the redirect works or not is dependent on the browser and its configuration. For example, this is what happens on my Firefox to your .co.uk domain today. If you think this should be working there is more work to do. We can do that all on your new site but it will take some time. You can leave the .co.uk domain as it is while you get .info setup and then do that one to shorten affects on each one
I have the website running on the new server, but obviously to get to it using a thebookguide.info URL I have to fake the IP address in a local hosts file. I don't know if I tried using the copied-over certs as I was fighting with setting up https on several fronts. But yes, I created and am using a self-signed cert to be able to test https, and of course had to set a security exception in my browser to use it. Obviously when the new server hosts the domain I want to have properly signed certs.
The alternative .co.uk domain name is very unimportant and is only there as a permanent redirect to .info, and I don't think is ever used. If it doesn't work on the new server at first I can fix it at my leisure.
certbot version is 0.31.0 on the old server both as root and as an unprivileged user. The 5.7.0 I quoted in my first post is for the new server. I have to confess that I ran certbot on the new server using the copied-over certs. Which gave a slew of errors but may have changed something. But surely not on the old server, which the new server has no stored login or shared key for.
Is there documentation that shows (step by step for a non-expert user) how to set up new certs from scratch on a new server for an existing domain, with any cleanup (revocation etc) necessary?
Yes, but, as I noted this redirect is not working properly. But I'll ignore it if you wish.
Note based on your public cert history you have never gotten a publicly trusted (Let's Encrypt) cert for the co.uk domains. Redirects from there has never worked properly as far as I can tell.
What may be obvious to you is not obvious to an outside observer who has only been given limited info
Setting up a new server is the same as setting up your old server. But, there are many options available and this affects the steps.
It looks to me like you setup your old server by configuring Apache for your domains on HTTP. Then set your DNS for that Apache and ran Certbot to get the cert using the --apache method. To recreate that on the new system you follow these same steps including the DNS change.
Note there are many other ACME Clients that allow getting a cert you don't even have to use Certbot. For example, there is a mod_md ACME Client built-in to Apache itself. But, Certbot is fine if you want to stay with it. And, another option is using a DNS Challenge which may not require switching your DNS to the new server but these are more complex to setup usually.
The issue with your chosen technique is how to avoid downtime while the DNS is "in transition". The steps you took were the wrong ones. That thread you reviewed cautioned against that unless the two systems were identical. Yours are not given that you have a domain name in your old cert that will not exist on your new one.
Going forward, if you just want to focus on the new server please show output of these just on that machine.
certbot version is 5.7.0 for root and unprivileged user
sudo certbot certificates gives "No certificates found."
sudo apache2ctl -t -D DUMP_VHOSTS gives
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 193.36.236.100. Set the 'ServerName' directive globally to suppress this message
VirtualHost configuration:
*:443 is a NameVirtualHost
default server 193.36.236.100 (/etc/apache2/sites-enabled/000-default-le-ssl.conf:2)
port 443 namevhost 193.36.236.100 (/etc/apache2/sites-enabled/000-default-le-ssl.conf:2)
port 443 namevhost www.thebookguide.info (/etc/apache2/sites-enabled/000-default-le-ssl.conf:70)
port 443 namevhost thebookguide.info (/etc/apache2/sites-enabled/000-default-le-ssl.conf:119)
port 443 namevhost www.thebookguide.co.uk (/etc/apache2/sites-enabled/000-default-le-ssl.conf:126)
port 443 namevhost thebookguide.co.uk (/etc/apache2/sites-enabled/000-default-le-ssl.conf:133)
*:80 is a NameVirtualHost
default server 193.36.236.100 (/etc/apache2/sites-enabled/000-default.conf:1)
port 80 namevhost 193.36.236.100 (/etc/apache2/sites-enabled/000-default.conf:1)
port 80 namevhost www.thebookguide.info (/etc/apache2/sites-enabled/000-default.conf:54)
port 80 namevhost thebookguide.info (/etc/apache2/sites-enabled/000-default.conf:102)
port 80 namevhost thebookguide.co.uk (/etc/apache2/sites-enabled/000-default.conf:109)
port 80 namevhost www.thebookguide.co.uk (/etc/apache2/sites-enabled/000-default.conf:114)root@thebookguide:/etc/letsencrypt#
Obviously the VHosts info comes from /etc/apache2/sites-enabled/000-default-le-ssl.conf, which is copied from the old server config with slight changes.
The VPS doesn't have any DNS settings yet (no public records point to it), so I set ServerName in that file to the IP address 193.36.236.100. Maybe I should have left it so it matched the copied certs, but I didn't want to break the live ones on the old server.
Really, there's a simple answer: move the DNS records to the new server, then run certbot (if you insist on using it) to get a cert. Trying to move the certs from the old system to the new one introduces unnecessary complications.
Or better yet, use Apache's mod_md to handle the certificate--most people shouldn't need to use certbot at this point.
It's the chicken and egg situation that I'm trying to avoid. The period when people go to the new server but their browser complains while I fight with the config to get certification set up. I'll investigate mod_md.
OK, but that assumes that 000-default.conf and ?000-default-ssl.conf? are correctly set up, from which certbot will generate 000-default-le-ssl.conf? The problem is getting them right in advance of the DNS change.
Another option, if your DNS host supports it, would be to get the cert using DNS validation. That lets you get the cert on the new server before you switch over the DNS records.
Even if the DSP doesn't support it, one can run certbot manually and get a cert that would give him 90 days to get everything running smoothly on the new IP.
It looks like my DNS doesn't do DNS validation.
Also, my apache config, copied from the old server, has the changes that certbot made to it on the old server.
My guess is that I should move away /etc/letsencrypt and remove any LetsEncrypt cert refs in the apache config
Point thebookguide.info to the new server and wait for the TTL.
Run sudo certbot --apache
I assume that certbot will ask me to create a new LetsEncrypt account, and will create and configure the certs I need.
Rudy's suggestion to use DNS validation in manual mode is a good one, though it will still at least take some edits to your Apache config, since the path the cert is likely to be different. Doing that requires manually adding some DNS records, and then removing them once validation is finished. But that will give you a valid cert that's good for 90 days, your site is live on the new server, and that's plenty of time to figure out the renewal piece.
And I'd still recommend looking into mod_md and away from using a standalone client entirely, but I recognize that's a bigger move.
Better yet would be to use a completely different web server, like Caddy, that automates all of this stuff--but that's going to be a bigger move yet.
But as I said, the .co.uk domain is extremely unimportant. It was transferred from the original site owner who never used it, and may have registered it to prevent poaching. Nobody should know it or use it. I can set up certs for it later but it hardly matters.
Thanks to all for your comments. The server move was due to a company, once wonderful and a sponsor of open source and public benefit things, stopping sponsorship after several mergers and takeovers.
So we'll move to a new method of funding for our very modest annual costs. If we find ourselves in surplus, some will be donated to LetsEncrypt and other services we use.
