[earakely-scale]

What changes

A computer reaches the run's websites by their names (site routing) with certificates from a CA made for the deploy. Those certificates were valid from real now − 5 min to the deploy's ttl + 1 day. Since #649, a computer's session reads the universe's time. So with the clock armed in the past, or more than a day ahead, Chrome refused every routed site with ERR_CERT_DATE_INVALID.

• The window: the deploy's CA and every site certificate are now valid over the widest window a certificate carries: from 1950-01-01, the earliest X.509's UTCTime holds (and the earliest cryptography signs), to 9999-12-31 23:59:59, RFC 5280's date for no expiry (UNIVERSE_FROM, UNIVERSE_UNTIL in sites.py). They hold at any date the gateway's clock takes, so nothing is re-issued when the clock is armed or moved. (The design said 1971–2099; review found the gateway's clock takes dates past 2099.)
• Why that's safe: the CA is name-constrained to the routed names, and its key is discarded once the certificates are signed. A wider window vouches for nothing more, and only this computer trusts the CA.
• The ttl is gone from site routing. It only set the old window, so sites.issue and sites.route no longer take it, and the deploy record no longer keeps sites.valid_for_s. An older record that has it still loads; the field is ignored.

Testing

Test	What it shows	Result
Unit	The CA and a leaf span 1950 to 9999-12-31 and verify at 1950, −6 years, now, +6 years, 2100-01-01 and 9999-12-31, and not a second before 1950. The site and computer env tests no longer pass a ttl.	288 pass
clock_desktop_test.py::test_a_fresh_chrome_loads_a_routed_site_six_years_either_side_of_now_and_past_2099 (new)	The clock desktop routes a stand-in site, shop.test. With its clock 6 years back, 6 years on and 80 years on, a fresh headless Chrome in the session loads https://shop.test/landed, making a TLS handshake of its own each time.	pass (x86_64 host)
The same test, with main's window put back (control)	Chrome refuses the site at both dates with net::ERR_CERT_DATE_INVALID, so the test catches the bug.	fails, as it should

curl and Python don't test the window: they use the system's OpenSSL, whose certificate checks the TLS shim (#639) keeps on real time. Chrome uses its own TLS and checks against the universe's time.

Docs

The site routing page should say that the deploy's CA and site certificates are valid from 1950 to the end of 9999, so they hold whatever the computer's clock shows.

🤖 Generated with Claude Code

Confidence Score: 5/5

The PR appears safe to merge; no new blocking issues were found.

Summary

The PR gives routed sites’ certificates a fixed lifetime and removes the routing lifetime tied to deployment expiry.

• Routed sites keep working when the computer clock moves far from today.
• Site routing records no longer carry a deploy TTL.

_{Reviews (5) · Last reviewed commit: "fix(computers): routed sites' certificat..." · Reviewed by Greptile}