UniFi controller cannot access keystore after ACME cert update

Started by 9axqe, October 21, 2024, 06:10:15 PM

Previous topic - Next topic
My opnsense letsencrypt cert renewed 2 days ago, and the ACME automation updates the cert in the UniFi keystore, as it always does.

I recently update the UniFi plugin, maybe that's related.

These are some logs I can see under /usr/local/share/java/unifi/logs/server.log:

[2024-10-21T17:37:45,968+02:00] <main> INFO  system - [internal] unable to set file permission on /usr/local/share/java/unifi/data/keystore: /usr/local/share/java/unifi/data/keystore: Operation not permitted
[2024-10-21T17:37:45,984+02:00] <main> INFO  system - [internal] unable to set file permission on /usr/local/share/java/unifi/data/keystore_original: /usr/local/share/java/unifi/data/keystore_original: Operation not permitted
[...]
[2024-10-21T17:39:42,557+02:00] <ble-load-keystore> WARN  blebridge - unable to load local keystore for BLE bridge /usr/local/share/java/unifi/data/keystore (Permission denied)


I noticed the keystore is owned by root:wheel somehow, while other files in the same directory are owned by user unifi:


root@opn:~ # ll /usr/local/share/java/unifi/data/
total 86
drwx------  3 unifi wheel     5 Oct 15 14:03 backup/
drwx------  4 unifi wheel   365 Oct 21 17:55 db/
drwx------  3 unifi wheel     4 May 18 03:54 firmware/
-rw-------  1 unifi wheel 26177 Oct 21 17:40 firmware.json
-rw-r-----  1 root  wheel  3029 Oct 19 00:01 keystore
-rw-r-----  1 root  wheel  3029 Oct 19 00:01 keystore_original
-rw-------  1 unifi wheel  1424 Oct 21 17:39 model_lifecycles.json
drwx------  3 unifi wheel     3 May 19 10:06 sites/
-rw-------  1 unifi wheel  1393 Oct 21 17:39 system.properties
-rw-------  1 unifi wheel  1393 Oct 21 17:39 system.properties.bk
-rw-------  1 unifi wheel 76067 Oct 19 01:03 uidb.json


I ran


chown unifi:wheel /usr/local/share/java/unifi/data/keystore
chown unifi:wheel /usr/local/share/java/unifi/data/keystore_original


restarted the unifi service and it seems to fix the issue.

My problem is, the next cert renewal in 2 months will cause this to fail again I expect.

I would like to check the command used to update the keystore but I'm not sure where this is defined. Pointers welcome.

The unifi keystore is updated via acme.sh. Seeh https://github.com/acmesh-official/acme.sh/blob/master/deploy/unifi.sh (around line 120-123. The problem is that a new keystore is made by the user running the command (being root).


What could help is to change this line: https://github.com/opnsense/plugins/blob/80c2623bd581f4586b09eb54ae30b2e0965cf60c/security/acme-client/src/opnsense/mvc/app/library/OPNsense/AcmeClient/LeAutomation/AcmeUnifi.php#L42

`$this->acme_env['DEPLOY_UNIFI_RELOAD'] = 'service unifi restart';` into something like `$this->acme_env['DEPLOY_UNIFI_RELOAD'] = 'chown unifi:wheel ' + (string)$this->config->acme_unifi_keystore + '; service unifi restart'

I've submitted a bug report and a suggested fix here: https://github.com/opnsense/plugins/issues/4417

It appears the fix is now included in acme.sh 3.1.1

I don't think I understand how to create a PR to have this version included in the next opnsense.

The software versions for the acme plugin listed here are different, hence I think I'm missing something. Is there another way to ask for this version bump?

Unfortunately, the fix in acme.sh v3.1.1 does not fix this issue for me:

after ACME has updated the certificate, the user is again root:wheel:

% ls -la /usr/local/share/java/unifi/data/keystore
-rw-r-----  1 root wheel 5974 May 25 21:33 /usr/local/share/java/unifi/data/keystore


The pull request was modified after the merge. It now use "find" with "-print" option to get folder ownership and keystore ownership before comparing them. The "-print" option is not available in the BSD version of "find". So this update do work on linux but not on BSD. I did a pull request that should fix it.

Quote from: privacyfreak on July 14, 2025, 09:49:19 PMThe "-print" option is not available in the BSD version of "find".

Since when?

root@opnsense:~ # find / -name group -print
/var/db/etcupdate/current/etc/group
/etc/group

Dropping one of the most frequently used predicates in find(1) would be quite a bummer.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

You're right, it do exist. Seems I misread something. I just noticed in the "unifi.sh" script, the option is -printf instead of -print. My bad.

The command use printf which seems to not be correct in bsd. It should be print. Also the print option doesn't  seem to behave the same. Which result in the process not changing the ownership. By using ls -ld with sed it work on both linux and bsd. I tested the pull request by manually editing the "unifi.sh" on my box and the fix this issue.