Hi !
the hook is used to restart services (like apache/postfix/dovecot) after
a renewal (if there was no user right issue, you need also to
restart/reload chrony to use the new certs... so why don't copy them
before and give them the correct rights ?
Ciao Gerd
Am 22.04.25 um 23:51 schrieb [email protected]:
Why just do that in the renewal-hook/post script ?
Not sure I fully grasp your drift, so apologies if the following is
old news.
The point of the certbot renewal hook is automation of deployment.
Nothing wrong with manually keeping track of the validity of existing
certificates, e.g., periodically checking, setting a reminder
somewhere, having a tool that checks and alerts, or waiting until
someone or something alerts upon finding an expired certificate (as
you will have seen, Let's encrypt will cease sending reminders in the
near future). And then deploying manually (assuming certbot did an
automated renewal, or maybe do that manually as well).
But once the number of certificates to keep track of reaches a certain
level, or the thrill of learning the ropes, i.e., setting this up in
the first place, and going through the motions of deploying manually
after (manual or automated) renewal, diminishes after a few
iterations, automated deployment (after automated renewal) is your
friend.
As always, YMMV.
Kind regards,
Joachim
22.04.2025 22:50:06 Sviatoslav Feshchenko
<[email protected]>:
This seem like a simpler solution! Thank you for sharing!
Sviatoslav
On Tuesday, April 22nd, 2025 at 3:32 AM, Gerd Hoerst
<[email protected]> wrote:
Hi !
Why just do that in the renewal-hook/post script ?
cp -L /etc/letsencrypt/live/time.hoerst.net/cert.pem
/etc/chrony/cert/
cp -L /etc/letsencrypt/live/time.hoerst.net/privkey.pem
/etc/chrony/cert/
chmod g+r /etc/chrony/cert/*
systemctl restart chrony
Ciao Gerd
Am 20.04.25 um 19:40 schrieb [email protected]:
No, there is no issue with the approach you outlined. My
proposal to Debian just included a ready-made script that you
could have used.
But yours works fine as well. Some caveats, e.g., it would
trigger, and do its stuff, on renewal of _every_ certificate on
the system, e.g., if you have separate certificates for multiple
domains, or different certs for chronyd and your web server for
the same domain name. But if you don't have such "advanced"
configurations, no issue (and many, if not most people, probably
don't).
Kind regards
Joachim
20.04.2025 19:27:57 Sviatoslav Feshchenko
<[email protected]>:
Perhaps I am not fully understanding you. I just created a
script in /etc/letsencrypt/renewal-hooks/deploy directory
with the following content:
#!/bin/bash
FULLCHAIN_PATH="${RENEWED_LINEAGE}/fullchain.pem"
PRIVKEY_PATH="${RENEWED_LINEAGE}/privkey.pem"
cat "${FULLCHAIN_PATH}" > /etc/chrony/certs/fullchain.pem
cat "${PRIVKEY_PATH}" > /etc/chrony/certs/privkey.pem
systemctl restart chronyd
systemctl restart gpsd
Then I forced certificate renewal by issuing the following
command:
certbot renew --force-renewal
I can confirm that the above script was executed upon
successful renewal and that chrony and gpsd were restarted
and everything is working fine. Are you then suggesting that
auto renewal will not trigger this script? Is there an issue
with the approach outlined above?
Many thanks for all your help!
Sviatoslav
On Sunday, April 20th, 2025 at 12:53 PM,
[email protected] <[email protected]> wrote:
Indeed the Debian packaging currently does not provide a
script for certbot to call upon certificate renewal.
The script goes in the deploy subfolder, and there is an
entry in the /etc/default/chrony config file to indicate
the certificate name upon whose renewal the script shall be
called (actually, it is called for every renewal, but it
only does stuff when the certificate name is the one
configured).
Kind regards,
Joachim
20.04.2025 18:44:03 Sviatoslav Feshchenko
<[email protected]>:
…
