On 2018/07/25 06:10, Bryan Vyhmeister wrote: > On Wed, Jul 25, 2018 at 08:51:53AM +0100, Stuart Henderson wrote: > > On 2018/07/24 13:25, Bryan Vyhmeister wrote: > > > (Obviously clock was wrong and I did not realize it. Looks like ntpd is > > > not setting the clock with -s for some reason so rdate did the trick.) > > > > If the clock is already more than a little bit wrong and you have > > "constraints" in ntpd.conf, ntpd (even with -s) cannot fix it. > > Thanks for that info. This is with the default ntpd.conf which does > indeed have constraints. I have not powered this system on for quite a > while. I appreciate the explanation. > > Bryan
The problem is that if the clock is wrong, the server's certificate and/or OCSP stapling can't be validated (it either appears to have expired, or not be valid yet), so ntpd is unable to connect using https to check the time. Personally I am no fan of "constraints", I use local NTP servers and trust the relevant parts of the network more than the RTC and batteries on my machines, and don't really like sending potentially fingerprintable external packets showing that a machine has rebooted, so I usually disable it. Obviously opinions differ on this :-)
