Getting ready to issue IP address certificates

Plenty of other responses with good use cases, but I didn’t see NTS mentioned.

If you want to use NTS, but can’t get an IP cert, then you are left requiring DNS before you can get a trusted time. If DNS is down- then you can’t get the time. A common issue with DNSSEC is having the wrong time- causing validation failures. If you have DNSSEC enforced and have the wrong time- but NTS depends on DNS, then you are out of luck with no way to recover. Having IP as part of your cert allows trusted time without the DNS requirement, which can then fix your broken DNSSEC enforcement.

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

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.

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.

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

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.)

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.)

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