> 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 <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 <chrony-us...@pe1chl.nl> > 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 >>> <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: >>>> >>>> 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 >>> >> >
