NTS Quick Start Guide

NTS is a method for using TLS/SSL to authenticate NTP traffic on the net. That means that bad guys can’t forge packets that will give your system bogus time.

It is specified in RFC 8915, published in September 2020.

Note: The NTP Pool does not currently support NTS.

It is strongly suggested that you get a "normal", unauthenticated, NTP server working before enabling NTS. This may reduce the time spent debugging. See the Client Quick Start Guide.

While NTPsec already supported NTS as RFC 8915 still was in the draft phase, there unfortunately were incompatible changes introduced shortly before it was published. As a result, while NTPsec-versions before 1.1.9 do in principle support NTS, they cannot talk to any NTS servers or clients that implement the final RFC, which includes NTPsec-versions from 1.1.9 onwards. And NTPsec 1.1.9 requires manually specifying the correct port number (4460), because it still defaulted to 123. 1.2.0 is the first version of NTPsec to fully support NTS as specified in RFC 8915.

Append the keyword nts to the end of your server lines. Do this only for servers that speak NTS. If the server uses a port other than 4460 for NTS key exchange, you also need to specify the port number. As of August 2022, the following should work:

A list of public NTS servers is availabe, with more info on NTS. Look here first.

Listed below are development machines, so there may be gaps in availability, and they may run unreleased versions of NTPsec:

Note that you must use the same host name that was used to create the server’s certificate. IP addresses will not work.

This assumes that the server is using a certificate covered by your OS/distro’s root certificate collection.

NetBSD needs the mozilla-rootcerts-openssl package and ca /etc/openssl/certs/ added to the server line.

Restart ntpd, and skip to Verification, below.

Being an NTS server requires a well-formed SSL certificate. The easiest way to do this is to use Let’s Encrypt. It needs a FQDN. Please see the certbot client site for instructions.

The following worked on Fedora:

If you already have an SSL certificate for your server, and you are serving time using the same FQDN, you can reuse that certificate.

Next, add the line: nts enable to your ntp.conf file.

Locate the following two files:

Then add the lines below to your ntp.conf, replacing with your pathnames.

Example, using Let’s Encrypt:

Note that ntpd must be able to read both files and you want to make sure that the bad guys can’t read your private key. It may be simpler to copy those files over to /etc/ntp/ and adjust their owner and mode so ntpd running as user ntp can read them.

You may need to tell your system where to store the keys used to encrypt cookies. The default is /var/lib/ntp/nts-keys. Some distros use /var/db/ rather than /var/lib/.

Again, make sure the bad guys can’t read that file.

Restart your server, and skip to Verification, below.

Check your log file. The current client side NTS implementation is quite chatty. The log lines may change, but what you see should be similar to below.

As a client, you should see lines like this:

For initializing a server, you should see lines like this:

On a server, each time a client uses TLS to setup cookies, you should see lines like these. If all goes well, there is a single line for each connection.

Servers on the big bad internet will get a lot of garbage connections. The common cases produce a single line. Less common cases will have additional lines with OpenSSL error data.

alert means the client on the other end encountered troubles and is reporting them back to the server.

The logging prefix NTSs is for the NTS server component. The NTSc component is for the NTS client part, where your ntpd is talking to other NTS servers.