Certbot on Mac, certificate permissions

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:
iow.rest
I ran this command:

It produced this output:

My web server is (include version):
nginx 1.21.4
The operating system my web server runs on is (include version):
OSX 11.6.1
My hosting provider, if applicable, is:
self hosted, on the mac
I can login to a root shell on my machine (yes or no, or I don't know):
yes
I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
no
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): 1.21.0

Hey!

I have a question regarding permissions of certs + privkeys on osx..

I am running a local dev environment on my mac with dnsmasq to test backups and restores of existing sites.. This works wonderfully and is great for local development but now i have a need to run a small test / dev server publicly for short periods at a time..

Obviously this requires ssl and I can make it work but i am not happy with how.

certbot creates certs and puts them (by default) in /etc/letsencrypt/**

this is unreadable by non-root user and nginx in my case is not running as root, nor would i want it to.

Its my understanding that the important bit, is that the privkey is readable only by root.

currently server (nginx) complains that privkey is not accessible - permissions denied.

what i have done in the past is to cp -r /etc/letsencrypt ~/homebrew/etc/letsencrypt, then own with the user that runs the server and point to the new readable location in the config..

I know this works but it's not good and i wondered what everyone else was doing or if there was a more logical approach!

So far i have copied the letsencrypt folder from /etc/letsencrypt to ~/homebrew/etc/letsencrypt and owned only the parent directories the certs live in. The certs themselves are still with default perms, owned by root, and they work!

but the privkey cannot be read by nginx as its only readable by root..

Bit of a messy post. If any info is needed please feel free to ask and thanks for helping!

Nginx would not start so i have given the privkey.pem read only privs with 644

Still owned by root:staff

All works as expected and i will close ports for 80 and redirect everything to ssl but -
Is there a better way to do this I havent thought of?

Thanks Again!
Charlie

IMHO, the easiest solutions for your scenarios are to:

  • use group privileges, and allow nginx to read via the group bits.
  • run certbot with command flags to use an alternate directory for certs and logs, and as a different user

Tldr: you’re trying to apply a production security model and archive system to a development workstation. You really don’t have to do either of those.

3 Likes

Hello!

Thanks for chiming in!

So the second option will have the same result I think but in my case, nginx runs as my non privileged user.

If I understand correctly,
In MacOS, would there actually be a security benefit to, for example; running nginx as 'nginxuser' and to chown the certs as 'certuser' and run the equivalent of 'sudo usermod-aG certuser nginxuser' ?

Im not sure there would?

in a typical linux setup it runs with master and worker processes and system and file level permissions can be set up differently, (certbot and nginx can be run only with root) but the servers have like a derivative level of access, im not entirely sure off the top of my head but I am aware it's much easier to secure in a linux env..

It is overkill but i am both interested in learning what i am doing (and really understanding the stuff i already know.) I think with ssl this is about as much as i can do with a 'usuable' osx install and my efforts should focus elsewhere, just wanted to know how dangerous it is to have it readable by others. This Instance may be run from a home connection from time to time, I wouldn't want a fault or misconfiguration to lead to further internal issues / exploitation of the network or its attached devices :slightly_smiling_face:

Tldr:
how much more secure would that be?
how bad is it to have readable permissions on privkey? how and when is this likely to be exploited?

There isn’t any real benefit to that. The typical way to keep using the default data storage (under /etc) is to create a “ssl-certs” group, add nginx/root/etc to the group, then chgrp the directory to that group. IIRC, the various ports to OS distributions mostly automate the group associations to make this all seamless. Certbot runs as root on these systems not as much for security of keys, as the need to bind to port 80 + restart process + manage the configuration files.

The Linux permissions model is really based on shared environments and often exploited attack vectors. You honestly don’t have either on a development machine that is periodically connected.

Even on production machines, limiting ssl keys to root access isn’t a requirement. Large systems and several servers use cloud/api access, and some clients even store keys in sql.

3 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.