Re: [chrony-users] Re: NTS Server Setup with Let's Encrypt

[kross@xxxxxxxxxxxxxxxxxxxx]

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 kross@xxxxxxxxxxxxxxxxxxxx:

> 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 <gerd@xxxxxxxxxx>:
> 
>> 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 kross@xxxxxxxxxxxxxxxxxxxx:
>>> 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 kross@xxxxxxxxxxxxxxxxxxxx:
>>> 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 <gerd@xxxxxxxxxx>:
>>>> 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 kross@xxxxxxxxxxxxxxxxxxxx:
>>>> Why just do that in the renewal-hook/post script ?
>>> Not sure I fully grasp your drift, so apologies if the following is
>>> old news.
>>> The point of the certbot renewal hook is automation of deployment.
>>> Nothing wrong with manually keeping track of the validity of existing
>>> certificates, e.g., periodically checking, setting a reminder
>>> somewhere, having a tool that checks and alerts, or waiting until
>>> someone or something alerts upon finding an expired certificate (as
>>> you will have seen, Let's encrypt will cease sending reminders in the
>>> near future). And then deploying manually (assuming certbot did an
>>> automated renewal, or maybe do that manually as well).
>>> But once the number of certificates to keep track of reaches a certain
>>> level, or the thrill of learning the ropes, i.e., setting this up in
>>> the first place, and going through the motions of deploying manually
>>> after (manual or automated) renewal, diminishes after a few
>>> iterations, automated deployment (after automated renewal) is your
>>> friend.
>>> As always, YMMV.
>>> Kind regards,
>>> Joachim
>>> 22.04.2025 22:50:06 Sviatoslav Feshchenko
>>> <sviatoslav.feshchenko@xxxxxxxxx>:
>>> This seem like a simpler solution! Thank you for sharing!
>>>> Sviatoslav
>>>> On Tuesday, April 22nd, 2025 at 3:32 AM, Gerd Hoerst
>>>> <gerd@xxxxxxxxxx> 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 kross@xxxxxxxxxxxxxxxxxxxx:
>>>> …
>  

--
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.