>
>> 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 <sviatoslav.feshche...@proton.me>:
> This seem like a simpler solution! Thank you for sharing!
>
> Sviatoslav
>
> On Tuesday, April 22nd, 2025 at 3:32 AM, Gerd Hoerst <g...@hoerst.net> 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 kr...@kaffeeschluerfer.com:
>>> 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 <sviatoslav.feshche...@proton.me>:
>>>
>>>> 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, kr...@kaffeeschluerfer.com
>>>> <kr...@kaffeeschluerfer.com> 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
>>>>> <sviatoslav.feshche...@proton.me>:
>>>>>
>>>>>> …
>>>>
>
