Hi,
it is an expected behavior and a proof that constraints are working
correctly: the certificate check fails because it is not valid.
I don't see a technical solution here because we'd either have to
disable constraint checks and loose their security benefit or we keep
them enabled and rely on the certificate validation.
Should we validate the certificates but ignore the time/expiration? I
don't think so. Should we cache the last-known certificate? This
wouldn't really work with fast-changing certificates such as Let's
Encrypt.
If you have a system where the clock is too far off, you should set
the clock before running ntpd, e.g. with
# rdate pool.ntp.org
(and validate the returned result by looking at your watch/phone)
Or
# date 201807071710
(I find the date command slightly more difficult to type)
Reyk
On Sun, Jul 01, 2018 at 03:29:03PM +0200, Solene Rapenne wrote:
> Hi
>
> I found a corner case about ntpd where ntpd -s can't set the date because of a
> constraint in ntpd.conf.
>
> Using default ntpd.conf:
>
> servers pool.ntp.org
> sensor *
> constraints from "https://www.google.com";
>
>
> it's reproducible with the following command
>
> $ doas /etc/rc.d/ntpd
> $ doas date 07010000
> $ doas ntpd -sdv
> ntp engine ready
> constraint request to 2607:f8b0:4005:801::2004
> constraint request to 216.58.192.4
> tls connect failed: 2607:f8b0:4005:801::2004 (www.google.com): connect: No
> route to host
> no constraint reply from 2607:f8b0:4005:801::2004 received in time, next
> query 900s
> tls write failed: 216.58.192.4 (www.google.com): certificate verification
> failed: certificate is not yet valid
> no constraint reply from 216.58.192.4 received in time, next query 900s
> no reply received in time, skipping initial time setting
>
>
> As the certificate is "not yet valid" due to the time being too far behind,
> the constraint setting prevent ntpd to set the clock.
>
> Is it an issue or a behavior which should be documented?
>
> Regards
>
--
