Time Synchronization and Certificate Dependencies

Accurate time is a dependency almost nothing declares but nearly everything uses. When a server's clock drifts by a few minutes, users cannot log in through Kerberos, API requests are rejected for invalid signatures, MFA codes fail, JWTs look expired or not yet valid, TLS connections report "certificate not yet valid", logs from different machines no longer line up during an incident, and scheduled jobs run at the wrong time. Certificates add a second hidden dependency: expiry dates that arrive whether or not anyone is watching, and validity periods that are getting shorter every year.

This page covers how to run time synchronization properly, how to recognize skew-related failures quickly, and how to keep certificates from expiring unnoticed.

TL;DR

Quick Example

A chrony configuration with authenticated and pooled sources:

Checking the state of a host:

Alerting on skew and expiring certificates with Prometheus (node_exporter and blackbox_exporter metrics):

Core Concepts

Time Sources

Time daemons such as chrony handle intermittent connectivity and VM pauses better than older implementations; systemd-timesyncd is a simpler client for workstations. Clocks are corrected by slewing (adjusting speed gradually) or stepping (jumping); stepping a running system can confuse applications, so allow it mainly at boot.

Windows and Active Directory

In an Active Directory forest, domain members sync from domain controllers, which sync up the hierarchy to the PDC emulator of the forest root domain, which should sync from reliable external sources. A misconfigured PDC emulator spreads bad time to every machine. See Active Directory and Group Policy.

Virtual Machines, Containers, and Leap Seconds

VMs drift when paused, migrated, or restored from snapshots; run a time daemon inside each VM (or use the hypervisor's supported mechanism) and watch for large steps after restores. Containers share the host kernel's clock, so fixing time means fixing the host. Leap seconds have historically been handled by stepping or by smearing the extra second over hours; mixing smeared and non-smeared sources creates temporary skew.

Failures Caused by Clock Skew

When many unrelated authentication errors appear on one host, check its clock first. See Time, Clocks, and Distributed Ordering.

Certificate Dependencies

Chains and Trust

A certificate is valid only if the client can build a chain to a trusted root, every certificate is within its validity period, names match, and the certificate is not revoked. Servers must send intermediates; old devices may lack newer roots; and root store changes can break clients that are rarely updated. See HTTPS and TLS.

Shrinking Lifetimes

The CA/Browser Forum has voted to reduce the maximum lifetime of publicly trusted TLS certificates in stages: from 398 days to 200 days in March 2026, 100 days in March 2027, and 47 days in March 2029, with shorter domain-validation reuse periods as well. Manual renewal processes that were tolerable once a year become untenable — automation is no longer optional.

Renewal Automation

Monitoring Expiry

Probe endpoints and alert well before expiry (for example 14–30 days), monitor renewal job failures, and include internal endpoints and client certificates, which most often expire unnoticed.

Best Practices

Treat Time as Infrastructure

Document time sources, monitor them like any critical dependency, and include clock checks in host health checks and incident runbooks.

Use Multiple, Trustworthy Sources

Configure at least three or four sources so one bad server can be outvoted, and prefer authenticated NTS where supported.

Allow Small Leeway, Not Large Tolerances

Give token validation a few seconds to a minute of leeway, but fix skew rather than widening tolerances to hide it.

Automate Every Certificate

Assume certificates will soon live weeks, not years, and automate issuance, deployment, and reloads everywhere.

Common Mistakes

No Time Daemon on VMs or Appliances

Widening Token Leeway to Hide Skew

Untracked Internal Certificates

FAQ

What is the best way to synchronize time on Linux servers?

Run chrony with several reliable sources — your cloud provider's time service or internal NTP servers, ideally with NTS authentication — and monitor offset and synchronization status.

How much clock skew is acceptable?

For most systems, offsets well under a second are normal and fine. Kerberos fails beyond five minutes by default, cloud request signing around fifteen minutes, and MFA codes within tens of seconds, but you should alert long before those limits.

Why does a wrong clock cause certificate errors?

Certificate validation checks the current time against each certificate's validity period. A client clock set in the past sees certificates as not yet valid; one set in the future sees them as expired.

What is NTS?

Network Time Security, a standard that adds cryptographic authentication to NTP so clients can verify that time responses come from the expected server and were not tampered with.

How short will TLS certificate lifetimes become?

Under the CA/Browser Forum's schedule, the maximum lifetime for publicly trusted TLS certificates drops to 200 days in 2026, 100 days in 2027, and 47 days in 2029, which makes automated renewal essential.

Related Topics

References