Thank you, this resolves that concern of mine (and in fact, it was an elegant
enough solution that I felt silly for not doing it that way before). :) It makes
a lot more sense to have acme-client(1) place the exceptional certificates in a
different spot, rather than modify `/etc/ssl/private` to make everything work in
one location.
On 22/12/16 11:16, Omar Polo wrote:
> Can only speak for prosody as it's the only non-base daemon I'm
> getting TLS certificates for; my strategy with it has been to generate
> a different certificate and to deliver it in a place where only
> prosody can read it. Luckily, the prosody package installs
> /etc/prosody/certs owned by _prosody alone.
>
> # /etc/acme-client.conf
> domain xmpp {
> domain name example.com
> alternative names { room.example.com upload.example.com }
> domain key "/etc/prosody/certs/example.com.key"
> domain full chain certificate
> "/etc/prosody/certs/example.net.crt"
> sign with letsencrypt
> }
>
> note the `domain' name is "xmpp" because I have another `domain' block
> for the same domain (but different alt names) for httpd:
>
> # only for httpd
> domain example.com {
> alternative names { www.example.com }
> ...
> }
>
> all handled by cron as usual:
>
> ~ * * * * acme-client example.com && rcctl reload httpd
> ~ * * * * acme-client xmpp && rcctl restart prosody
>
> in prosody.conf.lua i have
>
> certificates = "certs"
>
> I also have some symlinks in /etc/prosody/certs in the form:
>
> {room,upload}.example.com.crt -> example.com.crt
> {room,upload}.example.com.key -> example.com.key
>
> so that prosody can look up the certs by itself without extra
> configuration. Can probably do it without the symlinks, but I was
> lazy and this worked for me.
>
> HTH
