Setup certbot for automatic renewal though the initial setup has been done "manually"

My domain is: (no website there, only on subdomains, like:
My web server is (include version): nginx 1.18.0
The operating system my web server runs on is (include version): FreeBSD 12.2
My hosting provider, if applicable, is: OVH
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): not installed yet

I created and installed a certificate following the instructions on
This worked nicely. I'd liked to automate the renewal and discovered certbot may do this.
The point is, the defaults are not the same as my current setup (no /etc/letsencrypt/ directory, for instance). Also, I do not really want to run certbot to perform an initial setup itself since I don't want it to modify the nginx configuration files in any way.

So, I have:

  • an account.key file (so far, saved in /root/.ssl)
  • chained.pem and dhparam.pem files in /etc/ssl/certs/
  • domain.key in /etc/ssl/private/
    And nginx knows about these last three files (their paths are written in its configuration files).
    The certificate is for the main domain ( and its subdomains (* All of this runs fine.

I've seen installing certbot is easy.

My questions are:

  1. Is it possible to setup certbot to only perform renewals on an already working setup?
  2. If yes, in order to use certbot only for future renewals, is it necessary to install the nginx and DNS plugins too? Or may that be skipped, as nginx is already properly configured and the certificate is already correct (and includes wildcard domain names)?
  3. Will it be enough to run certbot via a cron job like in the example provided at step 8 (wildcard certificate tab) at

I guess (though I am unsure) the answer to the 3d question is no, since renewals seem to rely on renewal configuration files.

So, would it be correct to create one manually? I just don't know how my files match the ones of the example renewal config file I've seen in the doc. I could try something like this:

archive_dir = ??
cert = ??
privkey = /etc/ssl/private/domain.key
chain = /etc/ssl/certs/chained.pem
fullchain = ??

And this should be stored in /etc/letsencrypt/renewal/, but I am not sure what the CERTNAME is, that should be used to name the renewal config file.

Or, maybe instead of a renewal config file, I should specify the required files via command line options (like --key-path etc.) in the call of the cron job?

1 Like

In theory yes, but in practise I think this would be very difficult. Certbot doesn't have any "import" function. The account files are some kind of JSON format which isn't documented for example. Personally, I wouldn't go down that path if I were you.

The nginx plugin isn't required. It never has been actually, as there are other authentication plugins to choose from (such as webroot, dns plugins or manual).

I think your biggest issue is: how are you planning to authenticate your domain for the wildcard certificate? Are you planning to add and remove the TXT record(s) manually? If so, you can't automatically renew your certificate with certbot, as it requires manual operation at every renewal. Or are you planning on using a DNS plugin?


Well, I haven't planned anything yet. I'd liked to be able to automate the renewal, but I never performed a renewal before, even manually. So, I don't know much about what it will be about. As you ask about adding and removing TXT records manually or not, I guess the challenges parts must be done again at every renewal? I don't know how this can be automated, but maybe that's what the DNS plugin is about? Then I'll check that.

Still, as you say my initial idea is difficult to perform, I guess the best is to simply re-do everything using certbot from start (with a DNS plugin)? This way will be easier to setup the renewals, if I am right?

1 Like

A renewal is just the definition for getting a whole new certificate but with the same hostnames in it as a previous certificate. Nothing more, nothing less.

Correct. Hostname authorizations are cached, but only (currently, possibly subject to change) for 7 days. And you're advised to renew after 60 days, so those authorizations are long gone, requiring you to authorize/validate your hostname(s) again.

Yes, the idea behind a DNS plugin is that you provide the plugin with credentials to some kind of API of the DNS provider which is allowed to add and remove the required TXT records.

Correct, that would be the most logical approach. You can use certbot certonly (...) to only get a certificate without certbot trying to install the certificate into nginx. You should include a --deploy-hook command which would reload your nginx and of course point to the correct paths in /etc/letsencrypt/live/ in your nginx configuration files.


Just to add to what has already been said.
A DNS plugin is only required (for DNS authentication which is only required) for wildcard certificates.
You can use it for all types of certs; but is not required for any non-wildcard type names.
So... if you run into any problem with DNS plugins, and you can make do with certs that contain the full names (NOT WILDCARDS), and you can validate using HTTP (port 80), you can then just use certbot via HTTP authentication.
[which should be a very simple solution]

So many words!
Do you really need a wildcard cert?
If yes, you must use a DNS plugin.
If no, then you may choose a simpler path.

One more thing:
As far as trying to get certbot to put files where nginx already knows them...
It would be far simpler to tell nginx to get the files where certbot puts them.
[which can be done independently from having certbot get any certs - yes dual certs (in two places first) - then switch nginx to the certbot cert(s)]


Thank you very much for your explanations, they make things way clearer to understand globally.
The answer to my question is actually contained in all posts, but I choose this one as this is the main part of the answer.


Thank you very much for these additional details, I'll take them into account. I wanted to setup a config with a wildcard cert in order to be able to add other subdomains later without having to request a new cert each time. But for now I only need two, so I'll do the most simple solution. If I need more subdomains later, I'll add the matching certs.


This would be ideal!
For you: Very easy to add/remove names instantly (no waiting).
And the added security of obscurity; as the exact names used are not being published anywhere.
For LE: Less resources consumed (only one cert required).

I hope you can achieve this.
We are here to help if you run into any problem(s).

1 Like

Well, I got the credentials very easily and then simply running:

certbot certonly --dns-ovh --dns-ovh-credentials /path/to/ovh.ini -d -d "*"

worked straightforward, actually it has been way quicker than doing the same all "by hand" via (only had to think that the wildcard domain should be quoted to not be interpreted wrongly by sh).

Thank you very much again for your valuable guidance!

And a happy new year to you and everyone here :slight_smile:


And you can just use certbot renew to renew your certificate! Don't forget to reload any service using the certificate after a renewal. You can add a command kor script) to the --deploy-hook option or use the deploy hook directory. See the certbot documentation for more info.


Thank you! I did miss the --deploy-hook part. So I've checked the doc and added it to my crontab's line.

It is slightly different than the doc's line, because it does not use python (by the way, there's no default python executable in FreeBSD). I share this here in case it might be helpful to other FreeBSD users. Instead of python, I installed the small shuf utility (via pkg install shuf) and perform the whole action directly via the shell. So, via crontab -e (as root), I added:

0 0,12 * * * sleep `shuf -i 1-3600 -n 1` && certbot renew -q --deploy-hook 'service nginx reload'

(take care that all executables in this line must belong to paths that belong to cron's PATH, so maybe check the default cron's PATH to ensure this will work, and if necessary redefine it at start of crontab. For information, sleep is in /bin, service in /usr/sbin and shuf and certbot are in /usr/local/bin).


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