On 06/01/2018 02:30 AM, Hal Murray via devel wrote: > The catch is that the web certificates have expiration times and the code > assumes the clock is reasonable.
This isn't limited to "web certificates", but applies to certificates generally. Certificate expiration is fundamentally incompatible with the idea of a clock that is not reasonably accurate. Keep in mind that Let's Encrypt certificates are very popular, and have very short lifetimes (3 months), which may get shorter: https://letsencrypt.org/2015/11/09/why-90-days.html This is just off the top of my head, but I wonder if this is ultimately going to need an SSH-style "leap of faith" trust model. For example, the first time NTP starts up, it would ignore the NotBefore and NotAfter attributes, but validate everything else in the certificate as normal. Then, once the clock is synchronized, it sets a persistent flag on disk saying, "My time is reasonably accurate now." All future checks, including on initial startups of ntpd, would then check expirations. Finally, there would be a configuration option to turn this off, if your system has no battery-backed RTC. Another option would be to simply check the system clock for sanity (e.g. using the ntpd compilation date). If it's insane, do not check certificate expirations. Otherwise, always do. If the system clock is way off, the admin can manually set the clock within reason. -- Richard _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
