Bug 213448

Summary: rc.d/ntpd: Cannot fetch leap-seconds file if security/ca_root_nss package not installed
Product: Base System Reporter: Vick Khera <vivek>
Component: binAssignee: freebsd-rc (Nobody) <rc>
Status: Closed FIXED    
Severity: Affects Many People CC: dclarke, freebsd, imp, jasonmader, kevans, meta, pi
Priority: --- Keywords: needs-qa
Version: 10.3-RELEASEFlags: koobs: maintainer-feedback? (kevans)
koobs: mfc-stable13?
koobs: mfc-stable12?
Hardware: amd64   
OS: Any   
See Also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230017
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228621

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 freebsd_triage 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 freebsd_triage 2019-09-19 02:23:24 UTC 
*** Bug 230017 has been marked as a duplicate of this bug. ***
Comment 7 Koichiro Iwao freebsd_committer freebsd_triage 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 freebsd_triage 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 freebsd_triage 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.
Comment 10 Kubilay Kocak freebsd_committer freebsd_triage 2022-07-26 03:39:31 UTC 
@Kyle Has the situation changed since CA stuff in base?
Comment 11 Maxim Konovalov freebsd_committer freebsd_triage 2023-12-18 07:38:44 UTC 
*** Bug 275799 has been marked as a duplicate of this bug. ***
Comment 12 Maxim Konovalov freebsd_committer freebsd_triage 2024-02-01 00:06:50 UTC 
*** Bug 262391 has been marked as a duplicate of this bug. ***
Comment 13 Dennis Clarke 2024-02-01 16:16:20 UTC 
The duplicate bug I filed is not *really* a duplicate but close enough
for anyone to care about the fact that the leap seconds data file can
not easily be found. Certainly the information in the default ntp.conf
file is wrong.

Seems the place to go to get an up to date leap seconds file is :

    https://data.iana.org/time-zones/data/leap-seconds.list
Comment 14 Warner Losh freebsd_committer freebsd_triage 2024-02-05 15:06:09 UTC 
The two canonical places to get an up to date leap are:
https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list
and NIST's ftp server, which they are phasing out.

The IETF one is laggy and we should use the above link.

https://reviews.freebsd.org/D43752
Comment 15 Dennis Clarke 2024-02-07 04:01:28 UTC 
(In reply to Warner Losh from comment #14)

Nice to see this is a done deal :

https://cgit.freebsd.org/src/commit/?id=11da791920ba285f0832f09cb504ac81e35ff8d1
Comment 16 Warner Losh freebsd_committer freebsd_triage 2024-02-19 05:51:31 UTC 
Merged to 13.3 and maybe will be a EN too...