A browser refuses the management GUI's freshly issued certificate as not yet valid or expired, and the backup application's schedules fire at the wrong wall-clock times on the same appliance. What single root cause links these symptoms?

Wall-clock correctness is a dependency, not a nicety. A certificate the appliance generates for itself takes its notBefore and notAfter dates from the appliance's own clock, so a clock running ahead produces a certificate the browser - checking against its own correct time - rejects as not yet valid, and a clock lagging far behind can produce one that is already expired; the same clock drives schedule evaluation, so a backup window defined in local time fires at the wrong real-world hour. One root cause explains both symptoms, which is why time synchronization is core management configuration alongside address and DNS rather than an after-go-live improvement. An internal CA lacking its chain in the trust store is a plausible trap but produces a different complaint — untrusted issuer rather than validity dates — and would leave schedules firing on time; trust failures and window failures read differently in any browser. Reissuing certificates on a cycle to track clock drift fails by mechanism: a certificate regenerated on the same appliance inherits the same wrong clock and fails identically the day it is installed. A timezone mismatch shifts displayed hours by the regional offset — it cannot produce the large error that stamps a certificate with a validity window the browser's clock falls outside of. Exam caveat: fix the clock first and retest; most certificate tickets on newly commissioned systems close with zero certificate work. Operational check: compare the appliance clock to a reference, confirm time sync status, then retry the GUI session and inspect the next fire time of a known schedule.