Re: [chrony-users] Re: NTS Server Setup with Let's Encrypt
Hi ! Ok now i get some response on openssl s_client -showcerts -connect virgo.hoerst.net:4460 but a lot off error messages... Ciao Gerd Am 25.04.2025 um 12:34 schrieb kr...@kaffeeschluerfer.com: Hello Gerd, Hmm, the first thing I'd look at would probably be to double-check you're seeing the same thing locally than what I see from the outside. I.e., make sure that what I am seeing is not caused by some intermediate entity messing with the communication. E.g., try something like the following, substituting your domain name/port number: openssl s_client -showcerts -connect ptbtime2.ptb.de:4460 Then, I guess you'd already noticed/looked for error messages in the logs, so I assume you not mentioning anything in that regard likely means there weren't any. If chronyd had issues reading the file, and assuming the log level that seems the default on Debian, it would emit a message like the following: Apr 24 15:43:06 debian chronyd[18603]: Could not set credentials : Error while reading file. Depending on the exact issue, there _might_ be other messages with slightly more info, e.g., Apr 24 15:43:06 debian chronyd[18602]: Missing read access to /etc/chrony/key.pem : Permission denied (I found that there is no such additional message when chronyd cannot find the file at all.) So, just to be sure, double-check there aren't any error messages in the logs, and that the ownership and permissions on the files are indeed correct. One thing I noted when re-reading previous messages: Your snipped copies "only" the actual server certificate, when it should be the full chain. I.e., including at least the certificates of any intermediate issuing entities (the root certificate typically is assumed to be available on the client already). I haven't tried that yet, but depending on the server TLS library and how it's used, that _might_ cause a failure in setting the needed credentials. So, if the above did not indicate another issue, using the fullchain.pem file instead of the cert.pem one would probably be the next thing to try as far as changing and checking whether that makes a difference goes. Kind regards, Joachim 25.04.2025 10:58:50 Gerd Hoerst : Hi ! Thanks a lot but i have actual no idea where to start with bug search... the key is a rsa key from letsencrypt and the setup un chrony ntsserverkey /etc/chrony/cert/privkey.pem ntsservercert /etc/chrony/cert/cert.pem ntsdumpdir /var/lib/chrony the chronyc -N serverstats says: NTP packets received : 35975673 NTP packets dropped : 0 Command packets received : 81 Command packets dropped : 0 Client log records dropped : 15616714 NTS-KE connections accepted: 946 NTS-KE connections dropped : 0 Authenticated NTP packets : 0 Interleaved NTP packets : 110 NTP timestamps held : 2403 NTP timestamp span : 766138 NTP daemon RX timestamps : 0 NTP daemon TX timestamps : 35971583 NTP kernel RX timestamps : 35971693 NTP kernel TX timestamps : 110 NTP hardware RX timestamps : 0 NTP hardware TX timestamps : 0 Ciao Gerd Am 24.04.2025 18:13, schrieb kr...@kaffeeschluerfer.com: Hello Gerd, Assuming that your intention is to run an NTS server at the domain you shared as part of your example, just fyi that it is accepting TCP connections, but it seems it is not accepting TLS connections on the default NTS-KE port. In case you're running chronyd (strong likelihood given the forum), in my experience, that can happen when chronyd is not able to read one or more of the credential files, e.g., because chronyd cannot find it/them in the place configured, or chronyd doesn't have read rights for the file(s). Kind regards, Joachim 23.04.2025 11:37:09 kr...@kaffeeschluerfer.com: so why don't copy them before and give them the correct right ? Sure, but why not let the deploy hook do that as well for you? the hook is used to restart services Yes, if that is all you tell it to do. But it can do more than that. The deploy hook does whatever you tell it to do, as defined by the script one places in the deploy subfolder. Kind regards, Joachim 23.04.2025 11:31:04 Gerd Hoerst : 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 kr...@kaffeeschluerfer.com: 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 fu
Re: [chrony-users] Re: NTS Server Setup with Let's Encrypt
Hello Gerd, Out of curiosity, I checked: The missing intermediate certificate is probably not the (primary) issue in this case. While a client would usually not be able to successfully connect to the server, that is not because the server does not engage in a TLS negotiation (as seems to be the case with your server). But because the client will not be able to verify the server certificate without the intermediate certificate(s), and thus abort the TLS negotiation from its end. So using the certificate chain, rather than the server certificate on it's own, will still be needed once the primary issue is resolved. Looking once more at your scriplet below, I note it only sets _permissions_ on the key file, but not _ownership_. So while the ownership _might_ be ok because of circumstances not shown, I think chances are that they are not (though you not reporting error messages in chronyd's log output still puzzles me) So you might want to check once more that the _group_ on the key file is the one that chronyd is running under (_chrony in Debian). Compare, e.g., with the chrony.keys file in /etc/chrony, which, when installed from a typical maintainer package and not touched afterwards, is subject to the same/very similar constraints regarding permissions and ownership. Kind regards, Joachim 25.04.2025 12:34:54 kr...@kaffeeschluerfer.com: > Hello Gerd, > > Hmm, the first thing I'd look at would probably be to double-check you're > seeing the same thing locally than what I see from the outside. I.e., make > sure that what I am seeing is not caused by some intermediate entity messing > with the communication. E.g., try something like the following, substituting > your domain name/port number: > > openssl s_client -showcerts -connect ptbtime2.ptb.de:4460 > > Then, I guess you'd already noticed/looked for error messages in the logs, so > I assume you not mentioning anything in that regard likely means there > weren't any. If chronyd had issues reading the file, and assuming the log > level that seems the default on Debian, it would emit a message like the > following: > > Apr 24 15:43:06 debian chronyd[18603]: Could not set credentials : Error > while reading file. > > Depending on the exact issue, there _might_ be other messages with slightly > more info, e.g., > > Apr 24 15:43:06 debian chronyd[18602]: Missing read access to > /etc/chrony/key.pem : Permission denied > > (I found that there is no such additional message when chronyd cannot find > the file at all.) > > So, just to be sure, double-check there aren't any error messages in the > logs, and that the ownership and permissions on the files are indeed correct. > > One thing I noted when re-reading previous messages: Your snipped copies > "only" the actual server certificate, when it should be the full chain. I.e., > including at least the certificates of any intermediate issuing entities (the > root certificate typically is assumed to be available on the client already). > I haven't tried that yet, but depending on the server TLS library and how > it's used, that _might_ cause a failure in setting the needed credentials. > So, if the above did not indicate another issue, using the fullchain.pem file > instead of the cert.pem one would probably be the next thing to try as far as > changing and checking whether that makes a difference goes. > > Kind regards, > > Joachim > > 25.04.2025 10:58:50 Gerd Hoerst : > >> Hi ! >> >> Thanks a lot but i have actual no idea where to start with bug search... >> the key is a rsa key from letsencrypt >> >> and the setup un chrony >> >> ntsserverkey /etc/chrony/cert/privkey.pem >> ntsservercert /etc/chrony/cert/cert.pem >> ntsdumpdir /var/lib/chrony >> >> the chronyc -N serverstats says: >> >> NTP packets received : 35975673 >> NTP packets dropped : 0 >> Command packets received : 81 >> Command packets dropped : 0 >> Client log records dropped : 15616714 >> NTS-KE connections accepted: 946 >> NTS-KE connections dropped : 0 >> Authenticated NTP packets : 0 >> Interleaved NTP packets : 110 >> NTP timestamps held : 2403 >> NTP timestamp span : 766138 >> NTP daemon RX timestamps : 0 >> NTP daemon TX timestamps : 35971583 >> NTP kernel RX timestamps : 35971693 >> NTP kernel TX timestamps : 110 >> NTP hardware RX timestamps : 0 >> NTP hardware TX timestamps : 0 >> >> Ciao Gerd >> >> Am 24.04.2025 18:13, schrieb kr...@kaffeeschluerfer.com: >>> Hello Gerd, >>> Assuming that your intention is to run an NTS server at the domain you >>> shared as part of your example, just fyi that it is accepting TCP >>> connections, but it seems it is not accepting TLS connections on the >>> default NTS-KE port. In case you're running chronyd (strong likelihood >>> given the forum), in my experience, that can happen when chronyd is >>> not able to read one or more of the credential files, e.g., because >>> chronyd cannot find it/them in the
Re: [chrony-users] Re: NTS Server Setup with Let's Encrypt
Hello Gerd, Hmm, the first thing I'd look at would probably be to double-check you're seeing the same thing locally than what I see from the outside. I.e., make sure that what I am seeing is not caused by some intermediate entity messing with the communication. E.g., try something like the following, substituting your domain name/port number: openssl s_client -showcerts -connect ptbtime2.ptb.de:4460 Then, I guess you'd already noticed/looked for error messages in the logs, so I assume you not mentioning anything in that regard likely means there weren't any. If chronyd had issues reading the file, and assuming the log level that seems the default on Debian, it would emit a message like the following: Apr 24 15:43:06 debian chronyd[18603]: Could not set credentials : Error while reading file. Depending on the exact issue, there _might_ be other messages with slightly more info, e.g., Apr 24 15:43:06 debian chronyd[18602]: Missing read access to /etc/chrony/key.pem : Permission denied (I found that there is no such additional message when chronyd cannot find the file at all.) So, just to be sure, double-check there aren't any error messages in the logs, and that the ownership and permissions on the files are indeed correct. One thing I noted when re-reading previous messages: Your snipped copies "only" the actual server certificate, when it should be the full chain. I.e., including at least the certificates of any intermediate issuing entities (the root certificate typically is assumed to be available on the client already). I haven't tried that yet, but depending on the server TLS library and how it's used, that _might_ cause a failure in setting the needed credentials. So, if the above did not indicate another issue, using the fullchain.pem file instead of the cert.pem one would probably be the next thing to try as far as changing and checking whether that makes a difference goes. Kind regards, Joachim 25.04.2025 10:58:50 Gerd Hoerst : > Hi ! > > Thanks a lot but i have actual no idea where to start with bug search... > the key is a rsa key from letsencrypt > > and the setup un chrony > > ntsserverkey /etc/chrony/cert/privkey.pem > ntsservercert /etc/chrony/cert/cert.pem > ntsdumpdir /var/lib/chrony > > the chronyc -N serverstats says: > > NTP packets received : 35975673 > NTP packets dropped : 0 > Command packets received : 81 > Command packets dropped : 0 > Client log records dropped : 15616714 > NTS-KE connections accepted: 946 > NTS-KE connections dropped : 0 > Authenticated NTP packets : 0 > Interleaved NTP packets : 110 > NTP timestamps held : 2403 > NTP timestamp span : 766138 > NTP daemon RX timestamps : 0 > NTP daemon TX timestamps : 35971583 > NTP kernel RX timestamps : 35971693 > NTP kernel TX timestamps : 110 > NTP hardware RX timestamps : 0 > NTP hardware TX timestamps : 0 > > Ciao Gerd > > Am 24.04.2025 18:13, schrieb kr...@kaffeeschluerfer.com: >> Hello Gerd, >> Assuming that your intention is to run an NTS server at the domain you >> shared as part of your example, just fyi that it is accepting TCP >> connections, but it seems it is not accepting TLS connections on the >> default NTS-KE port. In case you're running chronyd (strong likelihood >> given the forum), in my experience, that can happen when chronyd is >> not able to read one or more of the credential files, e.g., because >> chronyd cannot find it/them in the place configured, or chronyd >> doesn't have read rights for the file(s). >> Kind regards, >> Joachim >> 23.04.2025 11:37:09 kr...@kaffeeschluerfer.com: >> so why don't copy them before and give them the correct right ? >>> Sure, but why not let the deploy hook do that as well for you? >>> the hook is used to restart services >>> Yes, if that is all you tell it to do. But it can do more than that. >>> >>> The deploy hook does whatever you tell it to do, as defined by the >>> script one places in the deploy subfolder. >>> Kind regards, >>> Joachim >>> 23.04.2025 11:31:04 Gerd Hoerst : >>> 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 kr...@kaffeeschluerfer.com: >>> 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)
Re: [chrony-users] Re: NTS Server Setup with Let's Encrypt
Hi ! Thanks a lot but i have actual no idea where to start with bug search... the key is a rsa key from letsencrypt and the setup un chrony ntsserverkey /etc/chrony/cert/privkey.pem ntsservercert /etc/chrony/cert/cert.pem ntsdumpdir /var/lib/chrony the chronyc -N serverstats says: NTP packets received : 35975673 NTP packets dropped: 0 Command packets received : 81 Command packets dropped: 0 Client log records dropped : 15616714 NTS-KE connections accepted: 946 NTS-KE connections dropped : 0 Authenticated NTP packets : 0 Interleaved NTP packets: 110 NTP timestamps held: 2403 NTP timestamp span : 766138 NTP daemon RX timestamps : 0 NTP daemon TX timestamps : 35971583 NTP kernel RX timestamps : 35971693 NTP kernel TX timestamps : 110 NTP hardware RX timestamps : 0 NTP hardware TX timestamps : 0 Ciao Gerd Am 24.04.2025 18:13, schrieb kr...@kaffeeschluerfer.com: Hello Gerd, Assuming that your intention is to run an NTS server at the domain you shared as part of your example, just fyi that it is accepting TCP connections, but it seems it is not accepting TLS connections on the default NTS-KE port. In case you're running chronyd (strong likelihood given the forum), in my experience, that can happen when chronyd is not able to read one or more of the credential files, e.g., because chronyd cannot find it/them in the place configured, or chronyd doesn't have read rights for the file(s). Kind regards, Joachim 23.04.2025 11:37:09 kr...@kaffeeschluerfer.com: so why don't copy them before and give them the correct right ? Sure, but why not let the deploy hook do that as well for you? the hook is used to restart services Yes, if that is all you tell it to do. But it can do more than that. The deploy hook does whatever you tell it to do, as defined by the script one places in the deploy subfolder. Kind regards, Joachim 23.04.2025 11:31:04 Gerd Hoerst : 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 kr...@kaffeeschluerfer.com: 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 : This seem like a simpler solution! Thank you for sharing! Sviatoslav On Tuesday, April 22nd, 2025 at 3:32 AM, Gerd Hoerst 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: … -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Re: NTS Server Setup with Let's Encrypt
Hello Gerd, Assuming that your intention is to run an NTS server at the domain you shared as part of your example, just fyi that it is accepting TCP connections, but it seems it is not accepting TLS connections on the default NTS-KE port. In case you're running chronyd (strong likelihood given the forum), in my experience, that can happen when chronyd is not able to read one or more of the credential files, e.g., because chronyd cannot find it/them in the place configured, or chronyd doesn't have read rights for the file(s). Kind regards, Joachim 23.04.2025 11:37:09 kr...@kaffeeschluerfer.com: >> so why don't copy them before and give them the correct right ? > > Sure, but why not let the deploy hook do that as well for you? > > >> the hook is used to restart services > > Yes, if that is all you tell it to do. But it can do more than that. > > The deploy hook does whatever you tell it to do, as defined by the script one > places in the deploy subfolder. > > Kind regards, > > Joachim > > 23.04.2025 11:31:04 Gerd Hoerst : > >> 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 kr...@kaffeeschluerfer.com: > 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 : >>> This seem like a simpler solution! Thank you for sharing! Sviatoslav On Tuesday, April 22nd, 2025 at 3:32 AM, Gerd Hoerst 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: >> …
Re: [chrony-users] Re: NTS Server Setup with Let's Encrypt
> so why don't copy them before and give them the correct right ? Sure, but why not let the deploy hook do that as well for you? > the hook is used to restart services Yes, if that is all you tell it to do. But it can do more than that. The deploy hook does whatever you tell it to do, as defined by the script one places in the deploy subfolder. Kind regards, Joachim 23.04.2025 11:31:04 Gerd Hoerst : > 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 kr...@kaffeeschluerfer.com: 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 : >> >>> This seem like a simpler solution! Thank you for sharing! >>> >>> Sviatoslav >>> >>> On Tuesday, April 22nd, 2025 at 3:32 AM, Gerd Hoerst >>> 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 > : > >> … >>>
Re: [chrony-users] Re: NTS Server Setup with Let's Encrypt
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 kr...@kaffeeschluerfer.com:
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
:
This seem like a simpler solution! Thank you for sharing!
Sviatoslav
On Tuesday, April 22nd, 2025 at 3:32 AM, Gerd Hoerst
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
:
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 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
:
…
Re: [chrony-users] Re: NTS Server Setup with Let's Encrypt
>
>> 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 :
> This seem like a simpler solution! Thank you for sharing!
>
> Sviatoslav
>
> On Tuesday, April 22nd, 2025 at 3:32 AM, Gerd Hoerst 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 :
>>>
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
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
> :
>
>> …
>
Re: [chrony-users] Re: NTS Server Setup with Let's Encrypt
This seem like a simpler solution! Thank you for sharing!
Sviatoslav
On Tuesday, April 22nd, 2025 at 3:32 AM, Gerd Hoerst 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
>> [](mailto: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
>>> [](mailto: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
[](mailto:sviatoslav.feshche...@proton.me):
> You are a good man! Thank you for doing that.
>
> But this raises a question. Does that means that Debian 12 currently does
> not have the ability to execute these scripts upon certificate renewal? I
> just checked and I have the following directory present on the system:
> /etc/letsencrypt/renewal-hooks
>
> And inside of it, there are 3 sub-directories:
>
> deploy
> post
> pre
>
> I haven' tried yet, but if I place a script on the deploy folder, would
> it not execute once the certificate is renewed?
>
> Sviatoslav
>
> On Sunday, April 20th, 2025 at 12:36 PM, kr...@kaffeeschluerfer.com
> [](mailto:kr...@kaffeeschluerfer.com) wrote:
>
>>> This script can copy the certificates after renewal and restart chrony,
>>> so it should be easy to automate this.
>>
>> I proposed for such a certbot renewal hook script to be included in the
>> Debian package, maybe it is of use to you. Works well for me so far, I
>> only have minor update in the pipeline to only restart chronyd when it
>> is actually running.
>>
>> https://salsa.debian.org/debian/chrony/-/merge_requests/14
>>
>> Kind regards,
>>
>> Joachim
>>
>> 20.04.2025 18:20:48 Sviatoslav Feshchenko
>> [](mailto:sviatoslav.feshche...@proton.me):
>>
>>> Thank you James and Rob.
>>>
>>> I think Rob is right. No matter what I did with permission, it just
>>> didn't work. As a workaround, I simply copied the certificates to a
>>> different directory and chrony now loads the certificates without
>>> issues, and I am now able to synchronize to the server using NTS!
>>>
>>> Copying the certificates may be an acceptable solution, because certbot
>>> offers pre and post validation hooks, which will execute a script
>>> before/after renewal. This script can copy the certificates after
>>> renewal and restart chrony, so it should be easy to automate this.
>>>
>>> Many many thanks!
>>> Sviatoslav
>>>
>>> On Sunday, April 20th, 2025 at 11:53 AM, Rob Janssen
>>> [](mailto:ch
Re: [chrony-users] Re: NTS Server Setup with Let's Encrypt
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
:
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 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
:
You are a good man! Thank you for doing that.
But this raises a question. Does that means that Debian 12
currently does not have the ability to execute these scripts
upon certificate renewal? I just checked and I have the
following directory present on the system:
|/etc/letsencrypt/renewal-hooks|
And inside of it, there are 3 sub-directories:
deploy
post
pre
I haven' tried yet, but if I place a script on the deploy
folder, would it not execute once the certificate is renewed?
Sviatoslav
On Sunday, April 20th, 2025 at 12:36 PM,
kr...@kaffeeschluerfer.com wrote:
This script can copy the certificates after renewal and
restart chrony, so it should be easy to automate this.
I proposed for such a certbot renewal hook script to be
included in the Debian package, maybe it is of use to you.
Works well for me so far, I only have minor update in the
pipeline to only restart chronyd when it is actually running.
https://salsa.debian.org/debian/chrony/-/merge_requests/14
Kind regards,
Joachim
20.04.2025 18:20:48 Sviatoslav Feshchenko
:
Thank you James and Rob.
I think Rob is right. No matter what I did with
permission, it just didn't work. As a workaround, I
simply copied the certificates to a different directory
and chrony now loads the certificates without issues,
and I am now able to synchronize to the server using NTS!
Copying the certificates may be an acceptable solution,
because certbot offers pre and post validation hooks,
which will execute a script before/after renewal. This
script can copy the certificates after renewal and
restart chrony, so it should be easy to automate this.
Many many thanks!
Sviatoslav
On Sunday, April 20th, 2025 at 11:53 AM, Rob Janssen
wrote:
…
Re: [chrony-users] Re: NTS Server Setup with Let's Encrypt
Running certbot will work without the need for a webserver (it spawns a trivial one) then a posthook will do.At least that is what I remember from setting up a rasp pi based oneRaspberrySecureTimeServer/Building-a-Raspberry-Secure-Timeserver.md at master · Kolkman/RaspberrySecureTimeServergithub.com-Composed on a mobile device, with clumsy thumbs and unpredictable autocorrect.On 20 Apr 2025, at 18:53, 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 : You are a good man! Thank you for doing that. But this raises a question. Does that means that Debian 12 currently does not have the ability to execute these scripts upon certificate renewal? I just checked and I have the following directory present on the system: /etc/letsencrypt/renewal-hooks And inside of it, there are 3 sub-directories: deploy post pre I haven' tried yet, but if I place a script on the deploy folder, would it not execute once the certificate is renewed? Sviatoslav On Sunday, April 20th, 2025 at 12:36 PM, kr...@kaffeeschluerfer.com wrote: This script can copy the certificates after renewal and restart chrony, so it should be easy to automate this. I proposed for such a certbot renewal hook script to be included in the Debian package, maybe it is of use to you. Works well for me so far, I only have minor update in the pipeline to only restart chronyd when it is actually running. https://salsa.debian.org/debian/chrony/-/merge_requests/14 Kind regards, Joachim 20.04.2025 18:20:48 Sviatoslav Feshchenko : Thank you James and Rob. I think Rob is right. No matter what I did with permission, it just didn't work. As a workaround, I simply copied the certificates to a different directory and chrony now loads the certificates without issues, and I am now able to synchronize to the server using NTS! Copying the certificates may be an acceptable solution, because certbot offers pre and post validation hooks, which will execute a script before/after renewal. This script can copy the certificates after renewal and restart chrony, so it should be easy to automate this. Many many thanks! Sviatoslav On Sunday, April 20th, 2025 at 11:53 AM, Rob Janssen wrote: Modern Linux systems often have something like SELinux which limits where certain programs can open files. Just putting extra config files in "myfolder" isn't going to work, and the error messages can be misleading... Rob On 2025-04-20 14:58, Sviatoslav Feshchenko wrote: Made a bit of progress with the issue. The server error log has the following entry after startup: "Could not set credentials : Error while reading file." This means it can't read the certificate files. Tried to change permissions using the following command: setfacl -R -m u:_chrony:rwx myfolder Wher myfolder is the directory where the certificates are located. Still not working, giving same error message. What would be the correct way of giving chrony permissions to read the certificate files created by certbot, without breaking the web server? I am running Debian 12.
Re: [chrony-users] Re: NTS Server Setup with Let's Encrypt
Glad I could be of assistance.
Kind regards
Joachim
20.04.2025 20:06:36 Sviatoslav Feshchenko :
> My setup if very straightforward, with only one domain and set of
> certificates. So it works well enough for me.
>
> I look forward to check out your proposal to Debian. Hopefully it gets merged
> soon and make things easier in this respect.
>
> It would also be nice to have a professional tutorial on the chrony website
> using let's encrypt certificates. Maybe if Miroslav has some extra time and
> interest, I think that's something of value that can be added, or at least a
> link to such a tutorial.
>
> I don't think I'll have any issues with the permissions going forward either.
> Again, I tried with a forced renewal and it worked perfectly fine!
>
> Many many thanks to each of you for the assistance.
>
> Warm regards,
>
> Sviatoslav
>
>
> On Sunday, April 20th, 2025 at 1:47 PM, kr...@kaffeeschluerfer.com
> wrote:
>> Maybe one thing, probably not relevant for you (since you had previously
>> copied the pem files, and manually set the proper permissions on them): If
>> there aren't preexisting pem files with proper permissions in your
>> destination paths, the files that your approach would create from scratch
>> might not have the right permissions.
>>
>> Kind regards,
>>
>> Joachim
>>
>> 20.04.2025 19:40:44 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 :
>>>
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
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
> :
>
>> …
>
Re: [chrony-users] Re: NTS Server Setup with Let's Encrypt
My setup if very straightforward, with only one domain and set of certificates.
So it works well enough for me.
I look forward to check out your proposal to Debian. Hopefully it gets merged
soon and make things easier in this respect.
It would also be nice to have a professional tutorial on the chrony website
using let's encrypt certificates. Maybe if Miroslav has some extra time and
interest, I think that's something of value that can be added, or at least a
link to such a tutorial.
I don't think I'll have any issues with the permissions going forward either.
Again, I tried with a forced renewal and it worked perfectly fine!
Many many thanks to each of you for the assistance.
Warm regards,
Sviatoslav
On Sunday, April 20th, 2025 at 1:47 PM, kr...@kaffeeschluerfer.com
wrote:
> Maybe one thing, probably not relevant for you (since you had previously
> copied the pem files, and manually set the proper permissions on them): If
> there aren't preexisting pem files with proper permissions in your
> destination paths, the files that your approach would create from scratch
> might not have the right permissions.
>
> Kind regards,
>
> Joachim
>
> 20.04.2025 19:40:44 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 :
>>
>>> 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 chronydsystemctl 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
>>> 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
:
> You are a good man! Thank you for doing that.
>
> But this raises a question. Does that means that Debian 12 currently does
> not have the ability to execute these scripts upon certificate renewal? I
> just checked and I have the following directory present on the system:
> /etc/letsencrypt/renewal-hooks
>
> And inside of it, there are 3 sub-directories:
>
> deploy
> post
> pre
>
> I haven' tried yet, but if I place a script on the deploy folder, would
> it not execute once the certificate is renewed?
>
> Sviatoslav
>
> On Sunday, April 20th, 2025 at 12:36 PM, kr...@kaffeeschluerfer.com
> wrote:
>
>>> …
>>
>> I proposed for such a certbot renewal hook script to be included in the
>> Debian package, maybe it is of use to you. Works well for me so far, I
>> only have minor update in the pipeline to only restart chronyd when it
>> is actually running.
>>
>> https://salsa.debian.org/debian/chrony/-/merge_requests/14
>>
>> Kind regards,
>>
>> Joachim
>>
>> 20.04.2025 18:20:48 Sviatoslav Feshchenko
>> :
>>
>>> …
Re: [chrony-users] Re: NTS Server Setup with Let's Encrypt
Maybe one thing, probably not relevant for you (since you had previously copied
the pem files, and manually set the proper permissions on them): If there
aren't preexisting pem files with proper permissions in your destination paths,
the files that your approach would create from scratch might not have the right
permissions.
Kind regards,
Joachim
20.04.2025 19:40:44 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 :
>
>> 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
>> 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 :
>>>
You are a good man! Thank you for doing that.
But this raises a question. Does that means that Debian 12 currently does
not have the ability to execute these scripts upon certificate renewal? I
just checked and I have the following directory present on the system:
*/etc/letsencrypt/renewal-hooks*
And inside of it, there are 3 sub-directories:
deploy
post
pre
I haven' tried yet, but if I place a script on the deploy folder, would it
not execute once the certificate is renewed?
Sviatoslav
On Sunday, April 20th, 2025 at 12:36 PM, kr...@kaffeeschluerfer.com
wrote:
>> …
>
> I proposed for such a certbot renewal hook script to be included in the
> Debian package, maybe it is of use to you. Works well for me so far, I
> only have minor update in the pipeline to only restart chronyd when it is
> actually running.
>
> https://salsa.debian.org/debian/chrony/-/merge_requests/14
>
> Kind regards,
>
> Joachim
>
> 20.04.2025 18:20:48 Sviatoslav Feshchenko
> :
>
>> …
>>
Re: [chrony-users] Re: NTS Server Setup with Let's Encrypt
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 :
> 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
> 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 :
>>
>>> You are a good man! Thank you for doing that.
>>>
>>> But this raises a question. Does that means that Debian 12 currently does
>>> not have the ability to execute these scripts upon certificate renewal? I
>>> just checked and I have the following directory present on the system:
>>> */etc/letsencrypt/renewal-hooks*
>>>
>>> And inside of it, there are 3 sub-directories:
>>>
>>> deploy
>>> post
>>> pre
>>>
>>> I haven' tried yet, but if I place a script on the deploy folder, would it
>>> not execute once the certificate is renewed?
>>>
>>> Sviatoslav
>>>
>>> On Sunday, April 20th, 2025 at 12:36 PM, kr...@kaffeeschluerfer.com
>>> wrote:
> This script can copy the certificates after renewal and restart chrony,
> so it should be easy to automate this.
I proposed for such a certbot renewal hook script to be included in the
Debian package, maybe it is of use to you. Works well for me so far, I
only have minor update in the pipeline to only restart chronyd when it is
actually running.
https://salsa.debian.org/debian/chrony/-/merge_requests/14
Kind regards,
Joachim
20.04.2025 18:20:48 Sviatoslav Feshchenko
:
> Thank you James and Rob.
>
> I think Rob is right. No matter what I did with permission, it just
> didn't work. As a workaround, I simply copied the certificates to a
> different directory and chrony now loads the certificates without issues,
> and I am now able to synchronize to the server using NTS!
>
> Copying the certificates may be an acceptable solution, because certbot
> offers pre and post validation hooks, which will execute a script
> before/after renewal. This script can copy the certificates after renewal
> and restart chrony, so it should be easy to automate this.
>
> Many many thanks!
>
> Sviatoslav
>
>
>
> On Sunday, April 20th, 2025 at 11:53 AM, Rob Janssen
> wrote:
>> …
>
>>>
>
Re: [chrony-users] Re: NTS Server Setup with Let's Encrypt
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 chronydsystemctl 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
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 :
>
>> You are a good man! Thank you for doing that.
>>
>> But this raises a question. Does that means that Debian 12 currently does
>> not have the ability to execute these scripts upon certificate renewal? I
>> just checked and I have the following directory present on the system:
>> /etc/letsencrypt/renewal-hooks
>>
>> And inside of it, there are 3 sub-directories:
>>
>> deploy
>> post
>> pre
>>
>> I haven' tried yet, but if I place a script on the deploy folder, would it
>> not execute once the certificate is renewed?
>>
>> Sviatoslav
>>
>> On Sunday, April 20th, 2025 at 12:36 PM, kr...@kaffeeschluerfer.com
>> wrote:
>>
This script can copy the certificates after renewal and restart chrony, so
it should be easy to automate this.
>>>
>>> I proposed for such a certbot renewal hook script to be included in the
>>> Debian package, maybe it is of use to you. Works well for me so far, I only
>>> have minor update in the pipeline to only restart chronyd when it is
>>> actually running.
>>>
>>> https://salsa.debian.org/debian/chrony/-/merge_requests/14
>>>
>>> Kind regards,
>>>
>>> Joachim
>>>
>>> 20.04.2025 18:20:48 Sviatoslav Feshchenko :
>>>
Thank you James and Rob.
I think Rob is right. No matter what I did with permission, it just didn't
work. As a workaround, I simply copied the certificates to a different
directory and chrony now loads the certificates without issues, and I am
now able to synchronize to the server using NTS!
Copying the certificates may be an acceptable solution, because certbot
offers pre and post validation hooks, which will execute a script
before/after renewal. This script can copy the certificates after renewal
and restart chrony, so it should be easy to automate this.
Many many thanks!
Sviatoslav
On Sunday, April 20th, 2025 at 11:53 AM, Rob Janssen
wrote:
> Modern Linux systems often have something like SELinux which limits where
> certain programs can open files.
> Just putting extra config files in "myfolder" isn't going to work, and
> the error messages can be misleading...
>
> Rob
>
> On 2025-04-20 14:58, Sviatoslav Feshchenko wrote:
>
>> Made a bit of progress with the issue. The server error log has the
>> following entry after startup: "Could not set credentials : Error while
>> reading file."
>>
>> This means it can't read the certificate files.
>>
>> Tried to change permissions using the following command:
>>
>> setfacl -R -m u:_chrony:rwx myfolder
>>
>> Wher myfolder is the directory where the certificates are located.
>>
>> Still not working, giving same error message.
>>
>> What would be the correct way of giving chrony permissions to read the
>> certificate files created by certbot, without breaking the web server? I
>> am running Debian 12.
>>
>> Many thanks!
>>
>> Sviatoslav
>>
>> On Saturday, April 19th, 2025 at 9:02 PM, Sviatoslav Feshchenko
>> [](mailto:sviatoslav.feshche...@proton.me)
>> wrote:
>>
>>> …
Re: [chrony-users] Re: NTS Server Setup with Let's Encrypt
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 : > You are a good man! Thank you for doing that. > > But this raises a question. Does that means that Debian 12 currently does not > have the ability to execute these scripts upon certificate renewal? I just > checked and I have the following directory present on the system: > */etc/letsencrypt/renewal-hooks* > > And inside of it, there are 3 sub-directories: > > deploy > post > pre > > I haven' tried yet, but if I place a script on the deploy folder, would it > not execute once the certificate is renewed? > > Sviatoslav > > On Sunday, April 20th, 2025 at 12:36 PM, kr...@kaffeeschluerfer.com > wrote: >>> This script can copy the certificates after renewal and restart chrony, so >>> it should be easy to automate this. >> >> I proposed for such a certbot renewal hook script to be included in the >> Debian package, maybe it is of use to you. Works well for me so far, I only >> have minor update in the pipeline to only restart chronyd when it is >> actually running. >> >> https://salsa.debian.org/debian/chrony/-/merge_requests/14 >> >> Kind regards, >> >> Joachim >> >> 20.04.2025 18:20:48 Sviatoslav Feshchenko : >> >>> Thank you James and Rob. >>> >>> I think Rob is right. No matter what I did with permission, it just didn't >>> work. As a workaround, I simply copied the certificates to a different >>> directory and chrony now loads the certificates without issues, and I am >>> now able to synchronize to the server using NTS! >>> >>> Copying the certificates may be an acceptable solution, because certbot >>> offers pre and post validation hooks, which will execute a script >>> before/after renewal. This script can copy the certificates after renewal >>> and restart chrony, so it should be easy to automate this. >>> >>> Many many thanks! >>> >>> Sviatoslav >>> >>> >>> >>> On Sunday, April 20th, 2025 at 11:53 AM, Rob Janssen >>> wrote: Modern Linux systems often have something like SELinux which limits where certain programs can open files. Just putting extra config files in "myfolder" isn't going to work, and the error messages can be misleading... Rob On 2025-04-20 14:58, Sviatoslav Feshchenko wrote: > Made a bit of progress with the issue. The server error log has the > following entry after startup: "Could not set credentials : Error while > reading file." > > This means it can't read the certificate files. > > Tried to change permissions using the following command: > *setfacl -R -m u:_chrony:rwx myfolder* > Wher* myfolder* is the directory where the certificates are located. > > Still not working, giving same error message. > > What would be the correct way of giving chrony permissions to read the > certificate files created by certbot, without breaking the web server? I > am running Debian 12. > > Many thanks! > > Sviatoslav > > On Saturday, April 19th, 2025 at 9:02 PM, Sviatoslav Feshchenko > wrote: >> … > >>> >
Re: [chrony-users] Re: NTS Server Setup with Let's Encrypt
You are a good man! Thank you for doing that. But this raises a question. Does that means that Debian 12 currently does not have the ability to execute these scripts upon certificate renewal? I just checked and I have the following directory present on the system: /etc/letsencrypt/renewal-hooks And inside of it, there are 3 sub-directories: deploy post pre I haven' tried yet, but if I place a script on the deploy folder, would it not execute once the certificate is renewed? Sviatoslav On Sunday, April 20th, 2025 at 12:36 PM, kr...@kaffeeschluerfer.com wrote: >> This script can copy the certificates after renewal and restart chrony, so >> it should be easy to automate this. > > I proposed for such a certbot renewal hook script to be included in the > Debian package, maybe it is of use to you. Works well for me so far, I only > have minor update in the pipeline to only restart chronyd when it is actually > running. > > https://salsa.debian.org/debian/chrony/-/merge_requests/14 > > Kind regards, > > Joachim > > 20.04.2025 18:20:48 Sviatoslav Feshchenko : > >> Thank you James and Rob. >> >> I think Rob is right. No matter what I did with permission, it just didn't >> work. As a workaround, I simply copied the certificates to a different >> directory and chrony now loads the certificates without issues, and I am now >> able to synchronize to the server using NTS! >> >> Copying the certificates may be an acceptable solution, because certbot >> offers pre and post validation hooks, which will execute a script >> before/after renewal. This script can copy the certificates after renewal >> and restart chrony, so it should be easy to automate this. >> >> Many many thanks! >> Sviatoslav >> >> On Sunday, April 20th, 2025 at 11:53 AM, Rob Janssen >> wrote: >> >>> Modern Linux systems often have something like SELinux which limits where >>> certain programs can open files. >>> Just putting extra config files in "myfolder" isn't going to work, and the >>> error messages can be misleading... >>> >>> Rob >>> >>> On 2025-04-20 14:58, Sviatoslav Feshchenko wrote: >>> Made a bit of progress with the issue. The server error log has the following entry after startup: "Could not set credentials : Error while reading file." This means it can't read the certificate files. Tried to change permissions using the following command: setfacl -R -m u:_chrony:rwx myfolder Wher myfolder is the directory where the certificates are located. Still not working, giving same error message. What would be the correct way of giving chrony permissions to read the certificate files created by certbot, without breaking the web server? I am running Debian 12. Many thanks! Sviatoslav On Saturday, April 19th, 2025 at 9:02 PM, Sviatoslav Feshchenko [](mailto:sviatoslav.feshche...@proton.me) wrote: > Hello, > > I am trying to set up a NTS server suing Let's Encrypt certificate for a > web server, but haven't been successful. Here are the steps I've taken: > > - Set up a web server on the same machine as chrony. > - Set up Let's Encrypt certificates using the certbot tool and the web > server is properly serving a test page via HTTPS. > - In chrony.conf have the following directives relating to NTS: > > - ntsservercert - set to point to the certificate created by certbot for > the web server > - ntsserverkey - set to point to the key created by certbot for the web > server > - Chrony is working just fine in all other respects. > - Firewall is configured to allow traffic on port 4460 and 123 and routes > all such traffic to the chrony server. > > I have not taken any other steps other than what's described above. > > I am testing the NTS server by using a different machine in a different > location on a different public IP that's running chrony and pointing to > the server with nts directive. I will refer to this as the client machine. > > The client machine does not appear to authenticate the server properly > for some reason. Running authdata command in chronyc shows "NTS" in mode > column and a small number in column Atmp. All other columns are zero. > > On the server machine, running serverstats command in chronyc shows the > same number as the client machine in column Atmp, in row "NTS-KE > connections accepted. This suggests that the server is receiving an NTS > request. Authenticated NTP packets is zero however, suggesting that > authentication on the client side failed. > > Also, not sure if it matters, but my certificate points to a sub-domain, > which is the same sub-domain as I am using as the server name on the > client side. However, when I run "sources" command on the client machine, > the server domain name resolves to
Re: [chrony-users] Re: NTS Server Setup with Let's Encrypt
> This script can copy the certificates after renewal and restart chrony, so it > should be easy to automate this. I proposed for such a certbot renewal hook script to be included in the Debian package, maybe it is of use to you. Works well for me so far, I only have minor update in the pipeline to only restart chronyd when it is actually running. https://salsa.debian.org/debian/chrony/-/merge_requests/14 Kind regards, Joachim 20.04.2025 18:20:48 Sviatoslav Feshchenko : > Thank you James and Rob. > > I think Rob is right. No matter what I did with permission, it just didn't > work. As a workaround, I simply copied the certificates to a different > directory and chrony now loads the certificates without issues, and I am now > able to synchronize to the server using NTS! > > Copying the certificates may be an acceptable solution, because certbot > offers pre and post validation hooks, which will execute a script > before/after renewal. This script can copy the certificates after renewal and > restart chrony, so it should be easy to automate this. > > Many many thanks! > > Sviatoslav > > > > On Sunday, April 20th, 2025 at 11:53 AM, Rob Janssen > wrote: >> Modern Linux systems often have something like SELinux which limits where >> certain programs can open files. >> Just putting extra config files in "myfolder" isn't going to work, and the >> error messages can be misleading... >> >> Rob >> >> On 2025-04-20 14:58, Sviatoslav Feshchenko wrote: >>> Made a bit of progress with the issue. The server error log has the >>> following entry after startup: "Could not set credentials : Error while >>> reading file." >>> >>> This means it can't read the certificate files. >>> >>> Tried to change permissions using the following command: >>> *setfacl -R -m u:_chrony:rwx myfolder* >>> Wher* myfolder* is the directory where the certificates are located. >>> >>> Still not working, giving same error message. >>> >>> What would be the correct way of giving chrony permissions to read the >>> certificate files created by certbot, without breaking the web server? I am >>> running Debian 12. >>> >>> Many thanks! >>> >>> Sviatoslav >>> >>> On Saturday, April 19th, 2025 at 9:02 PM, Sviatoslav Feshchenko >>> wrote: Hello, I am trying to set up a NTS server suing Let's Encrypt certificate for a web server, but haven't been successful. Here are the steps I've taken: 1. Set up a web server on the same machine as chrony. 2. Set up Let's Encrypt certificates using the certbot tool and the web server is properly serving a test page via HTTPS. 3. In chrony.conf have the following directives relating to NTS: 1. ntsservercert - set to point to the certificate created by certbot for the web server 2. ntsserverkey - set to point to the key created by certbot for the web server 4. Chrony is working just fine in all other respects. 5. Firewall is configured to allow traffic on port 4460 and 123 and routes all such traffic to the chrony server. I have not taken any other steps other than what's described above. I am testing the NTS server by using a different machine in a different location on a different public IP that's running chrony and pointing to the server with nts directive. I will refer to this as the client machine. The client machine does not appear to authenticate the server properly for some reason. Running authdata command in chronyc shows "NTS" in mode column and a small number in column Atmp. All other columns are zero. On the server machine, running serverstats command in chronyc shows the same number as the client machine in column Atmp, in row "NTS-KE connections accepted. This suggests that the server is receiving an NTS request. Authenticated NTP packets is zero however, suggesting that authentication on the client side failed. Also, not sure if it matters, but my certificate points to a sub-domain, which is the same sub-domain as I am using as the server name on the client side. However, when I run "sources" command on the client machine, the server domain name resolves to something like "dsl-1-2-3-4-tor.pr where 1-2-3-4 is the actual server IP address. Not sure why it resolves like that, but I am guessing my DNS provider is somehow using the tor network? Could this be the culprit? Any suggestions on what may be wrong, or how to diagnose the problem? All your suggestions are always very much appreciated, thank you! Sviatoslav >>> >> >
Re: [chrony-users] Re: NTS Server Setup with Let's Encrypt
Thank you James and Rob. I think Rob is right. No matter what I did with permission, it just didn't work. As a workaround, I simply copied the certificates to a different directory and chrony now loads the certificates without issues, and I am now able to synchronize to the server using NTS! Copying the certificates may be an acceptable solution, because certbot offers pre and post validation hooks, which will execute a script before/after renewal. This script can copy the certificates after renewal and restart chrony, so it should be easy to automate this. Many many thanks! Sviatoslav On Sunday, April 20th, 2025 at 11:53 AM, Rob Janssen wrote: > Modern Linux systems often have something like SELinux which limits where > certain programs can open files. > Just putting extra config files in "myfolder" isn't going to work, and the > error messages can be misleading... > > Rob > > On 2025-04-20 14:58, Sviatoslav Feshchenko wrote: > >> Made a bit of progress with the issue. The server error log has the >> following entry after startup: "Could not set credentials : Error while >> reading file." >> >> This means it can't read the certificate files. >> >> Tried to change permissions using the following command: >> >> setfacl -R -m u:_chrony:rwx myfolder >> >> Wher myfolder is the directory where the certificates are located. >> >> Still not working, giving same error message. >> >> What would be the correct way of giving chrony permissions to read the >> certificate files created by certbot, without breaking the web server? I am >> running Debian 12. >> >> Many thanks! >> >> Sviatoslav >> >> On Saturday, April 19th, 2025 at 9:02 PM, Sviatoslav Feshchenko >> [](mailto:sviatoslav.feshche...@proton.me) >> wrote: >> >>> Hello, >>> >>> I am trying to set up a NTS server suing Let's Encrypt certificate for a >>> web server, but haven't been successful. Here are the steps I've taken: >>> >>> - Set up a web server on the same machine as chrony. >>> - Set up Let's Encrypt certificates using the certbot tool and the web >>> server is properly serving a test page via HTTPS. >>> - In chrony.conf have the following directives relating to NTS: >>> >>> - ntsservercert - set to point to the certificate created by certbot for >>> the web server >>> - ntsserverkey - set to point to the key created by certbot for the web >>> server >>> - Chrony is working just fine in all other respects. >>> - Firewall is configured to allow traffic on port 4460 and 123 and routes >>> all such traffic to the chrony server. >>> >>> I have not taken any other steps other than what's described above. >>> >>> I am testing the NTS server by using a different machine in a different >>> location on a different public IP that's running chrony and pointing to the >>> server with nts directive. I will refer to this as the client machine. >>> >>> The client machine does not appear to authenticate the server properly for >>> some reason. Running authdata command in chronyc shows "NTS" in mode column >>> and a small number in column Atmp. All other columns are zero. >>> >>> On the server machine, running serverstats command in chronyc shows the >>> same number as the client machine in column Atmp, in row "NTS-KE >>> connections accepted. This suggests that the server is receiving an NTS >>> request. Authenticated NTP packets is zero however, suggesting that >>> authentication on the client side failed. >>> >>> Also, not sure if it matters, but my certificate points to a sub-domain, >>> which is the same sub-domain as I am using as the server name on the client >>> side. However, when I run "sources" command on the client machine, the >>> server domain name resolves to something like "dsl-1-2-3-4-tor.pr where >>> 1-2-3-4 is the actual server IP address. Not sure why it resolves like >>> that, but I am guessing my DNS provider is somehow using the tor network? >>> Could this be the culprit? >>> >>> Any suggestions on what may be wrong, or how to diagnose the problem? >>> >>> All your suggestions are always very much appreciated, thank you! >>> >>> Sviatoslav
Re: [chrony-users] Re: NTS Server Setup with Let's Encrypt
Modern Linux systems often have something like SELinux which limits where certain programs can open files. Just putting extra config files in "myfolder" isn't going to work, and the error messages can be misleading... Rob On 2025-04-20 14:58, Sviatoslav Feshchenko wrote: > Made a bit of progress with the issue. The server error log has the following > entry after startup: "Could not set credentials : Error while reading file." > > This means it can't read the certificate files. > > Tried to change permissions using the following command: > |setfacl -R -m u:_chrony:rwx myfolder| > Wher|myfolder| is the directory where the certificates are located. > > Still not working, giving same error message. > > What would be the correct way of giving chrony permissions to read the > certificate files created by certbot, without breaking the web server? I am > running Debian 12. > > Many thanks! > > Sviatoslav > > On Saturday, April 19th, 2025 at 9:02 PM, Sviatoslav Feshchenko > wrote: >> Hello, >> >> I am trying to set up a NTS server suing Let's Encrypt certificate for a web >> server, but haven't been successful. Here are the steps I've taken: >> >> 1. Set up a web server on the same machine as chrony. >> 2. Set up Let's Encrypt certificates using the certbot tool and the web >> server is properly serving a test page via HTTPS. >> 3. In chrony.conf have the following directives relating to NTS: >> 1. ntsservercert - set to point to the certificate created by certbot >> for the web server >> 2. ntsserverkey - set to point to the key created by certbot for the >> web server >> 4. Chrony is working just fine in all other respects. >> 5. Firewall is configured to allow traffic on port 4460 and 123 and routes >> all such traffic to the chrony server. >> >> >> I have not taken any other steps other than what's described above. >> >> I am testing the NTS server by using a different machine in a different >> location on a different public IP that's running chrony and pointing to the >> server with nts directive. I will refer to this as the client machine. >> >> The client machine does not appear to authenticate the server properly for >> some reason. Running authdata command in chronyc shows "NTS" in mode column >> and a small number in column Atmp. All other columns are zero. >> >> On the server machine, running serverstats command in chronyc shows the same >> number as the client machine in column Atmp, in row "NTS-KE connections >> accepted. This suggests that the server is receiving an NTS request. >> Authenticated NTP packets is zero however, suggesting that authentication on >> the client side failed. >> >> Also, not sure if it matters, but my certificate points to a sub-domain, >> which is the same sub-domain as I am using as the server name on the client >> side. However, when I run "sources" command on the client machine, the >> server domain name resolves to something like "dsl-1-2-3-4-tor.pr where >> 1-2-3-4 is the actual server IP address. Not sure why it resolves like that, >> but I am guessing my DNS provider is somehow using the tor network? Could >> this be the culprit? >> >> Any suggestions on what may be wrong, or how to diagnose the problem? >> >> All your suggestions are always very much appreciated, thank you! >> >> Sviatoslav >
[chrony-users] Re: NTS Server Setup with Let's Encrypt
Made a bit of progress with the issue. The server error log has the following entry after startup: "Could not set credentials : Error while reading file." This means it can't read the certificate files. Tried to change permissions using the following command: setfacl -R -m u:_chrony:rwx myfolder Wher myfolder is the directory where the certificates are located. Still not working, giving same error message. What would be the correct way of giving chrony permissions to read the certificate files created by certbot, without breaking the web server? I am running Debian 12. Many thanks! Sviatoslav On Saturday, April 19th, 2025 at 9:02 PM, Sviatoslav Feshchenko wrote: > Hello, > > I am trying to set up a NTS server suing Let's Encrypt certificate for a web > server, but haven't been successful. Here are the steps I've taken: > > - Set up a web server on the same machine as chrony. > - Set up Let's Encrypt certificates using the certbot tool and the web server > is properly serving a test page via HTTPS. > - In chrony.conf have the following directives relating to NTS: > > - ntsservercert - set to point to the certificate created by certbot for the > web server > - ntsserverkey - set to point to the key created by certbot for the web server > - Chrony is working just fine in all other respects. > - Firewall is configured to allow traffic on port 4460 and 123 and routes all > such traffic to the chrony server. > > I have not taken any other steps other than what's described above. > > I am testing the NTS server by using a different machine in a different > location on a different public IP that's running chrony and pointing to the > server with nts directive. I will refer to this as the client machine. > > The client machine does not appear to authenticate the server properly for > some reason. Running authdata command in chronyc shows "NTS" in mode column > and a small number in column Atmp. All other columns are zero. > > On the server machine, running serverstats command in chronyc shows the same > number as the client machine in column Atmp, in row "NTS-KE connections > accepted. This suggests that the server is receiving an NTS request. > Authenticated NTP packets is zero however, suggesting that authentication on > the client side failed. > > Also, not sure if it matters, but my certificate points to a sub-domain, > which is the same sub-domain as I am using as the server name on the client > side. However, when I run "sources" command on the client machine, the server > domain name resolves to something like "dsl-1-2-3-4-tor.pr where 1-2-3-4 is > the actual server IP address. Not sure why it resolves like that, but I am > guessing my DNS provider is somehow using the tor network? Could this be the > culprit? > > Any suggestions on what may be wrong, or how to diagnose the problem? > > All your suggestions are always very much appreciated, thank you! > > Sviatoslav
