firmware: wrong permission on /etc/ssl/cert.pem after 'configctl firmware configure'

[asche77]

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

• I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Describe the bug

Since the update to 21.7.6 and a renewal of my wildcard LetsEncrypt certificate by the ACME plugin and [...?], chrony could not connect to most NTS servers.

chronyc sources shows

MS Name/IP address Stratum Poll Reach LastRx Last sample
=============================================================================== 
^* time.cloudflare.com 3 6 37 11 -36us[ +469us] +/- 17ms 
^? sth1.nts.netnod.se 0 8 0 - +0ns[ +0ns] +/- 0ns 
^? sth2.nts.netnod.se 0 8 0 - +0ns[ +0ns] +/- 0ns 
^? ptbtime1.ptb.de 0 8 0  - +0ns[ +0ns] +/- 0ns 
...

The syslog spams error message as follows (presumably one per server):
2021-12-02T14:15:36 chronyd[5971] Could not set credentials : Error while reading file.

For some reasons, most NTS servers failed but two NTS servers worked: time.cloudflare.com and nts1.time.nl.

It seems to be some form of permission error on the SSL cert file. The following was set:

root@OPNsense:/usr/local/etc # ls -la /etc/ssl/ 
total 454 
drwxr-xr-x 2 root wheel 4 Nov 29 11:30 . 
drwxr-xr-x 25 root wheel 99 Nov 25 21:09 .. 
-rw-r----- 1 root wheel 698890 Nov 29 11:30 cert.pem 
-rw-r--r-- 1 root wheel 10921 Nov 10 11:08 openssl.cnf

with cert.pem set to "rw-r-----", I had the described issues.

If the cert.pem is set to "rw-r--r--" (chmod 644 cert.pem), chrony can connect to all NTS servers just fine (like before):

Name/IP address             Mode KeyID Type KLen Last Atmp  NAK Cook CLen
=========================================================================
time.cloudflare.com          NTS     1   15  256  23d    0    0    8  100
sth1.nts.netnod.se           NTS     1   15  256  26m    0    0    8  100
sth2.nts.netnod.se           NTS     1   15  256  26m    0    0    8  100
ptbtime1.ptb.de              NTS     1   15  256  26m    0    0    8  100
ptbtime2.ptb.de              NTS     1   15  256  26m    0    0    8  100
ptbtime3.ptb.de              NTS     1   15  256  26m    0    0    8  100
nts1.time.nl                 NTS     7   15  256   4d    0    0    8  104
nts.ntp.se                   NTS     1   15  256  26m    0    0    8  100
ntp2.glypnod.com             NTS     1   15  256  26m    0    0    8  104
ntpmon.dcs1.biz              NTS     1   15  256  26m    0    0    8  104
netmon2.dcs1.biz             NTS     1   15  256  26m    0    0    8  104
nts.netnod.se                NTS     2   15  256  27m    2    0    0    0

cert.pem is used by chrony as per its config file:

root@OPNsense:~ # cat /usr/local/etc/chrony.conf

port 123
driftfile /var/db/chrony/drift
pidfile /var/run/chrony/chronyd.pid
makestep 1 3

ntsdumpdir /var/lib/chrony
ntstrustedcerts /etc/ssl/cert.pem
nosystemcert

server time.cloudflare.com iburst nts
server sth1.nts.netnod.se iburst nts
server sth2.nts.netnod.se iburst nts
server ptbtime1.ptb.de iburst nts

EDIT: No longer sure it is actually ACME causing this.

• ACME updated my certificate on Nov 30, 03.00 CET.
• The cert.pem carries datestamp Nov 29, 11.30 ... ?

To Reproduce

Steps to reproduce the behavior:

1. Setup chrony plugin with NTS servers.
2. Update to 21.7.6.
3. Renew SSL certificate.
4. some other magic thing?
5. check chrony sources / authdata status.
6. See error: chrony can't connect to the NTS servers
7. check syslog.
8. See error messages "Could not set credentials : Error while reading file."

Expected behavior

Chrony to continue being able to access the NTS servers following a certificate update.

Software version used and hardware type if relevant, e.g.:

OPNsense 21.7.6-amd64
FreeBSD 12.1-RELEASE-p21-HBSD
OpenSSL 1.1.1l 24 Aug 2021

[asche77]

Comment: Not sure anymore it is really an ACME issue:

ACME renewed my certificate on Nov 30, 03.00 CET
cert.pem carries datestamp Nov 29, 11.30

Could it also be that chrony was removed from user group "wheel"? Or another action causing a renewal / rights reset of cert.pem?

[fichtner]

@asche77 thanks for the report. I fixed the inconsistency and the file shouldn't change permission away from 644 indeed.

Cheers,
Franco