How to regenerate renewal config file?

The documentation says it’s not recommended to manually modify the renewal configuration file, but what should we do if we want to make a change between renewals (e.g. forgot to add a post hook, etc.)? Is there a recommended way to regenerate the configuration file (without generating a whole new certificate) so it’s correct for the next renewal? I was hoping that rerunning my original certificate command with --dry-run would do it, but it doesn’t. From what I can tell, the renewal config file only gets written the first time the certificate is generated, and never gets updated by certbot again.


As far as I know, requesting a new / renewed certificate and manually editing the files are the only ways to make changes.

I remember reading that recommendation not to edit the file manually, but I can’t find it now. I think the reasoning behind it was just that the format isn’t documented. It’s not terribly hard to figure out, though. Make a backup before experimenting, of course. If there’s an option you want to use and you’re not sure what it should look like in the config file, you can use --staging (and --cert-name) to try it out; that does write a renewal config file but it also writes a cert so you won’t want it to overwrite your real certs (hence --cert-name to save it under a different name).

For the record, those warnings (several of them) are here:

I was going to ignore these and just manage the file myself via config management, but that seemed trickier the more I looked at it. Does anyone else think we should have a command line option to rewrite these files for us? Should I put in a feature request somewhere?

Regarding the final resolution of my related thread:

To handle a modified --webroot_path, we ended up modifying the renewal conf file in-place (via script, automatically as needed).

I’ll check out that warning, but I think in general, having an officially supported way to modify renewal configuration without reissuing a cert would be ideal.

That seems like a good idea to me. Certbot's issue tracker is here if you want to put in a feature request.

The historic reason why this doesn’t exist in general may be in part that making an invalid change in the renewal configuration could cause automated renewals to start failing, but you conceivably wouldn’t notice this for a long time. For example, if you manually change your webroot by editing the renewal configuration but get it wrong, you can’t renew with certbot renew anymore, but you don’t necessarily know this because you haven’t had Certbot try to complete the renewal.

Hmm. Okay, what if it ran a --dry-run before updating the file?

That might be helpful!

1 Like

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