When configuring SSL session caching in Apache 2.2, many administrators struggle to verify whether the cache is truly effective, especially in concurrent connection scenarios. The standard tools like openssl s_client -reconnect only test sequential session reuse, leaving the more complex concurrent case untested.

# Current SSL cache configuration in ssl.conf
SSLSessionCache shm:/var/www/apache-ssl-cache/ssl_scache(512000)
SSLSessionCacheTimeout 300
SSLMutex file:/var/www/apache-ssl-cache/ssl_mutex

The log entries you're seeing are actually normal and don't necessarily indicate problems with SSL session caching:

• (70007)The timeout specified has expired - Typically occurs during normal connection timeouts
• (70014)End of file found - Often happens when clients abruptly close connections
• PRNG seeding messages are initialization events, not caching issues

To truly verify concurrent SSL session caching, we need a more sophisticated approach than basic OpenSSL tests:

1. Initial Session Setup

openssl s_client -connect yourdomain.com:443 -reconnect -no_ticket -sess_out session.txt

2. Concurrent Session Test

Use this Python script to simulate concurrent connections:

import socket, ssl, threading

def test_ssl_session():
    context = ssl.create_default_context()
    context.load_verify_locations('/etc/ssl/certs/ca-certificates.crt')
    with socket.create_connection(('yourdomain.com', 443)) as sock:
        with context.wrap_socket(sock, server_hostname='yourdomain.com') as ssock:
            print(f"Session reused: {ssock.session_reused}")

threads = [threading.Thread(target=test_ssl_session) for _ in range(5)]
for t in threads: t.start()
for t in threads: t.join()

Enable detailed SSL logging in Apache:

LogLevel info ssl:warn
CustomLog logs/ssl_request_log "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"

Check shared memory cache statistics:

# Install apache2-utils if needed
sudo apt-get install apache2-utils

# Check shared memory segments
ipcs -m

# Detailed SSL cache stats
apache2ctl -t -D DUMP_MODULES | grep ssl
apache2ctl -M | grep ssl

• Verify the shared memory segment has proper permissions
• Check that the mutex file exists and is writable
• Monitor memory usage of the cache segment
• Consider using SSLSessionCache dbm:/path/to/cache if shared memory proves problematic

For high-traffic servers, these additional parameters might help:

SSLSessionCacheTimeout 600
SSLStrictSNIVHostCheck off
SSLRandomSeed startup file:/dev/urandom 1024
SSLRandomSeed connect builtin

When working with Apache 2.2's SSL implementation, session caching plays a crucial role in performance optimization. The configuration you've shared using shared memory (shm) is correct in principle:

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

The log entries you're seeing are actually normal SSL negotiation behaviors and don't necessarily indicate session caching failures:

[info] [client x.x.x.x] (70007)The timeout specified has expired: SSL input filter read failed.
[info] [client x.x.x.x] (70014)End of file found: SSL input filter read failed.

These typically occur when clients abort connections prematurely or when network timeouts happen.

While openssl s_client -reconnect is useful for basic testing, it doesn't cover the concurrent usage scenario you've correctly identified. Here's a more comprehensive test approach:

# First connection to establish session
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com > session1.log 2>&1

# Extract the session ID from first connection
SESSION_ID=$(grep 'Session-ID:' session1.log | awk '{print $2}')

# Second connection attempt to verify caching
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com -sess_in session1.sess > session2.log 2>&1

To verify if the shared memory cache is being utilized across processes:

# Check shared memory segments
ipcs -m

# Detailed Apache status with SSL information
apachectl fullstatus | grep -i ssl

For true concurrent testing, you'll need multiple parallel connections. This bash snippet helps test concurrency:

# Create 5 parallel connections reusing sessions
for i in {1..5}; do
  (openssl s_client -connect yourdomain.com:443 -reconnect 2>&1 | tee output_$i.log) &
done
wait

# Check results
grep -h 'Reused' output_*.log

1. Monitor mod_status output for SSL session cache statistics
2. Check shared memory utilization with ipcs -m
3. Verify with strace to see if Apache processes access the shm file
4. Enable higher debug levels temporarily in SSL logs

Consider these adjustments for better performance:

# Increase cache size if needed
SSLSessionCache shm:/var/www/apache-ssl-cache/ssl_scache(1024000)

# Adjust timeout based on your traffic patterns
SSLSessionCacheTimeout 600

# Consider using pthread mutex for better performance
SSLMutex pthread

The most reliable indicator is comparing full SSL handshakes vs resumed sessions in your access logs. A properly working cache should show significant reduction in full handshakes after initial connections.