SSL Part 1: Debug VHost

From The Uniform Server Wiki
Jump to: navigation, search

MPG UniCenter

SSL Part 1 Extra: Home | Multi-Websites 1 | Multi-Websites 2 | Debug VHost

mod_ssl Debugging Virtual hosts
Uniform Server 3.5-Apollo


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.

Incremental changes

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"
cd usr\local\apache2\bin
Apache -S

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.

  Directive Value Comments
 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:

  1. Start you servers
  2. Open a command prompt and type the following:
  1. W:
  2. cd "home\admin\www\plugins\uc_mod_ssl\key_cert_gen"
  3. openssl s_client -connect -state -reconnect
  1. You will receive a long list of information what you are looking for in this list are five occurrences of the line:
  1. Reused, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
  2. Confirming that the cache is performing correctly.

Note: Replace your domain name for 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.


Uc small logo.gif Ric