So I have a script, which at it's heart runs apachectl -t -D DUMP_VHOSTS to get a list of all the vhosts on a particular machine. It then greps the response from that, and produces a json blob of machine parseable information about the configuration of vhosts on a machine.

This will be run as a non-privileges user, as it simply an analysis of what is, not a privileged attempt to change anything.

However, on debian, non-privileged users, quite rightly can't read anything in /etc/ssl/private, so I get:-

AH00526: Syntax error on line 27 of /etc/apache2/sitesenabled/ssl_proxy.conf:
SSLCertificateKeyFile: file '/etc/ssl/private/ssl-cert-snakeoil.key' does not exist or is empty

This issue is discussed at Apache: SSLCertificateKeyFile: file does not exist or is empty

However, I don't want the user running the script to access the key file or otherwise test the config, I simply want apache to tell me about what vhosts are defined.

On the server that's specifically throwing this error, I don't even use SSL, so it's complaining about a key which doesn't even relate to a VHOST, but I can see that it might, but it seems apache can't be told just to carry on, and ignore SSL modules or anything.

Any ideas how to do that, beyond parsing the apache configs directly?


So it seems on examination, that what apachectl is doing when it DUMP(s)_VHOSTS, is not quite as stupid as thought. It's essentially validating the config file, which is to say, checking that files specified, do exist. It's not, trying to read the contents of the file. Hence the caller doesn't need read permission on the file, just read permission on the directory containing the file.

3 Answers 3


Two ways:

  1. Set up permissions so that the user running the script can see the directory and the files in it. This can be done with ACLs instead of "regular" unix permissions. (man setfacl is a starting point.)

  2. Set up your sudoers file to allow this user to run this one command as a user who can read the files (presumably root or possibly the apache user). The entry should look something like this:

    username ALL = (root) NOPASSWD: apachectl -t -D DUMP_VHOSTS

    This allows the user to use sudo to run this one command only as root without entering a password.

  • These are production servers, so we have no access to sudoers, hence my desire to run these scripts as non-priviledged users. I can see how acls might work, but I suspect it'll cause issues in the future as whomever upgrades the certificates would need to reapply it to avoid breaking things.
    – sibaz
    Commented Jun 29, 2017 at 15:45
  • I did find on a related path, that whereas on Ubuntu /etc/ssl/private is og-wr and so causes the problem when accessing /etc/ssl/private/* On Centos /etc/httpd/conf/ssl.key is 755, whereas /etc/httpd/conf/ssl.key/* is 600, which is secure, whilst not breaking DUMP_HOSTS for non-priviledged users
    – sibaz
    Commented Jun 29, 2017 at 15:47
  • If you can't use sudo, then permissions is the way I would recommend that you go - whether you do it with regular unix permissions or with ACLs is up to you. (I've only once been in an evironment where sudo didn't exist on production servers, and that was one that had far heavier user restrictions in place than a mere sudoers file!)
    – Jenny D
    Commented Jun 29, 2017 at 15:49
  • It's not that sudo doesn't exist, it's that I don't have access to change things in sudoers, so it's not a practical solution.
    – sibaz
    Commented Jul 6, 2017 at 11:29
  • (it's not practical in my case, but it's worth an upvote as it may help someone else)
    – sibaz
    Commented Jul 6, 2017 at 11:39

I have an unsatisfactory work around to the question, to surround all the SSL definitions in any vhost definitions, in a <IfDefine !APACHE_CONFIG_TEST> block, so I can pass a -D APACHE_CONFIG_TEST option to apachectl to avoid it considering and ssl keys.

It would be better if there was a way to do this with apache, rather than having to hack a solution into individual config files.


So in addition to the work around I suggested and the ACL/Sudo approach @jenny-d suggested (which would be fine, if I didn't have my hands tied by not being able to edit sudoers), I suggest the following as an answer (as it's the one I'm going to use):-

As apachectl only needs to see the files which are referred to, not access them:-

chmod a+rx /etc/ssl/private
chmod o-r /etc/ssl/private/*

Hence files are still unreadable by 'others' but others can ascertain that the mentioned file exists

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .