Cron Job

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. |, so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:
I ran this command:

It produced this output:

My web server is (include version):

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

My hosting provider, if applicable, is:
I can login to a root shell on my machine (yes or no, or I don't know):
I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
NOT USED - USING Operating System
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
Neil PANG version 2.8.7

My Issue isn't running the renewal for the certs (that funtions perfectly well) its the actual cronning of the job on the particular platform / service.
The scenario is that in order to have the cert installed two things need to happen - the .cer needs renaming to .crt the service gracefuly stopped and the keys copied (renaming extension) into a particular directory on the same server ...then service restarted again, the service does not need to stop and start when using a browser to install the certificates - Not great for automation.
Current script i have is : /Users/localname/ --issue --dns dns_cf -d -d
/usr/mailhost stop
cp /path/to/ /usr/local/mailhost/ssl/mail.example.crt
cp /path/to/ /usr/local/mailhost/ssl/mail.example.key
/usr/mailhost start
I do this manually before renewal is due .....
How often could the cron run without tripping an "excessive call" condition ?
Or is there the same type of thing that can be done within acme more elegantly?
Bc the setup really isnt checking if the cert has changed its just copying each time.I'd love to know a cleaner method that isn't "whack a mole" setup.

1 Like

I seriously doubt your domain is "".

So, let's start over:

withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help

/path/to/your/ --help
Which among lots of other stuff shows:
--deploy-hook <hookname>

1 Like includes an --install-cert command which does pretty much this.

Have a look at this part of the README. You will notice that it allows you to specify a destination path for the files and an optional hook to restart a nominated service.

--install-cert is the companion to --issue: you're meant to use them together. The --install-cert part will be invoked upon every certificate renewal.

Your cronjob should be --cron. If you look in crontab -l (at least, on Linux), it should already be there.

This command could run every minute and it would be safe. It will only actually renew certificates (and therefore the --install-cert) when they need to be renewed.

1 Like

Thanks _az I have the acme cron running (appears every 15 mins) but my own root cron now set to run once a day for the whackamole approach lol, the commands must be run as root on the mailserver so local standard user cron wont cut it and so im pinned in a ugly double cron setup.

1 Like

The domain has no relevance here.

...and, more relevantly, --reloadcmd. OP, it's simple--use the --install command, specify the desired paths for the cert files, and use --reloadcmd (whatever you'd use to restart the service).


That's fine, in that case I'd just use as the root user, and avoid using it as an unprivileged user.

That will allow you to issue --issue followed by --install-cert and have a sane autorenewing setup.

Or more simply: avoid using --issue in a cronjob, because it's really not the right way to use


There is something i found called "--renew-hook" in v 2.8.9 if i edit the existing crontab for .acme and replace with my existing root crontab commands would that work ? as --reloadcmd does not work with my mailhost it isnt apache or nginx...

15 0 * * * “/path/tofile/"/ --cron --home - -renew-hook /usr/local/mailserver/mailhost stop
cp /path/tofile/ /usr/local/mailserver/sslcert/server.crt
cp /path/tofile/ /usr/local/mailserver/sslcert/server.key
/usr/local/mailserver/mailhost start
“/path/tofile/" > /dev/null

1 Like

I suppose you mean --install-cert instead of --install :wink:


Yep, getting my clients mixed up.

I think hooks have to be part of your original --issue/--install-cert commands. If that's right, feeding it to --cron doesn't have any effect.

How about doing (as root): --install-cert \
--home           /Users/XXX/ \
--key-file       /usr/local/mailserver/sslcert/server.key  \
--fullchain-file /usr/local/mailserver/sslcert/server.crt \
--reloadcmd     "/usr/local/mailserver/mailhost stop; /usr/local/mailserver/mailhost start"

then you shouldn't need to do anything tricky with crons.


Don't forget to add the domain name (no need to add all the domains that is covering the certificate, only the first one): --install-cert \
--domain \
--home           /Users/XXX/ \
--key-file       /usr/local/mailserver/sslcert/server.key  \
--fullchain-file /usr/local/mailserver/sslcert/server.crt \
--reloadcmd     "/usr/local/mailserver/mailhost stop; /usr/local/mailserver/mailhost start"

Then you should say that in the form.
Saying "" is very misleading; as with any real domain that you don't actually own.
And you would be surprised how many times that domain is actually used in a command line.
[and then they wonder why is doesn't work in their lab]

And you completely ignored or missed the bottom half of my post:

[as you will likely miss this one]

1 Like

Keep in mind that you can't specify any command or script to --deploy-hook, the hook must exist and this hook must follow the rules. There are a few ones inside deploy dir but most of them do nothing... yet.

In this case, as @_az suggested, I think it is better the --install-cert approach to copy the certs to the right paths and to launch the required commands using --reloadcmd

1 Like

Thankou All and thankyou @sahsanu I shall try this and report back


As stated in the subject the issue stemmed with cron not the cert or domain i could have written but i think we're all adults here.
Thanks for the option of --deploy-hook.

1 Like

You do realize that is also in a real domain name format - although the domain name appears to be unregistered (at the moment).
[ domain name not relevant ]
Would have been more appropriate.
This has nothing to do with age.

1 Like

im going to register it so i can use in future - thankyou


But then it would be contradictory:
"I bought the domain: So now I own it!"
But then wouldn't you have to change the name or wouldn't that be false advertisement?

1 Like

the irony is missed sir, as THIS issue doesn't have anything to do with a domain that states i dont own it but do XD

1 Like

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