SSL Part 1: Debug VHost
mod_ssl Debugging Virtual hosts
While writing this mod_ssl section I made several typos and introduced other unintentional errors that prevented Apache starting. Thought I would share a few debugging techniques I use.
Always start with a new installation of Uniform Server and make sure it is working before experimenting. Make small changes and then test, at lest you can pin point what lines caused the failure.
Vhost syntax check
Before starting the servers use Apache –S command to check your configuration files for syntax errors.
If you have not installed UniServer as a service running the above command directly from the bin folder will result in this error:
Apache -S Syntax error on line 69 of */Uniform Server/udrive/usr/local/apache2/conf/httpd.conf: ServerRoot must be a valid directory
The path is incorrect because you are running from the installation folder and not from a virtual drive as set in the configuration file. The easiest way to run the command is to create a batch file that sets up a virtual drive and then runs the command.
I tend to loose files hence I place the batch file in the root folder (top level) where I copied Uniform server. The file looks like this change the paths and drives to match your system set-up.
subst X: G:"A2_clean\Uniform Server\udrive"
To run, open a command prompt, type G: and then type uni.bat alternatively double click on file name (uni.bat)
SSL Session Cache
To secure each connection SSL uses a session key agreed between client and server this is stored in a cache for later use. When the client reconnects the session key is re-used speeding up the process of initial connection. Apache uses a number of processes so there is no guarantee that the same process will handle the client request without a session cache the session key would be lost between the processes. To avoid this, SSL Session Information is stored in a inter-process Session Cache to give its full name. This allows all the processes to have access to this handshake information. The session key is removed after a defined period hence a new session is generated when the same client re-connects.
Basically its best to use one it speeds up reconnection from the same user, you have a choice of three that I have listed below. Well RAM is faster than disk so we can rule out option 3, cyclic buffers strike me as using extra processor resources hence I went for option 1. If it fails to work on your PC try one of the other options.
|1||SSLSessionCache||shmht:logs/ssl_scache(512000)||uses a hash table to cache the SSL handshake information in shared memory|
|2||SSLSessionCache||shmcb:logs/ssl_scache(512000)||uses a cyclic buffer to cache the SSL handshake information in shared memory|
|3||SSLSessionCache||dbm:logs/ssl_scache||creates the cache as DBM hash file on the local disk|
|4||SSLSessionCacheTimeout||300||session key time out in seconds|
OpenSSL provides some very powerful tools one of the commands allows you to force reconnection to your secure server and check the cache is functioning correctly.
The -reconnect command forces the inbuilt client (s_client) to re-connect to the server five times using the same SSL session ID.
Run the openSSL –reconnect command as follows:
Note: Replace your domain name for unicenter.gotdns.org change the port as required.
Debug - Apache Config file
If you are faced with a sticky problem remember to check out the log files in folder *\Uniform Server\udrive\usr\local\apache2\logs
It is also worth changing LogLevel from warn to debug (about line 470) in httpd.conf
USB – Interesting
After updating Uniform Server I copied it straight to a USB stick along with the DynDNS updater folder.
After forwarding ports 80 and 443 on a friends machine ran DynDNS updater which to my surprise worked. I can only conclude that this little gem of a program is portable.
I ran Uniform Server, no problems one secure and one un-secure website as expected.