I am running an Apache 2.4.18 server running under Ubuntu 16.04.1 LTS, only with PHP 7 and Exim 4 installed.

In the early morning the SSL handshake is extremely fast, about 200ms, but as time passes it increases (about 1 hour later), getting around 8s. If I reboot Apache, the SSL be fast again, but after a while it slows down again, returning to 8s and sometimes up to 30s.

I configured Apache ssh.conf (etc/apache2/mods-enabled) as follows:

    SSLRandomSeed startup builtin
    SSLRandomSeed startup file:/dev/urandom 512
    SSLRandomSeed connect builtin
    SSLRandomSeed connect file:/dev/urandom 512

    AddType application/x-x509-ca-cert .crt
    AddType application/x-pkcs7-crl .crl

    SSLPassPhraseDialog  exec:/usr/share/apache2/ask-for-passphrase

    SSLSessionCache         shmcb:${APACHE_RUN_DIR}/ssl_scache(512000)
    SSLSessionCacheTimeout  300


    SSLHonorCipherOrder on
    SSLProtocol all -SSLv3

    SSLCompression off
    SSLSessionTickets off

    SSLUseStapling on
    SSLStaplingResponderTimeout 5
    SSLStaplingReturnResponderErrors off
    SSLStaplingCache shmcb:/var/run/ocsp(128000)

In the VirtualHost settings I have set the following header:

    Header always set Strict-Transport-Security "max-age=15768000"

The server configuration is:

  • CPU: Intel Xeon E5-2650L 1.80Ghz (4 Core)
  • Memory: 7.8 GB
  • Load Average: 0.50

Using the server-status tool of Apache this appears.

When HTTPS is fast (11:00 AM after apache2 restart): SSL/TLS Session Cache Status

When HTTPS is slow: (11:04 AM): SSL/TLS Session Cache Status

This started to happen when we migrated from server. No new certifi cates were requested, the old SSLCertificateFile, SSLCertificateChainFile, and SSLCertificateKeyFile are still used.

What can be happening to slow it down and how can I fix it?

  • Solved using this article: Apache Optimization – Tom Jan 20 '17 at 16:11
  • If apache is running in prefork mode, you may have some luck reinstalling it to run in event mode. More detail here – S. Imp Mar 21 '18 at 2:47

If you're getting slow encryption, one thing that article didn't mention is /dev/random vs /dev/urandom. The /dev/random file can block waiting for entropy, and badly written encryption can hit it over and over. This can be especially pronounced in a virtual machine, as they don't have much in the way of normal entropy generating hardware. If this happens to you, just use /dev/urandom.

This is one of those things that probably isn't affecting you, but if it is, it can be a real problem and it's hard to diagnose without knowing to look for it.


  • 1
    The slow handshake was caused because the concurrent connections reached the value defined in MaxRequestWorkers. – Tom Jan 22 '17 at 4:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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