Certbot renew hook not working

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. crt.sh | example.com), 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:
certbot --renew (via cron job)

It produced this output:

2021-09-20 04:33:12,842:DEBUG:certbot._internal.storage:Writing new private key to /etc/letsencrypt/archive/cirs.forward-scatter.com/privkey6.pem.
2021-09-20 04:33:12,842:DEBUG:certbot._internal.storage:Writing certificate to /etc/letsencrypt/archive/cirs.forward-scatter.com/cert6.pem.
2021-09-20 04:33:12,843:DEBUG:certbot._internal.storage:Writing chain to /etc/letsencrypt/archive/cirs.forward-scatter.com/chain6.pem.
2021-09-20 04:33:12,843:DEBUG:certbot._internal.storage:Writing full chain to /etc/letsencrypt/archive/cirs.forward-scatter.com/fullchain6.pem.
2021-09-20 04:33:12,861:DEBUG:certbot._internal.storage:Writing new config /etc/letsencrypt/renewal/cirs.forward-scatter.com.conf.new.
2021-09-20 04:33:12,866:INFO:certbot.compat.misc:Running deploy-hook command: /etc/letsencrypt/renewal-hooks/deploy/reload_apache.sh
2021-09-20 04:33:12,891:DEBUG:certbot.display.util:Notifying user: new certificate deployed without reload, fullchain is
2021-09-20 04:33:12,894:DEBUG:certbot._internal.plugins.selection:Requested authenticator webroot and installer None
2021-09-20 04:33:12,894:DEBUG:certbot.display.util:Notifying user:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
2021-09-20 04:33:12,894:DEBUG:certbot.display.util:Notifying user: Congratulations, all renewals succeeded:
2021-09-20 04:33:12,894:DEBUG:certbot.display.util:Notifying user: /etc/letsencrypt/live/cirs.forward-scatter.com/fullchain.pem (success)
2021-09-20 04:33:12,894:DEBUG:certbot.display.util:Notifying user: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
2021-09-20 04:33:12,894:DEBUG:certbot._internal.renewal:no renewal failures

My web server is (include version):

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

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):

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):

After creating my certificates just fine, the log above has:
Running deploy-hook command: /etc/letsencrypt/renewal-hooks/deploy/reload_apache.sh

The contents of this file are:
apachectl graceful

So I would think my apache has been gracefully restarted and that newer pages would have the updated credentials. However visiting the web site, I'm still seeing the certificate that is about to expire in three weeks.

If I run the deploy/reload_apache.sh by hand (which I just did), it works fine. If I renew my certificate by using a --force-renewal, it works fine. It only fails when the certificate is renewed as part of a cron job.

Might not do what you would be expecting.
Their documentation shows:
apachectl -k graceful
See: Stopping and Restarting Apache HTTP Server - Apache HTTP Server Version 2.4

Symptoms like this make me immediately suspect $PATH problems.

Process trees which are started by cron (such as cron→certbot→reload_apache.sh) often have a more basic $PATH environment variable than e.g. the $PATH you see in your terminal.

If your shell script calls programs without using their absolute path, there's a chance that they won't run properly when invoked by the cron daemon.

I'm not a macOS user so I don't know what the default $PATH is in its crontab, but a fix you could try is to update your deploy hook to use absolute paths for all the programs it invokes, and additionally check the PATH= line in your crontab.


Excellent idea. Unfortunately I won’t find out if this fixes the problem for another two months.

I also noticed that a different launchctl plist includes the following lines:


This adds to the likelihood that you are right. Programs are run without a proper PATH in their environment unless one is set explicitly.

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