Httpd Ssl Problems

Home » CentOS » Httpd Ssl Problems
CentOS 11 Comments

Not much of a noob, but I will try.

I just configured httpd and installed mod_ssl and got my certificate from GoDaddy and put them on the server with ssl.conf pointing at them. I am getting this error:

SSLCertificateFile: file ‘/etc/pki/tls/certs/’ does not exist or is empty

It’s a cute error. I have checked several times for misspellings, looked at the file (looks like a cert to me) and I can certify that it is not empty and it most certainly exists. Want some proof? Here…

[root@itsnv607 ~]# ls -l /etc/pki/tls/certs total 1224
-rw-r–r–. 1 root root 571450 Apr 7 2010 ca-bundle.crt
-rw-r–r–. 1 root root 651083 Apr 7 2010
-rw-r–r–. 1 apache apache 1874 Jul 9 11:54
-rwxr-xr-x. 1 root root 3197 Jul 9 11:54 gd_bundle.crt
-rw——-. 1 root root 1164 Jul 8 14:33 localhost.crt
-rwxr-xr-x. 1 root root 610 Feb 21 16:45 make-dummy-cert
-rw-r–r–. 1 root root 2242 Feb 21 16:45 Makefile
-rwxr-xr-x. 1 root root 1131 Jul 9 11:52
-rwxr-xr-x. 1 root root 1708 Jul 9 11:52

Just for fun, I started playing with permissions, just in case that mattered (it didn’t). You can see that is there, where it is supposed to be, and is not empty.

What would cause this error besides what it actually says?

Jason Nemrow Systems Operations Specialist Information Technology Services Eastern New Mexico University

11 thoughts on - Httpd Ssl Problems

  • Nemrow, Jason wrote:

    First, could you do ls -la /etc/pki/tls/certs? I’d like to know if the directory was readable/executable for apache.

    Also, run getenforce


  • Yep. I disabled SELinux and everything is working now for ssl and apache. I will have to look later and study up on how to make SELinux work with this setup.

    Thanks a Lot!!!

    Jason Nemrow Systems Operations Specialist Information Technology Services Eastern New Mexico University

    —–Original Message—

  • It’s always selinux ;-)

    If you install the selinux utilities (policycoreutils-python) then you can use them to set up the security polices. Look in
    /var/log/audit/audit.log for the offending lines and then use commands like this, for example this is what I had to do to allow mysqld to run:

    sudo audit2allow -a -m mysqld > /tmp/mysqld.te
    sudo checkmodule -M -m /tmp/mysqld.te -o /tmp/mysqld.mod
    sudo semodule_package -o /tmp/mysqld.pp -m /tmp/mysqld.mod
    sudo semodule -i /tmp/mysqld.pp

  • Well always when you step outside normal practices…

    Where did you install that mysql from by the way as the base policy has mysql contexts and policies in place…

    In general your advice would work but it’s bad practice…

    The above assumes what you want the application is trying to do is what you want to happen – this is probably not quite the case.

    For the OP it’s likely to be the context of the certificates where you put them… copy them (not move) to somewhere like /etc/httpd so they get the context httpd_etc_t (in the alternative make a dedicated /etc/httpd/certs directory to support multiple certs for virtualhosts with a context of cert_t as this howto describes…

    The http_t domain has permission to read that context type so that will work properly and the various bits restricted appropriately…

    As for your mysql I’m guessing it installed to /opt or /usr/local or had a version number in place such as /var/lib/mysql55 which took the files out of the standard locations and consequently the file contexts would have been incorrect as they would have inherited from those other locations probably resulting in mysqld in the wrong domain too (initrc_t perhaps or bin_t depending how it was started). Using the audit2allow -a -M etc method outlined above would then result in mysqld having too broad access or possibly other processes getting access to the mysql database files or config files improperly (depending on how the auto generated rule went).

    To fix that scenario given that the base selinux policy already has rules for mysql all you need to do is ensure that the right file contexts are on the files in the improper locations.

    First use semanage fcontext -l | grep mysql to get a list of all file contexts related to mysql.

    Then for each of these (there’s only about 21) check to see where you custom install has put the equivalent file (eg /usr/libexec/mysqld might be in /usr/local/bin/mysqld or /opt/mysql/bin/msqld).

    With that knowledge in hand simply copy and paste the context to the new file for example:

    original from the list above: /usr/libexec/mysqld regular file system_u:object_r:mysqld_exec_t:s0

    Add your new path:
    semanage fcontext -a -t mysqld_exec_t ‘/usr/local/bin/mysqld’ && restorecon
    -Rv /usr/local/bin/mysqld

    With the correct contexts on the files you should then be able start the service and it’ll be properly confined in its correct domain.

  • I got from just doing ‘yum install mysql’ I don’t have access to that system any more to see where it got installed.

  • I got from just doing ‘yum install mysql’ I don’t have access to that Well that’s very weird as selinux enabled mysql is supported right out of the box under those conditions…

    Unless this was the early EL5 days whilst Red Hat and co were still in the process of writing a lot of the policies… but then with the targeted policy in place until they wrote an actual policy it still wouldn’t be restricted…

    Ah well that’s the end of that ;)

  • restorecon -R -v /etc/pki/tls

    It sounds like you saved the crt file somewhere else first, and then used “mv” to place it in /etc/pki/tls/certs. Use “cp” instead. A file that’s moved will keep its original SELinux context. A file that’s copied will be a new file, and will get its context from the parent directory.