Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We have Apache 2.2.22 running on Ubuntu 12.04.

SSL is configured and enabled, with these directives in /etc/apache2/mods-enabled/ssl.conf:

SSLSessionCache shm:/var/www/apache-ssl-cache/ssl_scache(512000)
SSLSessionCacheTimeout  300
SSLMutex file:/var/www/apache-ssl-cache/ssl_mutex

SSL seems to work. We can access the site through HTTPS, even in IE8 on Windows XP. However, we are not sure if SSL Session Cache is actually working correctly.

We see a lot of these INFO-level messages in the log of our virtual host:

[info] [client <censored>] (70007)The timeout specified has expired: SSL input filter read failed.


[info] [client <censored>] (70014)End of file found: SSL input filter read failed.


[info] [client <censored>] (70014)End of file found: SSL handshake interrupted by system [Hint: Stop button pressed in browser?!]

PRNG seeding also seems to happen quite often. Unfortunately it seems impossible to reliably tell for which forked apache child process the PRNG is being seeded:

[info] Seeding PRNG with 656 bytes of entropy

So are these messages indicative of SSL session cache not working (across forked apache child processes)?


I have found various sites that mention the use of openssl s_client -reconnect or gnutls-cli -Vr to test SSL session caching. I believe that they only answer part of the question: because both programs disconnect then reconnect, they only confirm that the SSL session is cached and can be reused sequentially, but they don't check if the cached SSL session can be used concurrently by multiple forked servers, to the same client. This is actually a typical usage scenario with modern browsers when pulling resources from an HTTPS website).

In order to check that the cached SSL session can be used concurrently, the first test connection must not be closed before opening the next one using the same SSL session ID/key. Unfortunately, neither utility seems to have such an option.

share|improve this question

You can check for certain by using one of the SSL analysis sites (e.g. Qualys' SSL server test). Look for the result of the 'session resumption test': if it says 'Yes', your session caching is working.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.