Skip to content

feat(init): keep the node clock in sync (NTP client with network.ntp_servers) #249

Closed
1 of 1 issue completed

Description

@Bugs5382

What and why

A CryptOS node has no time synchronisation. Nothing in init, the rootfs or the machine config runs NTP or SNTP, so the clock is whatever the hypervisor RTC gives it at boot, and then it drifts.

For a CA the clock is security-relevant:

  • notBefore and notAfter on every issued certificate
  • CRL thisUpdate and nextUpdate
  • OCSP producedAt, thisUpdate and nextUpdate
  • mTLS and ACME validity checks
  • audit log timestamps

A fast clock produces certificates and CRLs that relying parties reject as not yet valid. A slow clock produces OCSP and CRL responses that look stale. Kerberos PKINIT allows only 5 minutes of skew.

Expected

  • A minimal SNTP client in init (a hard dependency is not acceptable), or a well-reviewed small NTP library.
  • network.ntp_servers: IPv4 literals or hostnames (now that the node has a resolver, fix(revocation): node has no DNS resolver, so a hostname revocation_base_url blocks all issuance #233), carried through the proto like nameservers. Fall back to DHCP option 42 from /proc/net/pnp if the kernel exposes it; check whether it does.
  • Step the clock once at boot, before listeners and signing start, if the offset is large. Slew or re-sync periodically after that.
  • Refuse to step backwards across already-issued notBefore times without logging loudly.
  • Report the sync state (source, offset, last sync) in GetStatus / cryptosctl status, like the Revocation and DNS lines.
  • Decide whether signing should be blocked when the clock has never synced (fail closed, with an override), or only warn.

Refs #233

Metadata

Metadata

Assignees

Labels

enhancementNew feature (feat). Minor version bump.

Projects

No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions