How are you going to validate an X.509 certificate if you don't know the time?

ChromeOS has a quite interesting design to do this: https://www.chromium.org/chromium-os/chromiumos-design-docs/...

Essentially: keep some minimum values for time. Then do a single HTTPS request, ignore the validation of the certificate's date to start with, but use the Date header to later validate it against minimum / maximum. This has the advantage it's still a HTTPS request, so can't be MiTM'd and depending on implementation it can validate the time quite well (even if the device has run out of power it can have saved a recent timestamp on disk, so with regular use of the device an old certificate won't be valid, keeping the main useful property of certificates having validity periods).

I don't believe it does this, but you could do this without DNS as 8.8.8.8, etc already have IP address certificates:

    curl -sI https://1.1.1.1 | grep -i '^date:'

    curl -sI https://8.8.8.8 | grep -i '^date:'

    curl -sI https://9.9.9.9 | grep -i '^date:'

It would need a custom tool though, as curl only has --insecure, not a way to avoid just the notBefore / notAfter validation of the cert.

(This is not the only thing to use this technique, OpenBSD's ntpd has a way to contrain time based on HTTP headers: https://man.openbsd.org/ntpd.conf#CONSTRAINTS -- the default ntpd.conf ships with Quad9 configured via IP address.)

Oh this is a good point! Looking at my DNSSEC domain (hosted by CloudFlare) on https://dnssec-debugger.verisignlabs.com - the Inception Time and Expiration Time seems to be valid for... 3.5 days? This isn't something I look at much, but I assume that is up to the implementation. The new shortlived cert is valid for 6 days. So, from a very rough look, I expect X.509 certificate is going to be less time sensitive then DNSSEC - but only by a few days. Also, very likely to depend on implementation details. This is a great point.

Practically, though, you rely on hardware time until you get network time.

Assuming your device gets an IP via DHCP, there is a solution that does not involve hard-coding IPs into software.

DHCP option 42 (defined in RFC 2132) can be used to specify multiple NTP server IPv4 addresses.

(There’s also DHCP option 4, but that’s used to specify the IP for the older RFC 868 time protocol.)

DHCPv6 has option 31 for SNTP (via deprecated RFC 4075), and option 56 for NTP (via RFC 5908).

So, that would probably be the best option: Get an NTP address from DHCP or DHCPv6, use that to set your clock, and then do whatever you need!

(Yes, it does require that you trust your DHCP source, and its NTP reference.)

this seems possible to avoid as an issue without needing IP certs by having the configuration supply both an IP and a hostname, with the hostname used for the TLS validation.

Yes, that is absolutely possible, but doesn't mean that will be the default. I commented recently [0] about Ubuntu's decision to have only NTS enabled (via domain) by default on 25.10. It begs the question how system time can be set if the initial time is outside of the cert's validity time-frame. I didn't look, but perhaps Chrony would still use the local network's published NTP servers.

[0]: https://news.ycombinator.com/context?id=44318784