Switch from dns to apache after site move

[_jack]

My domain is: domain.com

I ran this command:

It produced this output:

My web server is (include version): Apache 2.4

The operating system my web server runs on is (include version): Debian 10

My hosting provider, if applicable, is: Linode

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 0.31.0

Hello all,

Apologies if this is an FAQ, I couldn’t find much about it in the docs or FAQ or here on the forums.

I am in the process of migrating domain.com from old server A to new server B, at a new hosting provider. Old server A has SSL certificates for domain.com, but not through Let’s Encrypt. I am switching to Let’s Encrypt on new server B.

On new server B, I first set up a staging site and generated a new LE cert for it:

certbot --apache -d staging.domain.com -d host2.domain.com

This worked fine, and I have been testing and using that site for weeks. Later, as the actual move gets closer, I created a new certificate for www and non-www versions of the domain. Since www and non-www are still live at old server A, I can’t use the http challenge method, so I used dns instead. This also worked fine - I added the TXT DNS records, and by editing my /etc/hosts I can fool my browser into visiting new site B to test, and the new certs work fine:

certbot certonly --manual --preferred-challenges=dns -d domain.com -d www.domain.com

(and yes I want to keep the certs for staging and www/non-www separate).

All good so far. Now I want to understand how the automated renewals will work. Debian 10 is systemd and though I am new to systemd I can see the various unit files and timers etc, and I can see from /var/log/letsencrypt that it is running fine.

• Question 1) From what I understand, the cert I created for staging will auto-renew just fine, because I used the apache plugin. certbot should both update the cert, and restart Apache for it to take effect. Is that correct?

• Question 2) When I first ran certbot for the staging site, it modified my vhost config files and added the SSL-related config. While I haven’t changed those SSL-related lines, I have made significant other changes to those vhost files, including merging 80/443 configs into a single file, etc. Will certbot renew attempt to modify those vhost files again during renewal, or will it see the SSL-related lines unchanged and therefore leave them alone?

• Question 3) My understanding is that bcs I used manual/dns for the www and non-www domain certificate, the auto-renewal of those won’t work. I’ve seen suggestions to switch to the apache plugin to make the renewal simpler. I can’t do that until I’ve updated the DNS and actually switched from old server A to new server B of course. But how would I do actually that? The docs discourage modifying the renewal config file (/etc/letsencrypt/renewal/domain.com.conf). So how do I switch renewals from using my original dns command to apache?

Thank you,
Jack

[griffin]

Hello

You could have just copied the existing certificate and private key from the old server to the new server, installed them, then switched the domain's dns A record from the ip address of the old server to the ip address of the new server.

I missed this part:

@_jack

Old server A has SSL certificates for domain.com, but not through Let’s Encrypt. I am switching to Let’s Encrypt on new server B.

[griffin]

@_jack

Question 1) From what I understand, the cert I created for staging will auto-renew just fine, because I used the apache plugin. certbot should both update the cert, and restart Apache for it to take effect. Is that correct?

Yes. You can test the renewal using the --dry-run parameter, which won't install the fake certificate it creates, but I suspect if you managed to both acquire and install a certificate the first time without using standalone, certonly, or other non-automated approaches that you are good to go (as long as you haven't made configuration changes that confuse the Let's Encrypt server at renewal time). Again, test with dry run.

@_jack

Question 2) When I first ran certbot for the staging site, it modified my vhost config files and added the SSL-related config. While I haven’t changed those SSL-related lines, I have made significant other changes to those vhost files, including merging 80/443 configs into a single file, etc. Will certbot renew attempt to modify those vhost files again during renewal, or will it see the SSL-related lines unchanged and therefore leave them alone?

That's actually a very good question. From my experience, you only need to "install" once then the certificate gets replaced during renewal. You should be able to rollback the changes if there's a problem. You can also use --disable-renew-updates to prevent the renewal from updating your configuration.

@_jack

Question 3) My understanding is that bcs I used manual / dns for the www and non-www domain certificate, the auto-renewal of those won’t work. I’ve seen suggestions to switch to the apache plugin to make the renewal simpler. I can’t do that until I’ve updated the DNS and actually switched from old server A to new server B of course. But how would I do actually that? The docs discourage modifying the renewal config file ( /etc/letsencrypt/renewal/domain.com.conf ). So how do I switch renewals from using my original dns command to apache ?

You can "manually" run the certbot command with the new parameters once you've switched. Upon success those new parameters should be stored for later usage during renewal. Again, test this with a --dry-run when you go to switch. As long as you already have a Let's Encrypt certificate installed and functioning, you should not need to "install" the certificate during renewal (meaning that your configuration should already be established, so the certificate and private key should automatically be replaced).

[griffin]

Just a heads-up: your version of certbot (0.31.0) is ancient.

[_jack]

Thanks for the detailed answers @griffin!

/usr/bin/certbot --dry-run renew

fails for the www and non-www domain certificate with:

Attempting to renew cert (domain.com) from /etc/letsencrypt/renewal/domain.com.conf produced an unexpected error: The manual plugin is not working; there may be problems with your existing configuration.
The error was: PluginError('An authentication script must be provided with --manual-auth-hook when using the manual plugin non-interactively.'). Skipping.

I am not completely sure why that is - the renew config file with the manual/dns options is unchanged and I would expect that old approach to be used and work again ... but given your answer about just re-running with new parameters after I've made the switch, I'm not too worried about this. After the switch, I will just do as you say and do:

certbot --apache -d domain.com -d www.domain.com

I hope that will generate a new certificate, and save a new renew config using Apache.

The --dry-run updated the staging certificate fine, though there aren't really any clues as to whether it tried to update my vhost configs or not:

new certificate deployed with reload of apache server; fullchain is ...

Thanks for the tips about rollback and --disable-renew-updates, I wasn't aware of those options.

As to the ancient version of certbot - wow! Current release is 1.7!? I just installed with apt-get install, and got v0.31, it seems the version in the Debian package repositories is very far behind. Maybe I should try an alternate install method.

PS: no need to delete your original reply, you are quite right. I hadn't considered that option, but I suppose I could have copied the current certificates over, and then just run cerbtot later to generate new certificates and switch over.

Thanks again!
Jack

[griffin]

Hello again @_jack

@_jack

/usr/bin/certbot --dry-run renew

So here's the thing: there are 3 "operations" for certbot:

• acquire certificate (certonly)
• install certificate (install)
• acquire AND install certificate (run/renew)

There are also 2 "modes":

• interactive: stops in the middle so you can create the authentication tokens
• non-interactive: requires "hook" scripts that perform the creation and cleanup of the authentication tokens

So perhaps something like:
certbot certonly --cert-name domain.com

The command above replaces the existing certificate with the domains and method specified in the configuration for domain.com. In your case, this should currently be --manual (and thus no installation operation) for domain.com and www.domain.com. You can add --dry-run to the end to test the command. Keep in mind that --dry-run does NOT update the certificate. It generates a fake certificate.

As for your version, you might check into snap installation:

https://certbot.eff.org/docs/install.html

You're very welcome
Jonathan

[_jack]

Thanks again for the reply and your patience. Unfortunately the more I read over the certbot docs the more confused I seem to be. I have read the user guide top to bottom many times now.

@griffin

So perhaps something like:
certbot certonly --cert-name domain.com

I think you are suggesting this as a way to test renewal now, before the switch? I don't actually care about renewal yet, as the certificate is only a few weeks old and the switch will happen well before it is due to renew.

I think the process I need to do is:

1. Make the switch so that domain.com and www.domain.com point to new server B with existing Let's Encrypt certificates.

2. Run certbot, specifying either the apache plugin, or -a apache, so that the renew config on disk - which currently specifies manual/dns - is updated, so that future automated renewal runs will work. Maybe like so:

   # acquire and install new cert
   certbot --apache -d domain.com -d www.domain.com
   

   Or to make sure certbot does not touch my vhost config files:

   # just acquire a new cert, no installer specified so no installation?
   certbot -a apache (-i none ?) -d domain.com -d www.domain.com
   

   Or to really make sure it does not touch my config files?

   # just acquire a new cert
   certbot -a apache --disable-renew-updates -d domain.com -d www.domain.com
   

3. Update the Debian certbot service so the renew command includes --disable-renew-updates?

   certbot -q --disable-renew-updates renew 
   

Now future updates will use the apache authenticator, without an installer, so my vhosts are not modified. Am I on the right track, or just tying myself in knots?

As to the snap install - thanks, I did see that option. I am not familiar with Snap, and I'd rather not have to install a whole new package management tool on a production server ... maybe I can just manually download and use the certbot-auto shell script the "Other UNIX" option suggests.

[griffin]

Yeah, in my opinion the certbot documentation (and options) could really use some streamlining. I actually use my own client.

• The --cert-name option allows you to use an existing configuration so that you don’t need to respecify the domains or methods of acquisition or installation. Any parameters you specify in addition will override what’s in the configuration. Think of it as “initializing” your command.
• When you don’t specify run, renew, certonly, or install (or any of the options without -- in front), certbot defaults to run.
• You can use -d domain.com,www.domain.com if you don’t want to keep putting -d. Either way, the first entry becomes the common name on the certificate.
• Use certbot certonly -a apache instead of certbot -a apache -i *none*

It looks like you’re generally on the right track though. Just be sure to thoroughly test with --dry-run as it automatically rolls back the changes doesn’t overwrite your certificates.

Cheers!