Stig Nygaard - Nighttime

Setting up NTS-Secured NTP with NTPsec

This is a guest blogpost by Martin Langer, Ph.D. student for “Secured Time Synchronization Using Packet-Based Time Protocols” at Ostfalia University of Applied Sciences, Germany.

In the previous posts, I already introduced the Network Time Security (NTS) protocol and described the most important features. Although the specification process has not been completed, there are already some independent NTS implementations and public time servers (IETF106). NTPsec is one of the important representatives of this series and already offers an advanced NTS solution. In this post, I’ll give you a short guide to setting up an NTS-secured NTP client/server with NTPsec.


NTPsec  is a fork of the NTP reference implementation NTPD that has removed inherited burdens to provide a smaller codebase. In addition, the relevance of NTPsec in the Linux environment is increasing and it is one of the first NTS-capable NTP implementations.

Due to the missing Windows support, this guide is only intended for Linux systems. Therefore I’m using a Raspberry Pi 3B with the recent Debian-based operating system Raspbian. The procedure described here also works with other Linux distributions in the same or similar form.

Software Components Used

In order to use NTS, we need the following software components. You can find detailed instructions for installation and setup below:

Important: All NTS implementations that use OpenSSL with TLS 1.3 support require OpenSSL 1.1.1b or higher. OpenSSL 1.1.1a contained a bug  which caused the TLS key export to fail during the NTS Key Establishment (NTS-KE) phase.

NTS Properties of NTPsec

Currently (Q4/2019), NTPsec has implemented the NTS draft 17. The following adjustments of the specification up to the latest draft version 20 do not contain any significant changes so that NTPsec is representative. The following NTS features are included in the implementation:

  • TLS support for the NTS Key Establishment (NTS-KE) phase
  • Default NTS-KE port
    • 123 (TCP)
  • Default NTP port
    • 123 (UDP)
  • Error handling (server-side)
    • Discard request packets without response*

*The server only discards invalid request packets and does not send an NTSN (NTS NAK) back to the client. This is okay, but a client then doesn’t know whether a request has been lost or if an error occurred during verification.


Okay, now we can finally get started. First, we log into our Raspberry Pi (RPi) and make sure that we have an Internet connection. This device can be accessed directly with a connected screen and keyboard or headless via SSH. Then we update the system and the installed packages:

Next, we check the OpenSSL version, which must be 1.1.1b or higher:

To ensure the correct functioning of NTPsec, we should also disable the local time synchronization service. This also applies to other services (such as OpenNTPD, Chrony, …).

If an NTP service (e.g. NTPD) is used instead, we can remove it as follows:

This is necessary since NTPD and NTPsec use the same files and names for the application.

Installation of NTPsec

The installation of NTPsec can be done via the package manager as well as by manually building the source code.

Method 1: Using the Package Manager

The easiest way to install NTPsec is through the use of a package manager. For NTS support, we need the version 1.1.8 or higher. To check which package version is available, we use the command apt show:

If version 1.1.8 is available, we can simply install it as follows:

That’s it! You can skip the following steps and go directly to the configuration (see below).

Method 2: Build the Source Code Manually

The manual setup consists of building and installing NTPsec as well as its registering as a system service (systemd).

Part 1: Building and Installing

This installation guide is based on the NTPsec instructions and can be carried out without much effort. We begin with the installation of some basic tools and compilers. Then we create a temporary working directory in which we copy and build the NTPsec source code.

Next, there are two ways to build the code. Either we clone the current git repository (variant 1) or we download the recent NTPsec version (variant 2).

Variant 1: Using The Git Repository

Variant 2: Downloading Binaries

The following script now installs all tools or packages (bison, libssl-dev, libcap-dev, libseccomp-dev) that are needed for building. These can also be installed manually. But in our case we use the script:

Now we can make initial configurations. We can display the available options with ./waf configure --help. If no parameters are specified, the NTPsec installation is done in the /usr/local/ directory by default. The application (ntsd) is then located in /usr/local/sbin. With the parameter –prefix=<dest/path> we can change the path arbitrarily. If NTPsec is to be configured as a server, the parameter –refclock=all is necessary, since it allows the use of any local reference clock (GPS, PTP, SHM, etc.).

Finally, we build the source code and install the binaries:

Let’s check the NTPsec version number:

The output should look like ntpd ntpsec-1.1.8 2019-11-20T04:44:12Z and must be 1.1.8 or higher.

Part 2: Setting up the NTP Service (Systemd)

Perfect. Next, we set up NTPsec as a system service. For this, we create an ‘ntp’ user and an ‘ntp’ group with restricted rights. We also create folders for log files and certificates.

Now NTPsec is executed automatically when rebooting the system. At the moment the service is not running yet, because we have to configure it first.

Configuration of NTPsec

After the installation of NTPsec the configuration has to be created. The NTP service uses ntp.conf, which is located in the /etc/ directory by default. If this file is not yet available, it must be created:

The following examples are based on the NTPsec instructions (General, NTS-QuickStart) and differ between client and server.

Client Configuration

Let’s have a look to the client configuration. In this ntp.conf I have listed 4 examples for a possible client configuration. These can be changed or commented out if necessary:

In the first example, the Raspberry Pi synchronizes its clock with a public NTPsec time server using a classical unsecured NTP connection.

In the second example, the client communicates with the same time server via an NTS-secured NTP connection. The initial channel to the NTS-KE server uses the default port 123 TCP (currently implementation-specific). Since the NTPsec time server uses certificates issued by Let’s Encrypt, we do not need to set any additional parameters. To check the certificates, the client uses the local root CA pool (/etc/ssl/certs/ca-certificates.crt), which also allows the verification of certificates issued by Let’s Encrypt.

In the third example, we connect to the time server of the Ostfalia University, which is also NTS-capable. This uses TCP port 443 for the NTS-KE connection and uses self-signed test certificates. To check the server certificate we have to specify the root CA manually. The corresponding certificate can be downloaded by the following command:

Caution: The time server of the Ostfalia University also publishes its private key, as it is a public test server. This time server should not be used for clock synchronization of productive systems.

The fourth example differs from the third one only from the deactivated domain validation. This can be useful when we running a local NTS server with certificates without a registered domain.

The other entries in the configuration file are optional and are used to record statistics and log files. The descriptions as well as the complete parameter list (incl. NTS) can be found in ntp_conf.adoc. Here only very briefly described:

Server Configuration

The configuration of the server is a little easier:

In this example, we use the local clock as the reference time source, which we distribute to all connected clients. When activating NTS, we have to specify a server certificate and the private key. This may have been created manually or issued by an external CA instance (e.g. Let’s Encrypt again).

By the way, the client and server configurations can be combined to run both simultaneously. For example, a client could fetch the time NTS-secured from external time servers and distribute it as a server in the local network without NTS.

Debug and Advanced Information

Starting the Daemon:

Now we can start our NTPsec service:

After this, the service should run, which we can easily check:

The whole thing should look like this:

Manual Start of NTPsec:

Of course, you can also start NTPsec manually:

If you also want to see the log output live, then you need to specify some parameters:

For an NTS-secured NTP client (here from example 3 of the configuration) we see the following:

Everything works well. The certificate is valid and the client has received 8 cookies. The AEAD algorithm 15 (AEAD_AES_SIV_CMAC_256) is used to secure packets.

Peer Status:

To check the current status of the connection(s), we must enter the following command:

The NTS-Secured NTP Client:

As you can see, the synchronization works fine. No packet loss and a small time offset.

The NTS-Secured NTP Server:

The server side also works, but gives less information.

NTS Status:

The following command allows us to view the NTS statistics:

If we use both NTS client and NTS server at the same time, then we get these values:

Manipulated or invalid packets are detected and discarded. The number is listed accordingly (NTS server recvs w error).

Wireshark Examples and Pcap Files

At this point, I would like to show a few examples, how the whole thing looks like in Wireshark. Since NTS is not yet supported in Wireshark, there are still incorrect interpretations of the binary data. But that shouldn’t bother us at all.

Example 1: NTS with TLS 1.2 and 512-Bit AEAD Algorithm:

In this figure we see an NTS-secured NTP connection. This starts with the NTS-KE over TLS 1.2. Due to the strong AEAD algorithm and the resulting large cookies, the NTP packets have a size of 296 bytes (or 338 bytes including all headers). The yellow markings in Wireshark are due to misinterpretations of the content.

NTS with TLS 1.2 and 512 bit AEAD algorithm
Example 2: Possible NTS Behavior with Packet Loss or Manipulation:

Here we see the behavior of manipulated NTP packets. The server simply discards them. The client then sends another packet and wants an additional cookie because one is missing. Therefore, the size of the following request increases by the size of a cookie. This is repeated until the client has no cookies left and repeats the NTS-KE. This behavior also occurs if the client does not receive the response due to packet loss.

Possible NTS behavior with multiple packet loss
Exampe 3: NTPsec with Default Settings and NTS

Like example 1, but with TLS 1.3 and a 256 bit AEAD algorithm. The NTP messages are therefore smaller.

NTPsec with default settings and NTS
Example 4: Multiple Unsecured NTP and NTS-Secured NTP Connections

In this example, we see unsecured and NTS-secured NTP connections of the Ostfalia time server. The NTS connections use different configurations (AEAD algorithms), so that the packet sizes vary.

Multiple unsecured NTP and NTS-secured NTP connections

The current connections of the Ostfalia time server are recorded and can be freely downloaded. This allows better diagnosis and live tracking when testing with NTS. The current pcap files can be found here and here.  The pcap files of the Wireshark examples above are here.:

Thanks for reading ;)

Featured image “Nightlight” by Stig Nygaard is licensed under CC BY 2.0.

25 thoughts on “Setting up NTS-Secured NTP with NTPsec

    1. Hello Attilio,

      “does the DNS been checked from time to time?”

      ehm… no, not directly. Only during the TLS handshake, but not when the NTS-secured NTP phase is running. But this should not be a problem. If the address is no longer accessible, then the cookies also slowly decay and the client will attempt to re-establish a TLS connection after a few minutes to check the certificate and the associated DNS.

      by the way… your guide looks good :)

      Also some good news: NTS will be released very soon. Our tests on the last IETF Hackathon (July 2020) were successful and we have multiple working Implementations (NTPsec, Chrony, Cloudflare and more) and public time servers:

      here are the results:

      public NTS time server (stratum 1, using NTPsec): (; certificates:

      best regards,

        1. We have the need to change our old Symmetricom appliances (2 S100 TCXO and 2 S200 Rb) where I work.

          Requirments are GPS/GLONASS/Galileo + Rubidium option + 10Gb possibly, and of course NTS.

          I am not able to find any appliance which is NTS ready, and of course I cannot propose a raspberry lol. We need professional hardware and support and shit.

          Do you have any recommendation or hint?

          Thanks :)

          1. yeah… it not so easy right now. NTS is an RFC for almost 2 months and many producer need time to develop the standard and upgrade their firmware. Furthermore, the hardware must be able to provide the additional performance, since many appliances need to serve the full network bandwidth.

            I have a loose cooperation with Meinberg and I know that you are very interested in equipping your devices with it. I think they will roll out new firmware or provide new devices as soon as possible.

            I will ask tomorrow, maybe I will get an info about it. I will report again in 1-3 days ;)

            1. that would be great, at least to have some info, like the already available devices that will be capable of NTS just by firmware update :)

              thank you so much!

              1. Hey Attilio,

                unfortunately I have not received any further feedback so far. I’ll try again and probably get back to you tomorrow ;)

  1. Pingback: NTS – Blog
  2. I’ve a problem in connecting with the NTS-KE server of PTB @, particularly with the CE certificate chain dfn-ca-global-g2 you linked above (I’m running NTPsec on Debian 10); what to put into ntpsec.conf and how/where to import the certificates to? – Thanks for your help!

    1. hey :)

      you can put the certificates in ‘etc/ssl’ or ‘etc/ssl/certs’. Also see the examples above (for custom directories):

      # Example 1: unsecured NTP
      server iburst minpoll 3 maxpoll 6

      # Example 2: NTS-secured NTP (default NTS-KE port (123); using certificate pool of the operating system)
      server iburst minpoll 3 maxpoll 6 nts

      # Example 3: NTS-secured NTP (custom certificate and NTS-KE port)
      server iburst minpoll 3 maxpoll 6 nts ca /var/lib/ntp/certs/rootCaBundle.pem (–> is the dfn-ca-global-g2 cert)

      # Example 4: NTS-secured NTP (skip DNS check)
      server iburst minpoll 3 maxpoll 6 nts ca /var/lib/ntp/certs/rootCaBundle.pem noval

      short question… where are you from? I know about problems in London and Canada (due to filtering of NTS packets). Do you get error messages?

      best regards,

      1. Perfect, that did the trick, thank you for your help, Martin!
        And I’m from Germany, no NTS filtering by my provider here…

  3. Hi Martin,

    Is there a list being maintained somewhere which NTP servers are NTS-capable?

    Best regards,

    1. hey Marco,
      good question..

      I don’t think there is a public list. Maybe this helps: (

      the standardized NTS port is now 4460/tcp. So maybe the ports above are now 4460. is now the official NTS-secured time server of germany and central europe.

      have a nice day (⊙ヮ⊙)

          1. Hi Martin, I noticed several servers time out or refuse connection, and I also noticed you provided a public certificate. I wonder whether these two are related: is chrony unable to connect because I don’t have the proper certificate? My knowledge is limited on this subject, so I wonder if you could help me out. Tried to find my way throught the manpages, but I don’t get it. Chrone is running on my (Asuswrt-Merlin) router and I did see there has been directory created for keys. But how to proceed? Can you help me out? Thanks in advance.
            Best regards,
            The Netherlands

            1. Hey Marco,

              this is not difficult ;)
              The certificate is no longer necessary. For the individual servers, it may be that they are no longer connected to the network. I have tested this list a few months ago. The time servers of PTP and Cloudflare should be available.

              You only have to do the following:
              1. open the configuration file. For a NTPsec client it is “/etc/ntp.conf” and for a Chrony client it is “/etc/chrony.conf”.

              2. Then enter the following:
              server nts
              server nts

              soon available:
              server nts
              server nts

              also available:
              server nts

              see if it works :)
              many greetings,

              1. Oh, thanks for your guidance, but that was already clear, I have chrony-nts up and running and it performs great. I was just wondering why several servers keep timing out (see below) and others keep refusing connection, and wondered whether that had something to with the certificate you posted earlier. It works like a charm, it’s just that the list of servers is still somewhat limited.

      1. oh… for germany the new server is: and it uses Lets Encrypt vertificates ;) and should be online in 1-2 weeks. is also fine ;)


        1. and are apparently online as of this weekend. However, ptbnts[1|2|3] are constantly timing out. Any idea why they can’t be reached?

          1. Martin,

            I have already found my answer by the reply of the ntp-admin @ PTB:

            “The servers ptbnts1/2/ were announced as test servers on It wasn’t clear from the beginning whether they would turn productive or stay in test status but it was decided to extend the official timeservers ptbtime1/2/ So with our atomic clocks as primary source they disseminate the official time information for Germany, in the past via NTP and now via NTP and NTS.”

            In short: the ptbntns server are taken offline, the ptbtime servers are now the main servers for Germany and Europe.

            Best regards,

            1. sorry for the late reply, I was very busy. You are right… it is currently also difficult to find out which time servers are already NTS capable. 「(⌒_⌒;)

Leave a Reply

Your email address will not be published. Required fields are marked *