Bug 213448 - The /etc/rc.d/ntpd script cannot fetch NTPD leap-seconds file if ca_root_nss package not installed
Summary: The /etc/rc.d/ntpd script cannot fetch NTPD leap-seconds file if ca_root_nss ...
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 10.3-RELEASE
Hardware: amd64 Any
: --- Affects Many People
Assignee: freebsd-rc mailing list
URL:
Keywords:
: 230017 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-10-13 12:58 UTC by Vick Khera
Modified: 2019-12-04 18:07 UTC (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vick Khera 2016-10-13 12:58:00 UTC
I booted up a test VM I have that hasn't been started for a while. The console logged this:

Oct 13 08:36:25 devbox kernel: Certificate verification failed for /C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./CN=Starfield Root Certificate Authority - G2
Oct 13 08:36:25 devbox kernel: 34380992136:error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed:/u/yertle1/sources/usr10/src/secure/lib/libssl/../../../crypto/openssl/ssl/s3_clnt.c:1191:
Oct 13 08:36:25 devbox kernel: fetch: https://www.ietf.org/timezones/data/leap-seconds.list: Authentication error

I traced it down to the lack of a proper certificate chain:

[root@devbox]# fetch https://www.ietf.org/timezones/data/leap-seconds.list
Certificate verification failed for /C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./CN=Starfield Root Certificate Authority - G2
34380992136:error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed:/u/yertle1/sources/usr10/src/secure/lib/libssl/../../../crypto/openssl/ssl/s3_clnt.c:1191:
fetch: https://www.ietf.org/timezones/data/leap-seconds.list: Authentication error
[root@devbox]# pkg install ca_root_nss
 [[ pkg install details elided as irrelevent ]]
[root@devbox]# fetch https://www.ietf.org/timezones/data/leap-seconds.list
fetch: https://www.ietf.org/timezones/data/leap-seconds.list: size of remote file is not known
leap-seconds.list                                       10 kB 8155 kBps 00m00s
[root@devbox]#

So it appears that the base system ntpd requires the package to properly function: The "fetch" feature of /etc/rc.d/ntpd fails as shown here.
Comment 1 Vick Khera 2016-10-13 13:09:17 UTC
I suspect the workaround here is to add --no-verify-peer to ntp_leapfile_fetch_opts in the /etc/defaults/rc.conf file, but that seems wrong and is just asking for a hack to happen.
Comment 2 Jeremy Chadwick 2017-12-05 20:32:53 UTC
I believe this problem may be related to the following commit, but unsure; gut feeling says very likely:

http://www.freshbsd.org/commit/freebsd/r325256
Comment 3 Jeremy Chadwick 2017-12-05 20:33:34 UTC
(In reply to Jeremy Chadwick from comment #2)
Ignore, wrong tab.  Comment was intended for unrelated Bug 224126.
Comment 4 Jason Mader 2018-07-24 15:55:49 UTC
I opened Bug 230017 before I saw this. FreeBSD 11.2 was released with an outdated leap-seconds file.
Comment 5 Bjoern A. Zeeb freebsd_committer 2018-08-29 14:47:52 UTC
See also https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228621
Comment 6 Koichiro Iwao freebsd_committer 2019-09-19 02:23:24 UTC
*** Bug 230017 has been marked as a duplicate of this bug. ***
Comment 7 Koichiro Iwao freebsd_committer 2019-09-19 02:25:21 UTC
I don't think adding --no-verify-peer is the right way.
As cem say in bug 213448, ca_root_nss should be in base.
Comment 8 Koichiro Iwao freebsd_committer 2019-09-19 03:50:56 UTC
Just an idea, is it possible to distribute new leap-seconds file to replace expired file via freebsd-update?
Comment 9 Vinícius Zavam freebsd_committer 2019-11-22 11:59:07 UTC
(In reply to Koichiro Iwao from comment #8)

AFAIK, it's possible yes.

freebsd-update works in a way that it builds world and kernel 2 times and compares which files/libs changed since the first time it built the source; so one 'touch' command hitting the leap-seconds file can make it to be part of the list of files pushed to freebsd-update.

like, freebsd-update build the untouched source of releng/12.1 and after its done the patches are applied and freebsd-update compiles the code again. after it's all done, the comparing phase starts and it indexes what will be part of the next "-pX" release.