How to switch from apache to webroot for renewal



I used certbot-auto apache to install a certificate for a website on an unbuntu server running PHP-FPM and Apache. This did not work without commenting out various sections of the virtual host configuration file which were causing certbot to fail. Once the offending lines had been removed the certificate was successfully obtained. I could then reinstate the necessary parts of the configuration to ensure the website was functional. However, the renewal of these certificates fails for the same reason as the initial certificate retrieval - the config cannot be parsed.

I later learned that using certbot-auto certonly --webroot meant that the configuration files did not need to be touched and I have therefore successfully acquired and renewed certificates for other websites without any trouble.

What I’m wondering is how to switch from the apache approach to the webroot approach with minimal disruption. At first glance it would seem I can simply update the letsencrypt/renewal configuration file with the necessary settings for the website in question.

Below is the contents of the renewal configuration file for the website in question in apache mode:

version = 0.9.3
cert = /etc/letsencrypt/live/
privkey = /etc/letsencrypt/live/
chain = /etc/letsencrypt/live/
fullchain = /etc/letsencrypt/live/

authenticator = apache
installer = apache
account = 12345

And here’s what I intend to change it to after comparing it to the websites I have set up with the webroot method:

version = 0.12.0
archive_dir = /etc/letsencrypt/archive/
cert = /etc/letsencrypt/live/
privkey = /etc/letsencrypt/live/
chain = /etc/letsencrypt/live/
fullchain = /etc/letsencrypt/live/

authenticator = webroot
installer = None
account = 12345
[[webroot_map]] = /var/www/ = /var/www/

I’m not 100% sure what the implication of changing the version number is. If I don’t change it will the syntax be correct? If I do change it might it somehow invalidate the certificate request?

Finally, is there anything other than the renewal configuration file that I need to consider changing?

Any help greatly appreciated.


In the past, the configuration file syntax could have changed. If there’s an update in syntax which isn’t compatible, the client needs to know about it.

As far as I know, your new configuration should work.

If I were you, I would just try it with the --dry-run switch: this will try to renew even if the cert is not even close to expiry, but with “staging” certificates. It will not change anything in the /live/ directory at all, just for testing.

The apache plugin would reload Apache by itself. With certonly, you’re responsible for that. There are four options:

  • Manually reloading your webserver after a certbot-auto renew. Which obviously is quite stupid, b/c you’d want to run certbot-auto renew automatically from for example cron… :stuck_out_tongue:
  • Adding the reload command to the cronjob;
  • Adding the switch --renew-hook command_to_reload_your_webserver_goes_here to certbot-auto renew ór
  • Add the option renew_hook = command_to_reload_your_webserver_goes_here to your renewal configuration file.

(Do note the difference between the dash (-) on the command line in --renew-hook and the underscore (_) in the renew_hook option for the renewal configuration ;))

Hope this helps!


Thanks very much Osiris. Pleasing to know I was on the right lines but always helpful to have someone backing up the thinking.

Good suggestion re the –dry-run, that gave me added confidence that everything was going to renew as expected (which it did).

Finally, good call re the reload, something I had not added to the other server where I was using webroot and noticed a reload was necessary. In the end I opted for the –post-hook option at the end of the command in crontab so as to prevent apache from reloading for each and every certificate that is renewed. Hopefully I’ve understood this correctly.

Thanks again for your help.


Agreed, good choice :slight_smile:


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