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.
https://crt.sh/?q=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:N/A
It produced this output:N/A
My web server is (include version):vsftpd-3.0.3-33
The operating system my web server runs on is (include version):RedHat 8.4
My hosting provider, if applicable, is: Azure
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): ni
The version of my client is (e.g. output of
certbot --version or
certbot-auto --version if you're using Certbot):certbot 1.14.0
I previously reported my issue at:
Certbot + post hook + vsftpd
the recommendation was to use a script as post hook.
that still hasn't resolved my issue, the cert renewal fails to call the post hook
extract from log at time of cert renewal:
2022-09-16 10:48:39,062:DEBUG:certbot.display.util:Notifying user: new certificate deployed without reload, fullchain is
2022-09-16 10:48:39,063:DEBUG:certbot._internal.plugins.selection:Requested authenticator standalone and installer None
I'm not seeing that from the tiny part of the log file you've posted. The words about not reloading is probably related to the nginx and apache plugins when using the certonly subcommand.
Can you post the related renewal configuration file?
I'm using HTTPS-01.
the renewal files are:-
which currently contains:-
ExecStart=/usr/bin/certbot renew --post-hook "/root/scripts/vsftpd-restart.sh"
and that post-hook script file contains:-
/usr/bin/systemctl status vsftpd.service
/usr/bin/systemctl restart vsftpd.service
/usr/bin/systemctl status vsftpd.service"
the permissions on the script file are:-
"-r-xr-----. 1 root root 324 Jun 30 11:32 /root/scripts/vsftpd-restart.sh
so it has execute permission, and it runs when called manually from the command line.
I'm using HTTPS-01.
need Best Practice - Keep Port 80 Open
I don't want to wander up that avenue unnecessarily.
the actual cert is renewing fine, what is not happening is the ftp application is not being bounced as part of post hook, so the old certificate is still being used by the ftp server application, even though a new certificate is obtained by certbot.
Thanks, that is good to know; as often I cannot see the forest through the trees.
@g-spencer Osiris meant for you to show the renewal file for that cert in
# renew_before_expiry = 30 days
version = 1.14.0
archive_dir = /etc/letsencrypt/archive/ftps.sis.tv
cert = /etc/letsencrypt/live/ftps.sis.tv/cert.pem
privkey = /etc/letsencrypt/live/ftps.sis.tv/privkey.pem
chain = /etc/letsencrypt/live/ftps.sis.tv/chain.pem
fullchain = /etc/letsencrypt/live/ftps.sis.tv/fullchain.pem
# Options used in the renewal process
account = 9fdf...ba1f
pref_challs = http-01,
authenticator = standalone
server = https://acme-v02.api.letsencrypt.org/directory
post_hook = systemctl restart postfix
So no vsftpd post/deploy hook is actually configured, only Postfix. No wonder it doesn't work.
Usually, one would not use the post hook command from within a systemd timer, but configure Certbot properly so that the renewal configuration file contains the appropriate command.
OK thanks for highlighting that, I originally set it up to restart postfix as part of the testing.
I'll look at getting the correct configuration, do I just edit the file ?
why'd you say that?
from my understanding, certbot starts an http listener only for the renewal process and then shuts down again
I've updated /etc/letsencrypt/renewal config file.
will monitor and report on future findings,
thanks Osiris / MikeMcQ
actually, I've just dry-runned the renewal and vsftpd service has been restarted:-
certbot renew --dry-run
why'd you say that?
Because there is no active
HTTPS-01 authentication method allowed.
I think you must have meant
That could be my fault for previously using HTTPS-01 in this Topic when I meant HTTP-01, sorry.
I think I have edited them to be HTTP S-01 now.
Could that be "
Yes, agreed probably better hook. Just noting it is
--deploy-hook in command prompt but translates to
renew_hook in renewal conf file.
yes, sorry, HTTP-01 for the challenge, not HTTPS-01 (well spotted)
rg305 / MikeMcQ,
as for the conf file, the parameter specified in my conf file is 'post_hook', I don't know if that's 'better practice', but seemed to work for the dummy run.