How does Apache access SSL certs created by root user?

8
votes

I have a Debian server on which I am running Apache HTTPD.

I have configured it to use certain SSL certificates which reside in /etc/ssl/private/. Only root user has read-write access to this directory. The HTTPD process is run as www-data user, but it is started using an init.d script (that comes with HTTP installation) by root user.

When apache2 process is running as www-data and the SSL certs can only be read by root user, how is Apache able to read the certs and function without any problem?

I am facing similar problem with an init.d script that I have written for a custom server written in Python. This init.d script was working just fine as long as I was not using SSL certs. As soon as I added these certs, the process just won't start because it won't be able to read the certs as www-data user can't read the certs.

I have used nginx as well in a similar situation and the results were similar as they were with Apache. So how do these two projects tackle this problem?

3
linuxapachenginxapache2sysadmin
"I am facing similar problem" > What is your exact 1st problem - I don't see it? Also, why is your 'custom' 'server' init script written in python? Start Apache using the provided system server init script for your OS; it's what it for and is thoroughly tested. Then you can use python all you want to interact with server which is running as root. Do not start server any other way! What is the reasoning behind starting Apache or any other system/root service with a python script? – B. Shea

3 Answers

4
votes

When you run

ps aux | grep apache2

You'll notice that there is a process owned by root, I think this may be the reason, because this process can access the files/dirs owned by root.

3
votes

Root runs Apache in most situations.
Hence root is the owner of the main "parent" process.

When Apache starts, it (normally) should have been started using root (partly why you have to use sudo with the system service manager to start it correctly). Further, the parent process (running as the root user) then reads the configuration(s) in, binds to the given system ports (usually 80 and 443) and other tasks. These ports are also considered privileged (anything under 1024). Once completed, it spawns child processes (which can also use "workers" via the core modules).

Since the parent process is root and the children/workers are run under 'www-data' (or another non-privileged user), Apache can still bind to system ports and deal with root privilege files such as private SSL keys/etc in this manner.

"While the parent process is usually started as root under Unix in order to bind to port 80, the child processes and threads are launched by the server as a less-privileged user. The User and Group directives are used to set the privileges of the Apache HTTP Server child processes. The child processes must be able to read all the content that will be served, but should have as few privileges beyond that as possible. In addition, unless suexec is used, these directives also set the privileges which will be inherited by CGI scripts.*"

From: https://httpd.apache.org/docs/2.4/mod/prefork.html#how-it-works

1
votes

Only the private key is protected as the certificate is publicly available in the /etc/ssl/certs directory. The /etc/ssl/private is root only readable but ssl-cert user group is granted to execute (ssl-cert group X rights). This system group is perhaps the one involved in the SSL authentication method.

could you try :

sudo chown root:ssl-cert /etc/ssl/private/your-private.key

reload apache and check again ?

I have purged all Apache2 installations on my servers so I can't test this anymore.

Hope that helps, regards