> > 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

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.

-Lucas

Reply via email to