How to use certs in non-root services?

Hey all,

I want to set up Prosody with my new beta Let’s Encrypt certificates. On my setup, the prosody process runs as a non-root user, so it has no access rights on the certificate files.

How do you deal with these situations? Should I create a “ssl-cert” group, make the prosody user a member, give the group read rights on the files (and access rights on the parent directories) like suggested here? I guess these rights would be overwritten when requesting new certs?

Or should I let prosody run as root? Or do you have another solution?

Thanks,
Sebastian

2 Likes

I’m still pretty clueless about this… :-/

Using a group like ssl-cert and setting appropriate access rights is usally the way I do it.

The proper proper way is probably writing an Installer plugin to letsencrypt for Prosody.

Meanwhile (while one is not written) you should use the described option of creating group, etc. You could also write a simple script for key rotation so letsencrypt writes its keys to whereever, then you copy them to canonical location on your OS with ACLs you want. (Just FYI: canonical location for certs in RH/CentOS is /etc/pki/tls/certs).

Ok, thanks! As I don’t want to copy the certs around, I’m now running this after each renewal:

chgrp -R ssl-cert /etc/letsencrypt
chmod -R g=rX /etc/letsencrypt

Can’t you just set a chmod 2755 /etc/letsencrypt ? That way every new file/directory created below /etc/letsencrypt/ will inherit the group of /etc/letsencrypt. Since you have /etc/letsencrypt with ssl-cert as group that should work out perfectly for your usecase.

3 Likes

It would be nice if /etc/letsencrypt/live was 755 and the directories under that were 750. That way, you could assign a group for a particular service to each domain instead of the whole SSL certs folder (which is no more secure than just giving everyone read access).

Alternatively, the client could have an option such as --copy-to owner:group:750:/path/to/target/dir/ so the cert gets copied (not symlinked) to the target folder with the specified permissions as well as /etc/letsencrypt/live

2 Likes

Sorry for reviving this thread, but for future searchers having this issue, if you are using the certbot client, a post-renew script to copy certs to the correct places (and make any modifications necessary for the target servers) works very well. The script can be setup so that it does not change the permissions of the target files. For example:

#!/bin/sh
echo "Letsencrypt renewal hook running..."
echo "RENEWED_DOMAINS=$RENEWED_DOMAINS"
echo "RENEWED_LINEAGE=$RENEWED_LINEAGE"

if grep --quiet "my.jabber.domain" <<< "$RENEWED_DOMAINS"; then
  # jabberd requires the private key and cert chain together
  > /etc/jabberd/server.pem
  cat \
    $RENEWED_LINEAGE/privkey.pem \
    $RENEWED_LINEAGE/fullchain.pem > /etc/jabberd/server.pem
  systemctl restart jabberd
  echo "jabberd server.pem updated and jabberd restarted"
fi

if grep --quiet "my.postfix.domain" <<< "$RENEWED_DOMAINS"; then
  > /etc/pki/postfix/my.postfix.domain-key.pem
  > /etc/pki/postfix/my.postfix.domain.pem
  cat $RENEWED_LINEAGE/privkey.pem > /etc/pki/postfix/my.postfix.domain-key.pem
  cat $RENEWED_LINEAGE/fullchain.pem > /etc/pki/postfix/my.postfix.domain.pem
  systemctl restart postfix
  echo "postfix key and cert chain updated and postfix restarted"
fi

This approach does not require any permissions machinations on the letsencrypt directories.

1 Like

Another revival for the specific issue OP had (and that I had discovering this thread)
Prosody now specifically makes this easier for let’s encrypt

https://prosody.im/doc/letsencrypt
Using Prosody 0.10

prosodyctl --root cert import /etc/letsencrypt/live

Or using certbot’s deploy hook

certbot renew --deploy-hook "prosodyctl --root cert import /etc/letsencrypt/live"

This has been very helpful to me! I assume it’ll work when the time comes, though I made some changes:

  • Put the script in the deploy/ subdir, rather than the renew/ subdir, because the former is run only upon successful renewal (including deployment), while the latter is run after any renewal attempt. (So I wouldn’t call it a “post-renew script” so much as a “post-deployment script”.)
  • I’m using GNU’s cp --backup=t, rather than cat (and zeroing out the old files), to preserve the old files, “just in case”.
  • I added a chmod 600 for the private key after copying.

Hope this is helpful (and not harmful!). Note that I’m updating only my /etc/dovecot/ config; I haven’t tried updating my SMTP config yet (I’m running qmail, not Postfix).

Hey I need help to create a certificate for my prosody server but I ud like to see any example I need to see the configuration inside prosody some like
ssl = and all and how to create the certificate and import it

I posted instructions and a renewal script for qmail, that might be helpful for some other non-root cases as well.

Qmail renewal script