A server showing the right time has not necessarily received that time securely. Equally, a successful authentication exchange with a time service does not establish that the service’s measurements are actually being used to control the clock. Authentication status and source selection are separate things to inspect. Cloudflare Docs Treating them as one green “synchronized” indicator leaves an avoidable monitoring gap.
Network Time Protocol, or NTP, provides time synchronization. Network Time Security, or NTS, adds cryptographic protection to NTP’s client-server exchanges. Cloudflare Docs For infrastructure teams, secure server time synchronization therefore requires more than enabling an option: the operating policy must connect authenticated sources, usable measurements, and an understood response when either becomes unavailable.
Include management systems in the inventory as well as application hosts. HW Server’s BMC server-security coverage provides related context for reviewing that privileged infrastructure separately. Record devices that need a different authenticated-time arrangement rather than assuming that every platform supports the same client configuration.
Understand what NTS actually proves
The IETF’s NTS specification defines protections for identifying the communicating party, detecting changes to time-synchronization packets, and preventing replay of previous responses. Basic timing information remains visible; NTS is not intended to make the current time secret. RFC Editor Its value is establishing the origin and integrity of the exchange, not concealing a timestamp.
The protocol has two stages. First, the client uses Transport Layer Security, or TLS, to establish the keys needed for authentication. That connection then closes. Subsequent NTP packets use the established keys rather than travelling through a permanently open TLS connection. Cloudflare Docs This distinction matters when troubleshooting: successful key establishment and successful delivery of usable timing measurements are different milestones.
Authentication also does not independently prove that the supplying clock is correct. A verified source can still be misconfigured or otherwise supply poor time. The practical implication is to retain accuracy monitoring and source comparisons rather than treating authentication as a replacement for them.
An internal relay does not automatically extend upstream protection to every downstream machine, either. Red Hat documents client and server NTS configuration separately and recommends authenticated upstream synchronization for a time server that depends on other servers. Red Hat Documentation Map the complete chain—from upstream service to internal relay to client—and identify the protection applied to each exchange.
Check both network stages
Firewall reviews should distinguish key establishment from time-packet delivery.
NTS key establishment normally uses TCP port 4460. The protected NTP exchange uses the server and port communicated during that stage. Netnod’s client guide, for example, specifies port 4123 for its protected NTP traffic. RFC Editor The lesson is not to copy that port into every installation, but to verify the chosen service’s actual requirements.
Consider a hypothetical client that can complete key establishment but cannot reach the advertised NTP endpoint. Its authentication setup may succeed while timing measurements never arrive. The opposite troubleshooting mistake is to prove that ordinary NTP traffic passes and assume that authenticated key establishment must therefore work.
Build separate checks for those stages. Confirm the configured service identity, the negotiated timing destination, and the permitted traffic between the relevant network segments. Keep access limited to the intended service rather than opening broad rules merely to make a test pass.
A warm, already-running client is not a complete startup test. Depending on configuration, chrony can retain NTS state across restarts and avoid a new key-establishment exchange. Include a controlled fresh-start test in the deployment plan so that cached state does not conceal a missing dependency.
Read clock status alongside authentication
On Linux hosts running chrony, use its monitoring reports together. The chrony command reference describes separate views for clock performance, source selection, and authentication; none should be treated as a complete health check on its own.
Start with chronyc tracking. Review the estimated offset, reference update time, and synchronization state. These describe the clock’s operation, not proof that every contributing source is authenticated. Red Hat Documentation Record them as the timing side of the assessment.
Then inspect chronyc sources -v. The * state identifies the best selected source, while + identifies additional sources combined with it. A reachability value of 377 records valid responses for the last eight polls; it is not an authentication badge or a guarantee that every sample was suitable for synchronization. Check which sources contribute, not merely which ones respond.
Finally, inspect chronyc authdata. Its mode identifies NTS, symmetric-key authentication, or disabled authentication. For NTS, chrony’s troubleshooting guidance also checks that the key-establishment fields contain nonzero values. An NTS label alone should not end the investigation.
Match the selected and contributing sources to their authentication records. That comparison answers a more useful question than “Is an NTS server configured?” It shows whether the sources influencing the clock match the intended security policy.
For example, an authenticated source can be available while another source contributes to synchronization under a mixed-source policy. That is not automatically a malfunction. It is a reason to inspect the policy before describing the installation as NTS-only.
Decide what happens when trusted sources disappear
Source-selection defaults deserve explicit review.
In the chrony 4.9 documentation, the default authentication-selection mode is mix. When authenticated and unauthenticated sources are configured together, this mode applies additional selection rules requiring agreement with the authenticated sources and reference clocks. The documented require mode instead prevents unauthenticated NTP sources from being selected. Chrony Those are materially different policies.
The chrony source-selection rules also distinguish authentication from the trust selection option. The latter affects how sources are judged; it is not a substitute for cryptographic authentication. Review the effective configuration against the installed software version rather than assuming that a reassuring option name proves the intended protection.
Include automatically supplied sources in that review. Red Hat’s NTS client guidance specifically addresses disabling time sources supplied through the Dynamic Host Configuration Protocol, or DHCP. Red Hat Documentation A carefully reviewed server entry is only part of the configuration when another mechanism can supply additional entries.
The operational decision should be written down: when fresh authenticated measurements are unavailable, should the host continue using its existing clock estimate, raise an alarm, restrict particular workloads, or use a separately approved fallback? Define the acceptable timing uncertainty and escalation path for the applications involved.
Plan for a machine that starts with the wrong date
NTS introduces a startup dependency worth testing before rollout: certificate validation needs a sufficiently plausible date, while the machine may be trying to obtain trustworthy time precisely because its clock is wrong.
Chrony’s troubleshooting guidance identifies an incorrect client clock as a possible cause of certificate-validation failure. It discusses maintaining a battery-backed real-time clock, restoring previously recorded time, and other recovery approaches, while warning that disabling certificate time checks has security implications. Chrony Treat this as a recovery-design problem, not a reason to leave validation weakened indefinitely.
For a new deployment, document how an authorized administrator or provisioning system establishes an approximately correct initial date. Test the procedure after a long shutdown or restoration of an old system image. The acceptance condition should be successful authenticated synchronization without a permanent certificate-check exception.
Check operating-system security requirements before adopting a configuration example. Red Hat’s RHEL 10 documentation flags NTS incompatibility with certain hardened security profiles. Red Hat Documentation Verify the supported arrangement for the exact release and policy in use; do not quietly disable required protections to make a tutorial work.
Keep accuracy limits and recovery tests visible
NTS cannot eliminate every network-induced timing error. The specification explicitly discusses asymmetric delay: when packets take longer in one direction than the other, an NTP offset estimate can be biased even though the packet contents remain authentic. RFC Editor Authentication protects the message, not the speed at which the network delivers it.
A hypothetical calculation illustrates the distinction. Assume the path would otherwise be symmetric, but a single exchange receives an additional 40 milliseconds of delay in only one direction. Under NTP’s offset calculation, that asymmetry introduces a 20-millisecond bias into that exchange’s offset estimate. This is an illustration, not a prediction of the final system-clock error: filtering and source selection can reject or reduce the influence of a poor measurement.
The specification notes that multiple sources or network paths can help against delay attacks when an adversary controls only some paths. RFC Editor For planning purposes, ask whether apparently separate sources genuinely provide different dependencies, rather than counting hostnames alone.
Before declaring the deployment complete, run an authorized pilot that exercises startup, source loss, and recovery. Test key establishment and timing-packet delivery separately. Observe which sources are selected, whether authentication remains consistent with policy, which alarms fire, and how fresh measurements resume after connectivity returns.
Do not introduce clock jumps or disruptive network changes into production simply to demonstrate the concept. Agree on the test environment and application limits first.
The useful handover is a record of the chosen sources, their authentication state, the permitted fallback behavior, and the results of those controlled tests. A screenshot of the correct time cannot establish any of those things.
