As complex as Apache configurations can be, it's not unlikely that there will be problems. This section will address some common errors and resolutions to those problems.
Fortunately for administrators, Apache comes with a configuration checker, which will test changes made to the configuration before bringing down an operational server. If it finds any errors, it will provide you with some diagnostic information. Consider the following example:
vlager # ../bin/apachectl configtest
Syntax error on line 985 of /var/www/conf/httpd.conf:
Invalid command 'SSLEgine', perhaps mis-spelled or defined by a module not included
in the server configurationThe configuration testing tool has found an error on line 985, and it appears that the SSLEngine directive was spelled incorrectly. This configuration checker will catch any syntactical errors, which certainly helps. Administrators should always run this before stopping and restarting their servers.
The configtest option won't solve all of your problems, however. Transposed digits in an IP, a misspelled domain name, or commented out requirements will all pass the test, but cause problems for the operational server.
This is a very general error, and a variety of circumstances can cause it. This is Apache's way of telling you that it can't find or read the page. If you are getting an error of this nature, first check all of your paths. Remember with Apache, you are operating within a virtual directory environment. If you have links to files outside of this structure, it is likely that the server will not be able to server them. Additionally, you should verify the permissions of the files and make sure that the user who owns the web server process can read them. Files owned by root, or any other user, set to mode 700 (read/write/execute user) may cause the server to fail, since it will be unable to read them.
Pathnames, along with domain names, are often misspelled. While configtest may catch some of them, it is unlikely that it will catch all of them. One typo can cause a whole site to fail. Double-check everything if you are having a problem.
If your SSL server isn't working, there are a number of things that could have gone wrong. If your server isn't delivering the pages, you should check the error_log file. It will often provide you with a wealth of troubleshooting options. For example, our example web server was not serving up SSL pages, but unencrypted pages were being served without issue. Checking the error_log, we see:
[Wed Aug 6 14:11:33 2003] [error] [client 10.10.0.158] Invalid method in request \x80L\x01\x03
This type of error is quite common. The invalid request is the client trying to negotiate an SSL session, but for some reason the web server is serving only unencrypted pages on the SSL port. We can even verify this by pointing the browser at port 443 and initiating a normal HTTP session. The reason why this is occurring is that the server does not think it has been told to enable the SSLEngine, or doesn't think it has.
To fix this problem, you need to verify that you have the line in your httpd.conf file:
SSLEngine On
You should also check the Virtual Host entry that you created for the SSL server. If there is an error with the IP address or DNS name on which it was told to create the server, the server will create this kind of error. Consider the following excerpt of our configuration file:
<VirtualHost www.vbrew.cmo:443> SSLEngine On SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:!SSLv2:+EXP:+eNULL SSLCertificateFile conf/ssl/vbrew.cert SSLCertificateKeyFile conf/ssl/vbrew.key </VirtualHost>
A typo in the VirtualHost directive has caused the server to try to start for a name in the .cmo rather than the .com top-level domain. Of course, Apache doesn't realize this is an error, and is doing exactly what you've asked it to do.
Other SSL-related problems are likely to center on key locations and permissions. Make sure that your keys are in a location known to the server and that they can be read by the necessary entities. Also, note that if you are using a self-signed keysome clients may be configured not to accept the certificate, causing them to fail. If this is the case, either reconfigure your client workstations or purchase a third-party signed certificate.