Chrony fails to sync with NTS enabled

Question

I have configured Chrony server and client on two Centos 9 Stream machines. Without NTS everything is fine and the time is being synced. However, when I enable NTS, and configure the server to use certificate, the sync is failing. Any idea what the issue might be? Below is the server and client config:

Server:

[root@server1 ~]# cat /etc/chrony.conf
pool 2.centos.pool.ntp.org iburst
sourcedir /run/chrony-dhcp
driftfile /var/lib/chrony/drift
makestep 1.0 3
rtcsync
allow 192.168.11.0/24
keyfile /etc/chrony.keys
ntsdumpdir /var/lib/chrony
leapsectz right/UTC
logdir /var/log/chrony

ntsserverkey /etc/certs/chrony.key
ntsservercert /etc/certs/chrony.crt

[root@server1 ~]# cat /etc/chrony.keys
1 MD5 AVeryLongAndRandomPassword

Client:

[root@client1 ~]# cat /etc/chrony.conf
sourcedir /run/chrony-dhcp
driftfile /var/lib/chrony/drift
makestep 1.0 3
rtcsync
keyfile /etc/chrony.keys
ntsdumpdir /var/lib/chrony
leapsectz right/UTC
logdir /var/log/chrony
server server1 iburst nts

[root@client1 ~]# cat /etc/chrony.keys
1 MD5 AVeryLongAndRandomPassword

Sync test:

[root@client1 ~]# chronyd -Q -t 3 'server server1 iburst nts maxsamples 1'
2022-08-06T23:23:52Z chronyd version 4.2 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +NTS +SECHASH +IPV6 +DEBUG)
2022-08-06T23:23:52Z Disabled control of system clock
2022-08-06T23:23:52Z TLS handshake with 192.168.11.29:4460 (server1) failed : The TLS connection was non-properly terminated.
2022-08-06T23:23:55Z chronyd exiting

When checking the capture, it seems that the server terminates the connection after receiving the client hello:

Answer 1

Is the certificate used by your NTS server trusted by your client? I tried to reproduce your configuration and I was able to get things working.

Server setup

I started by generating a self-signed certificate for use by the server:

server# cd /etc/chrony
server# openssl req -x509 -nodes -newkey rsa:4096 \
  -keyout chrony.key -out chrony.crt \
  -sha256 -days 365 -subj /CN=server1

I configured the server like this:

pool 2.centos.pool.ntp.org iburst
sourcedir /run/chrony-dhcp
driftfile /var/lib/chrony/drift
makestep 1.0 3
rtcsync
allow 192.168.11.0/24
keyfile /etc/chrony.keys
ntsdumpdir /var/lib/chrony
leapsectz right/UTC
logdir /var/log/chrony

ntsserverkey /etc/certs/chrony.key
ntsservercert /etc/certs/chrony.crt

I started the server in debug mode to test it out and saw an error ("Could not set credentials").

server# chronyd -d
2022-08-08T00:54:52Z chronyd version 4.2 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +NTS +SECHASH +IPV6 +DEBUG)
2022-08-08T00:54:52Z Frequency 0.765 +/- 3.876 ppm read from /var/lib/chrony/drift
2022-08-08T00:54:52Z Could not set credentials : Error while reading file.
2022-08-08T00:54:52Z Using right/UTC timezone to obtain leap second data

The error was caused by the permissions on /etc/certs/chrony.key, which was owned by root and mode 0600. I made it owned by the chrony user:

server# chown chrony /etc/certs/*

Now when I start chronyd -d on the server it runs without errors.

Client setup

On the client, I used your config file:

sourcedir /run/chrony-dhcp
driftfile /var/lib/chrony/drift
makestep 1.0 3
rtcsync
keyfile /etc/chrony.keys
ntsdumpdir /var/lib/chrony
leapsectz right/UTC
logdir /var/log/chrony
server server1 iburst nts

When I first tried start chronyd -d, I saw the following error:

2022-08-08T01:01:06Z TLS handshake with 192.168.122.17:4460 (server1)
failed : Error in the certificate verification. The certificate is NOT
trusted. The certificate issuer is unknown.

That's expected, since I'm using a self-signed certificate. To fix that, we can install the certificate as a trusted certificate. On my system (Fedora, which should match your CentOS system), that means installing it into /etc/pki/ca-trust/source/anchors and then running update-ca-trust:

client# cat > /etc/pki/ca-trust/source/anchors/server1.crt
<paste certificate here>
^D
client# update-ca-trust

Now when I run chronyd -d I don't see any errors. Additionally, the client successfully connects to the server:

2022-08-08T01:03:36Z Selected source 192.168.122.17 (server1)

And running chronyc -N authdata shows:

client# chronyc -N authdata
Name/IP address             Mode KeyID Type KLen Last Atmp  NAK Cook CLen
=========================================================================
server1                      NTS     1   15  256   45    0    0    8  100