Forced renewal with existing certificate without renewal data?

Hi all!

  • Domains: serveral, virtual hosts
  • I would like to run this command: certbot certonly --force-renewal --webroot -w /var/www/webdir -d dom.tld -d www.dom.tld
  • Web server: Apache 2.4.41
  • Operating system: Ubuntu Server 20.04.3 LTS
  • Hosting: Dedicated server at Hetzner
  • I can login to a root shell: Yes
  • No control panel and no graphical desktop
  • certbot 1.23

Currently, I am transferring a few virtual hosts from a FreeBSD server to an Ubuntu Server. Certbot works on Ubuntu, I already created a new certificate.

For testing I copied letsencrypt/archive and letsencrypt/live from FreeBSD to Ubuntu. This worked immediately since the "live" symbolic links were relative. I did not copy the renew data, since they differ between FreeBSD and Ubuntu.

After having modified the IP in DNS, I now would like to create a new cert on the new Ubuntu server by calling the above command.

letsencrypt/archive/dom.tld and letsencrypt/live/dom.tld already exist and contain the old cert. http requests for dom.tld are always redirected to https which works as desired. Therefore I assume that if I would delete the old cert, the challenge would fail due to the missing certificate.

While I could modify the vhost config to http only, then create the cert and afterwards switch back to https, this process would be rather cumbersome and cause more down time. So I would prefer to keep the old certificates.

My question: Will the above command work or will the existing certificate (without renew entries) disturb the forced renewal?

Kind regards

1 Like

The basis used by Certbot is the renewal configuration file. Without it, the certificate doesn't exist as Certbot is concerned, even if there are files in /archive/ and /live/. I'm not sure what will happen if you try to get a "new" certificate with existing directories in /archive/ and /live/ with the same name. Certbot probably will raise an error.

Are you running Certbot with the --reuse-key option? If not, you don't really need the files in /archive/ and /live/.

By the way, why would you use --force-renewal?

I think the best way to migrate stuff is to copy the entire /etc/letsencrypt/ directory and let Certbot update the renewal configuration file, if necessary.

3 Likes

Hello Osiris, thanks for the answer.

Without the files in /archive/ and /live/, apache returns config error due to missing certificates. I could avoid this by editing all the virtual host configuration files in order to turn SSL off and again on afterwards.

As I already mentioned, the FreeBSD renewal files shouldn't work in the Ubuntu setting. All the FreeBSD paths in the renewal files are not appropriate to Ubuntu. Are these paths really magically updated if I run "certbot renew"? If this were so, these paths would seem to be unnecessary. I assume that I would at least have to manually edit all the files in the renewal directory which seems error-prone.

--force-renewal: I guessed that this could be necessary since the current certificate is not old enough. Of course this may be wrong.

--reuse-key: I don't use this switch.

It appears to me that there might be no easy way.

Kind regards

1 Like

Or you can avoid trying to start Apache, issue your certificates using --standalone and then start Apache and run certbot renew --apache so that certbot remembers to use Apache next time (it won't renew but it will save the preference -- you probably need to specify --cert-name there as well).

Of course, if you want the same paths you have to use the --cert-name option pretty much always.

1 Like

True, if you migrated the Apache configuration 1:1, then it will expect those files indeed.

I'm not sure which paths you're refering to, as the only paths contained (AFAIK) in the renewal config file are those to the files in /etc/letsencrypt/, which you seem to have copied 1:1 (so no problem there) and perhaps the webroot path. But that latter path could be overridden by adding the appropriate option to the certbot renew command. (E.g. certbot renew -w /var/www/whatever/) Or edit the renewal conf manually, but that's generally not recommended. On the other side, manually fixing the renewal configuration file and testing it with certbot renew --dry-run would prevent you from issuing a new, forced certificate unnecessarily.

What other incompatible paths would your renewal conf contain?

Not without a renewal configuration file. Also, if you've copied the entire /etc/letsencrypt/ directory, would it still be necessary to force a renewal? You would have migrated perfectly fine certificates I'd think.

3 Likes

Thx again for the answers.

The solution for me is that apache caches the certificates and will not immediately discover that a certifictes is deleted from disk. I overlooked this caching. So I delete

/etc/letsencrypt/archive/mydomain.tld
/etc/letsencrypt/live/mydomain.tld

and then run

sudo certbot certonly --webroot -w /var/www/mywebdir -d mydomain.tld
sudo apache2ctl graceful

In the multi-domain case further domains have to be added. This creates a new certificate together with the correct renewal data. I tried this for 2 domains and it worked flawlessly. The case may be regarded as closed.

I did not copy everything since the certificates are stored at /etc/letsencrypt (Ubuntu) instead of /usr/local/etc/letsencrypt (FreeBSD) and the webroot is /var/www (Ubuntu) instead of /usr/local/www/apache24/vhosts (FreeBSD).

--standalone: I hesitate to try this, since it would at least cause more downtime (from stopping apache) and I have no experience what effects this has for the renewal.

Kind regards

1 Like

It doesn't. It just loads them in memory.

What you're doing is risky, but if it works for you, be my guest.

1 Like

With respect to "caching":

I agree. Sorry, this was just sloppy language by me.

1 Like

That is VERY unnecessary and potentially troublesome.

1 Like

Osiris, however, mentioned above that these directories might cause problems. Furthermore, what may be troublesome if "mydomain.tld" is nowhere present within etc/letsencrypt on the new server?

Essentially, this appears to me as a compeltely new creation of a certificate on a new server under a new letsencrypt account. The only difference is that Apache has an old but still valid cert in RAM. This cert could even stem from another cert provider. "certonly" does not install anything in the Apache config.

I had also read here that it should be possible to recreate certificates from scratch on new servers.

"sudo certbot renew --dry-run" gives
"Congratulations, all simulated renewals succeeded"

This result seems also to be reasonable:
https://www.ssllabs.com/ssltest/analyze.html?d=new.gwup.org&latest

Kind regards

1 Like

Your server seems to be using the most recently issued certificate for that hostname indeed.

Using certonly and the --webroot authenticator bypasses Apache so indeed it could still use the certs in RAM.

That said, when using certonly you should make sure Apache is reloaded after a renewal. Usually, this would be done by adding the reload command to a --deploy-hook.

2 Likes

You only mentioned the /archive/ and /live/ directories in your "delete" attempt.
There is more to consider; Like: /renewal/
And certbot already has a built-in delete function.

2 Likes

Yes, I know of the built-in delete command but I was uncertain what this feature additionally could perhaps do besides simply deleting files in the letsencrypt directory. I did not copy the renewal data from the old server since the paths to letsencrypt and the webroot have changed due to an OS change from FreeBSD to Ubuntu. This means that the /renewal/ data was already not present on the new server, so there was nothing to delete. This I mentioned in an earlier posting.

Kind regards

1 Like

I would interpret "bypassing Apache by using certonly/webroot" means that neither the Apache config is touched by certbot not that Apache is restarted by certbot. But the access to the challence should nevertheless go over Apache. A total Apache bypass should happen if I would apply the option --standalone.

Yes, I agree.

Kind regards

1 Like

Correct.

True, but doesn't require a config change or restart, which was indeed what I meant.

2 Likes

Meanwhile, I moved 10 virtual hosts from FreeBSD to Ubuntu without any problems using the mentioned approch. As I aready wrote I copied only archive and life dirs for website testing but without the renewal part since renewal contained data incompatible with Ubuntu (wrong paths). After deleting life and archive data I was always able to receive new certs together with now correct renewal data. While certbot was running, Apache kept the old certs in RAM. Restarting Apache loaded the new certs.

Despite that my approach was designated as dangerous, it worked like a charm. I could just keep the SSL sections of the vhost config files. Case is closed for me.

Kind regards

1 Like

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