On 2022/12/17 18:03:01 +0100, Omar Polo <[email protected]> wrote: > On 2022/12/17 16:25:20 +0000, Lucas <[email protected]> wrote: > > > > Then the private keys within would all have 0400 permissions, user and > > > > group > > > > being the same (so _prosody:_prosody for XMPP-related TLS). I noted > > > > that the > > > > default is 700 permissions on `/etc/ssl/private` with root:wheel > > > > ownership. Is > > > > the approach I've just outlined with adding a group and modifying > > > > permissions a > > > > bad idea? > > > > > > Personally, I wouldn't deviate from the os defaults by changing the > > > permission on /etc/ssl/private. > > > > > > it seems fragile, and you'd also need to make sure permissions are > > > kept when updating the certificates. > > > > 100% agree with this. Also, you should update mtree accordingly to avoid > > security(8) noise, then you can get some sysmerge noise on updates, ... > > > > > all handled by cron as usual: > > > > > > ~ * * * * acme-client example.com && rcctl reload httpd > > > ~ * * * * acme-client xmpp && rcctl restart prosody > > > > What I do is replacing `rcctl restart prosody` with a script that > > > > 1. Copies private key and certificate into `/etc/prosody/certs` and > > fixes the owners and permissions > > 2. Runs `rcctl reload prosody` instead > > that's basically what i had too, before noticing that i could have > acme-client do the work for me. > > > I believe that a plain `rcctl re{load,start} prosody` shouldn't work > > after acme-client creates a new private key, as that is created with > > mode 0400 owned by root, and prosody runs under _prosody user directly, > > not starting as root, reading the key and then dropping to _prosody. > > the key is 0400 but inherits the permissions from the directory, so > it's _prosody:_prosody here.
Correction: acme-client creates the key as 0400 and permissions root:_prosody, which means that prosody can't read it. However, once chown'ed to _prosody:_prosody one time its owner won't change (or at least hasn't changed for me yet) and regular certs update works fine. > (replacing my domain name with `example.com', the output is untouched > otherwise.) > > antartica$ doas ls -lah /etc/prosody/certs/ > total 48 > drwx------ 2 _prosody _prosody 512B Nov 22 20:19 . > drwxr-xr-x 4 root wheel 512B Jun 9 2022 .. > -rw-r--r-- 1 root _prosody 805B Nov 12 20:28 Makefile > -r--r--r-- 1 root _prosody 5.9K Nov 22 20:19 example.com.crt > -r--r--r-- 1 root _prosody 5.9K Sep 23 20:33 example.com.crt.1 > -r-------- 1 _prosody _prosody 3.2K Apr 1 2022 example.com.key > -rw-r--r-- 1 root _prosody 1.5K Nov 12 20:28 openssl.cnf > lrwxr-xr-x 1 root _prosody 17B Mar 27 2022 room.example.com.crt -> > example.com.crt > lrwxr-xr-x 1 root _prosody 17B Mar 27 2022 room.example.com.key -> > example.com.key > lrwxr-xr-x 1 root _prosody 17B Apr 1 2022 upload.example.com.crt > -> example.com.crt > lrwxr-xr-x 1 root _prosody 17B Apr 1 2022 upload.example.com.key > -> example.com.key > > Have been running like this for various months already and worked > flawlessly. I'd like to revisit the configuration sometimes to drop > the symlinks tho.
