Run letsencrypt as 'encrypt' user

Help
1

Hey everybody, noob here :slight_smile:
Again here is somebody not liking that letsencrypt needed to be run as sudo/root. So here was my approach that I couldn’t finalize however. Maybe you can directly point out why this is a bad idea or give me a hint which other client could help me out.
I checked out the “No_Sudo_Client” in Python but it has the disadvantage you have to do it yourself.

My Idea was to create a new user encrypt with an priv.key and let him do all the encrypt stuff. As member of /www-data/ it can have access to www-data to do all what is needed. The server-certificates are then stored in his home dir. In my case apache can look them up over there. Or one gives user encrypt the right to access the default ssl-certificate storage.

In fact I do not unserstand why root access is needed at all (okay installing packages at the begining but afterwards?)
My scenario is not 100% save but I guess better then the root version.

So, how to make it real?: I wanted to install letsencrypt ‘local’ and that was my first problem. Is there no ‘PREFIX’ flag or so? Second: letsencrypt-auto needs root in any case and I cannot make it to run without. The stupid letsencrypt (no-auto) version, I cannot find. Where ist it located? (As I said: “Noob here”)

May some experts of you help me out?
Thank you very much in advance!
Greets
Ben

2

I'm actually happy with the security of my server being protected by root. I don't need a user with lesser privileges tampering with my certificates.

However, I understand there are situations where root is impractical. In those cases, there are lots of other clients you can use that don't require root. I'd recommend acme.sh, it's pretty mature and pretty powerful, and doesn't require root. You can install it anywhere (even in your home directory), and you can specify where certs are stored.

Using acme.sh, you can do everything as user "encrypt".

You can probably do want you want with the official client, but as a noob, don't give yourself the headaches (I say that as a slightly less nooby noob :wink: )

3

Thanks you very much.
Indeed it was excactly what I was looking for.
It took me a day but now everything is running.
Thank you very very much :smiley:
Ben

4

Very glad I could help :slight_smile:

5

Hi! I think better privilege separation in the client is a worthy goal, but it’s a bit more complicated than it seems. For the Apache and Nginx authenticator, the client needs permission to write the config files for those servers. For the standalone authenticator, the client needs permission to bind port 443 (this can be accomplished with capabilities, though). For all clients, the client needs permission to write out the private key files as owned by root and only readable by root.

It’s possible with some tweaking to get the official letsencrypt client to run as non-root (you need to override the config, log, and keys directories), but you lose the ability to auto-configure your web server.

6

Hi,
I am not really on your side.
Lets talk about ngnix/apache only:

  1. You need root only once to deploy the configuration. Afterwards the configuration files remain same all the time, you just exchange the certificates.

  2. The key files do not have to belong to root. They can belong to any user what would be as save as belonging them to root. Important is only that this user is ‘separated’ from the others like www-data for apache. In my case I have a user encrypt that has a special location /etc/mycert/to write the certificates to. As it encrypt is member of www-data group. The server has no problem with reading the certificates.

Okay the tricky part is reloading the apache/ngnix after renewing the certificates. I’m gonna tell you the truth. I have not tried what will happen if I do not reload the server and just replace the certificates…
Maybe you can tell me already before that it will not work :wink:
Good night and best greets
Ben

7

On renewals, you typically need to re-do the steps where you prove to Let's Encrypt that you control the server. If you are using the Apache or Nginx authenticators, this involves editing configuration and gracefully restarting the service.

My understanding of best practice for keys is that they should not be readable by www-data. The web server can start as root, read the keys, then drop privileges. That way if the server is compromised it doesn't necessarily result in key compromise.

8

My opinion falls somewhere between jsha's and benni's - that's awesome! I'm never the moderate voice!

While I completely understand why you want the client to edit configurations (point two of your key goals), I'm not a big fan. First, I'm not comfortable with my configurations being edited by a third-party client. I would be much more comfortable with the client providing me with text that I could choose to enter into my configs.

Secondly, the client can't (or couldn't) handle a single vhosts file anyway. I honestly didn't even know you could have vhosts in multiple files, I've always had a single vhosts since Apache 1.x back in the 90s.

Also, the client doesn't need root if it's authenticating via webroot (as long as the user has write access to the webroot location). That said, I am happy the certs are protected and renewed by high-privilege root. And I understand the client's config abilities will get smarter - it's still only v0.5!

This is true, and if you manually configure your webserver, the client doesn't need root at all. However as jsha said, renewal may need root to bind certain ports depend on method, plus only root should be able to access your priv key.

But it really should. Your priv key is a very important security item and a valuable target for attackers. It is far easier to get the privileges of user "encrypt" than it is the privileges of root.

Actually, root could run a regular cron job reloading Apache and Postfix, it doesn't have to be tied to the actions of the client (after all, you're configuring the web server separately anyway). Of course, you'd want to configure root's reload cron to run just after Encrypt's renew cron, but that's no big deal.

And I'm guessing that if you regularly renewed without reloading, everything would work fine for three months, and then every connection would warn you your site is not secure! (Until you restarted/reloaded Apache, or restarted your server.)

:thumbsup: In fact, I thought that was Apache's default behaviour for many years.

1 Like
9

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