OLS is an open source derivative of the LiteSpeed Web Server (LSWS), which delivers most many of the key features, including the high performance LiteSpeed Cache (LSCache). Whilst it can’t read  Apache configuration files like its bigger brother LSWS (and thus can’t be used with a hosting control panel like cPanel or Plesk), it’s great for working with a handful of sites configured manually

Whilst the LSCWP plugin has a lot of useful features which can be used even without the LSCache from OLS/LSWS, the main selling point is the integration with LSCache to deliver blazing fast page load times along with massive scalability under load.

I recently ran into a bizarre issue where the cache just completely stopped working for no obvious reason, which led to hours of pulling apart WordPress and OLS to try and work out why.

Aside from pages loading very slowly, the main clue was that the X-Litespeed-Cache header was completely missing, although the X-Litespeed-Cache-Control header was present as normal. This would normally mean some kind of issue with the cache storage location (/usr/local/lsws/cachedata/ by default, unless override by the storagePath configuration option in the cache module settings).
I couldn’t see any issues with the cache storage location, but tried adjusting it elsewhere anyway without any luck.

I verified that all of the settings for the cache module were configured as per those listed on the OLS wiki and eventually out of frustration deleted the whole cache module definition from the server configuration and added it back, at which point the cache started working again!

I’ve absolutely no idea why removing and re-adding the exact same configuration should make any difference whatsoever, but I have now verified identical behaviour on two different servers with completely independent configurations.

The post OpenLiteSpeed WordPress cache mysteriously not working first appeared on Spheron1.

In order to enable OCSP stapling, first we need to construct the intermediate certificate chain which OpenLiteSpeed will use to cryptographically verify the response from the CA’s OCSP server.

Take the COMODORSADomainValidationSecureServerCA.crt and COMODORSAAddTrustCA.crt files provided by Comodo when your certificate was issued and concatenate them into a single file

cat COMODORSADomainValidationSecureServerCA.crt COMODORSAAddTrustCA.crt > /etc/pki/tls/certs/PositiveSSL_chain.pem

Now log in to the OpenLiteSpeed WebAdmin console and perform the following steps:

1. Click on “Configuration” on the navigation bar and then select “Listeners” from the drop down menu
2. Click “View/Edit” on your HTTPS listener
3. Click on the “SSL” tab
4. Click “Edit” on the “OCSP Stapling” section
5. Set “Enable OCSP Stapling” to “Yes”
6. Set “OCSP Responder” to “http://ocsp.comodoca.com”
7. Set “OCSP CA Certificates” to the file containing the chained intermediate certificates created earlier (“/etc/pki/tls/certs/PositiveSSL_chain.pem” in my case).
8. Click “Save”
9. Perform a “Graceful Restart” of the OpenLiteSpeed server

If all has gone well, you now have OCSP stapling working. Click on “Actions” on the navigation bar and then select “Server Log Viewer” from the drop down menu or look in /usr/local/lsws/logs/error.log and check that you have a line saying “Enable OCSP Stapling successful!”

You can also use the excellent SSL Server Test by Qualys’ SSL Labs at to check many attributes of your server’s SSL setup, including whether or not OCSP stapling is working.

The post OpenLiteSpeed OCSP stapling with Comodo PositiveSSL first appeared on Spheron1.