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?
Often, the SSL certificate configuration is located in a <VirtualHost> block in a different configuration file. The configuration files may be under a directory like /etc/httpd/vhosts. d/, /etc/httpd/sites/, or in a file called httpd-ssl. conf.
To get a certificate, you must create a Certificate Signing Request (CSR) on your server. This process creates a private key and public key on your server. The CSR data file that you send to the SSL Certificate issuer (called a Certificate Authority or CA) contains the public key.
We can create the SSL key and certificate files with the openssl command: sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/apache-selfsigned. key -out /etc/ssl/certs/apache-selfsigned. crt.
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.
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
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
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With