How to share Letsencrypt cert files amonst several daemons having different group name

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP



How to share Letsencrypt cert files amonst several daemons having different group name



Multiple daemon applications would like to access the same TLS certificates (or chain, or private) keys.



And they all run their daemon with different GID and group name.



My attempts at securing the private key in a safe manner, yet sharing it across different daemons (having their own GID) with the following various approaches (and some later nixed) are:



Set file permission to "blaze of glory" chmod a+rwx. This got nixed because it reveals the secret privkey.pem file to the entire filesystem.


chmod a+rwx



Create a new group keys and add nginx, apache, named (or bind), and sftdyn group to the keys group in /etc/group (or using adduser nginx keys). Use new keys group on the PEM files. Then cap PEM files' permission with chmod 0640.


keys


nginx


apache


named


bind


sftdyn


keys


adduser nginx keys


keys


chmod 0640



Use setfacl.


setfacl



Which of 2 or 3 is best to address this thorny issue?




1 Answer
1



System admin side of me believes strongly in "keep it simple" and says to do it via the "keys" group (or ssldaemons or whatever you want to name it - I think group names should describe the membership or purpose if possible) and regular old boring file system permissions.



On the other hand, if you are already using ACLs then using just another ACL rule or three would fit better into your work flow/policy/admin style.



If you aren't using ACLs already, then I wouldn't head down that road - no need to make things excessively complex. Unless of course you need an excuse to management to do it :)





Secondary group ID would be okay then?
– Egbert S
Sep 10 at 12:20





@EgbertS works fine, I use it to control a few other things so in my use case it had to be 2nd-ary groups. And, from a sysadmin side, adding a user's primary group to some user as a secondary group is against the design of the permissions model - it works, but it also removes the ability ot have a file/directory that is private to the first user.
– ivanivan
Sep 10 at 20:22





Unless the file has root:secondgroup and 0750/0640?
– Egbert S
Sep 11 at 0:41





@EgbertS root isn't the only user that may need to keep things private. Think about hte private half of a public/private key pair?
– ivanivan
Sep 11 at 0:57





Hence the chown root:key <file> notation?
– Egbert S
Sep 12 at 20:00


chown root:key <file>






By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Popular posts from this blog

Firebase Auth - with Email and Password - Check user already registered

Dynamically update html content plain JS

How to determine optimal route across keyboard