For what they're worth, my random thoughts are below... On 4/11/19 4:31 AM, Hal Murray via devel wrote: > There is a potential item: We may need the NTP server to listen on some port > in addition to 123 in order to get around various filtering rules leftover > from NTP DDoS amplification attacks. Need more data which a release would > help.
My inclination is that tcp 123 is the obvious choice unless/until IANA allocates a port or some other wider-community consensus develops. > I think we need a couple of scripts for monitoring certificates. Details > TBD, but I'm thinking of things like when does my certificate expire and tell > me ??? about the certificates on the servers I'm using. This will get more > interesting when we figure out what to do about additional certificate > checking. It would be half just a convenient reminder of how to do things > and > maybe a cron job to warn you that your certificates are timing out or some > server's certs are busted. This problem is not specific to NTPsec, so I would suggest it's out of scope for here. Personally, for other TLS certificates, I mainly use certbot. If it fails to renew the certificate, it exits with a failure status, which causes the systemd service unit to be in a failed status. I monitor that (failed units) generally. If you want to do some verification script, here is a starting point that I've used: openssl verify -CAfile chain.pem -purpose sslserver cert.pem Another idea might be for ntpd (in server mode) to verify the certificate on startup and log an error (and/or refuse to serve NTS and/or die) if the server certificate fails verification. If you want to take that further, you could track the earliest NotAfter in the chain and do something when the certificate expires. > We need a good writeup on getting started when the system time may not be > known. That means we have to understand the issues. Whether it's "good" or not, I don't know, but I already provided one of these, expanding on the NTS draft's suggestions. See "Certificate Verification" in devel/nts.adoc, starting at "It is desirable to include a middle-ground option". Note that all mentions of OCSP are only applicable if/when you do OSCP; they're not requirements for implementing the bootstrapping mode. -- Richard _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel