Chrony time sync for cryptographic correctness

Bad time breaks crypto before it breaks anything obvious.

That is the part people miss. They treat NTP as background ops hygiene, then spend an afternoon debugging TLS failures, strange login issues, or tunnel handshakes that fail only after reboot. Meanwhile the real problem is that the machine thinks it is living three hours in the past.

The chrony FAQ is direct about what accurate time matters for: DNSSEC, Kerberos, TLS, and WireGuard all care. So time sync is not "nice to have." It is part of your cryptographic control plane.

This is why "the service starts eventually" is not the standard you want. A host can be alive, reachable, and still wrong enough to make every higher-level security control look flaky.

The four directives that do most of the work

Chrony has plenty of knobs. Most public servers need only a handful.

This is the minimal client configuration I actually recommend:

pool pool.ntp.org iburst maxsources 4
driftfile /var/lib/chrony/drift
makestep 1.0 3
rtcsync

Why these four pieces?

iburst

The FAQ recommends iburst because it speeds initial synchronization. That matters most at boot, which is exactly when cryptographic weirdness is most likely if the clock is badly wrong.

driftfile

driftfile lets chrony remember how the local clock tends to wander. That is boring and essential. Clocks drift. Pretending they do not is not hardening.

makestep

The FAQ explains why makestep exists: if the clock is significantly wrong at startup, slewing gradually is too slow. You need to step it.

That is why makestep 1.0 3 is such a good default. Early boot is exactly when you want aggressive correction.

rtcsync

rtcsync periodically copies the corrected system time back to the RTC. That means the next boot starts less wrong than the last one. Again: boring, useful, cumulative.

Put differently: these directives are not clever. They are what keeps boot-time clock nonsense from leaking upward into every protocol that assumes time is real.

One source is enough to set the clock, not enough to trust it

Chrony's FAQ recommends three or four sources for a reason. One time source can tell you what time it thinks it is. Multiple sources let chrony decide whether one of them is being silly.

This is the same lesson as every other reliability domain: a single answer is not the same as a trustworthy answer.

So if your config still points at one lonely server because it "worked fine," you are optimizing for short files over correctness.

That does not mean every small VPS needs a hand-curated masterpiece of time infrastructure. It means the default should include enough diversity to catch nonsense before the rest of your stack depends on it.

For most ordinary servers, this is exactly the right level of ambition: a few good sources, fast initial sync, and verification that the host is actually converging instead of merely running a daemon named chronyd.

NTS is better, but not magic

If you want authenticated time, chrony supports Network Time Security directly. The config reference documents the nts option on a server line:

server ntp1.example.net iburst nts
server ntp2.example.net iburst nts
driftfile /var/lib/chrony/drift
makestep 1.0 3
rtcsync

That is the good news.

The catch is also documented clearly. The chrony FAQ warns that NTS has a chicken-and-egg problem: if the client clock is badly wrong, TLS certificate validation for the NTS key-exchange can fail before time is corrected.

That is not a chrony flaw. That is how certificate validity works.

RFC 8915 requires TLS 1.3 for NTS-KE, and it discusses the certificate-validity problem directly. RFC 5280 is even blunter: certificate validation requires that the certificate validity period include the current time.

So the right mental model is:

• NTS is better than unauthenticated time
• NTS still depends on the clock not being absurdly wrong
• startup correction still matters

If you use NTS, the same chrony reference documents supporting details like ntstrustedcerts and ntsdumpdir, which make certificate trust and cookie reuse operational instead of magical.

This is the point where a lot of "secure time" blog posts turn mystical. They should not. NTS improves the trust story. It does not repeal the physics of a bad RTC and a rebooted host.

Verification, not faith

Do not settle for "the service is active."

Use chronyc to ask whether the host is actually trustworthy:

chronyc tracking
chronyc sources -v
systemctl status chronyd
timedatectl

The chronyc docs are worth reading here. tracking tells you the current system-time offset and root dispersion. That is much more useful than a vague idea that the daemon is "synced."

This is also where you catch the dangerous half-working state: the service is running, one source exists, but the host is still drifting enough to make certificate validation or tunnel setup flaky.

If you are troubleshooting boot-time certificate failures, check time first. It is astonishing how often that advice sounds too simple and still turns out to be right.

On Ubuntu or Debian-family systems, the practical rollout is boring:

sudo apt update
sudo apt install chrony
sudo systemctl enable --now chrony

Then replace the default config with a small explicit one, restart the service, and verify with chronyc tracking instead of assuming install success means time correctness.

That last step is the whole discipline in miniature: install, configure, verify. Not install, assume, and later blame TLS.

That mindset alone prevents a surprising amount of wasted debugging.

Why this belongs in a hardening guide

Because crypto fails weirdly when time is wrong.

• TLS certs look expired or not yet valid
• NTS cannot complete certificate validation
• Kerberos gets angry
• DNSSEC validation becomes nonsense
• operator confidence collapses because the error messages are rarely honest

This is the same class of issue as /blog/linux-sysctl-network-hardening: small, boring infrastructure settings that quietly decide whether the rest of the security stack behaves like engineering or superstition.

My opinion is simple:

A public server without working chrony is not mostly fine. It is one reboot away from mysterious cryptographic breakage.

Install it, keep the config small, use multiple sources, step early, sync back to RTC, and verify with chronyc instead of trusting ceremony.