We only need a rough time to get clocks to within cert/OCSP boundaries
here. If the clock is too broken to connect normally via TLS, can we just
fetch a time from an openbsd.org host using a pinned key hash instead?
(ignoring certificate date errors, and there's not any need to do CA checks).
If we have to rekey the server/s used for this then it degrades to the
current status quo, but there's not a lot else we can do in that situation,
and in the absence of that it's a lot better than we have now.
--
Sent from a phone, apologies for poor formatting.
On 7 August 2018 16:10:25 Reyk Floeter <[email protected]> wrote:
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
--
