Thoughts on intermediate compatibile SSL with Let's Encrypt certificates

Let’s Encrypt is a free, automated, and open certificate authority (CA), run for the public’s benefit.The key principles behind Let’s Encrypt are:

The key principles behind Let’s Encrypt are Free: Anyone who owns a domain name can use Let’s Encrypt to obtain a trusted certificate at zero cost.

  • Free: Anyone who owns a domain name can use Let’s Encrypt to obtain a trusted certificate at zero cost.
  • Automatic: Software running on a web server can interact with Let’s Encrypt to painlessly obtain a certificate, securely configure it for use, and automatically take care of renewal.
  • Secure: Let’s Encrypt will serve as a platform for advancing TLS security best practices, both on the CA side and by helping site operators properly secure their servers.
  • Transparent: All certificates issued or revoked will be publicly recorded and available for anyone to inspect.
  • Open: The automatic issuance and renewal protocol will be published as an open standard that others can adopt.
  • Cooperative: Much like the underlying Internet protocols themselves, Let’s Encrypt is a joint effort to benefit the community, beyond the control of any one organization.


First, we have to mention about some dark sides of Let's Encrypt service. However great the idea of free public and open certificate authority is, it brings also many troubles for us. Developers have tried to make the system of obtaining certificates as simple as possible, but it still requires a higher skill of server administering. Therefore, many of developers like the one from ISPConfig ( have implemented this solution directly into their. This brings people more effective deployment and supervision over the whole system much easier and flexible.

Real complication

Many people have decided to implement Let's Encrypt into their production sites. I find this still a very bad idea to be done without being very (but really very) careful. Let's Encrypt brings you freedom but also limits you in using the certificate with SHA-256 RSA Encryption. Support for SHA-256 has improved over the last few years. Most browsers, platforms, mail clients and mobile devices already support SHA-256. However, some older operating systems such as Windows XP pre-SP3 do not support SHA-256 encryption. Many organizations will be able to convert to SHA-256 without running into user experience issues, and many may want to encourage users running older, less secure systems to upgrade.

In this tutorial, we are going to deal with this incompatibility in a simple, but still nasty way.


  • Apache version 2.4 and higher
  • OpenSSL version 1.0.1e and higher
  • Apache mod_rewrite enabled

The whole idea

As mentioned before, there are still devices incompatible with SHA-256 signature in the Internet. When I was forced to deploy an SSL to some websites, I had to decide between two options:

  1. Using Let's Encrypt having it for free but not for all.
  2. Buying a certificate with 128 bit signature.

Well, still the option no. 1 was the only way as it was promised to customer long days ago (:No more theory:

No more theory

I hope I have explained the needed and now we can deal with the unsupported viewers of our website. There are many people using Windows XP machines with SP2 and lower (Yes, there are still plenty of them). So we have to filter these people.

In your “/etc/apache2/sites-available/” add following on the end of the file:

RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} !(NT\ 5) [NC]
RewriteRule ^(.*) https:// [R]

RewriteCond gets a string from http header of the guest accessing your page. You can simply check yours and find more information here:

The condition we used tells us something like “if string doesn't contain 'NT 5'” then RewriteRule executes/applies the rule of redirecting [R] to https variant of your domain, NT 5 is an OS version string for Windows XP devices.If you don't use this redirection, incompatible users won't be able to access your https website.

If you don't use this redirection, incompatible users won't be able to access your https website.I have to warn you about this solution being not 100% perfect as some of

I have to warn you about this solution being not 100% perfect as some of guests don't have to provide you relevant or real information. I have worked with AWstats to figure out what rate of unknown systems are accessing my page and it is about 1.3%, so pretty few requests. If you want to deal with unknown operating systems to ensure their compatibility, you can add unknown in the condition as well (RewriteCond %{HTTP_USER_AGENT} !(NT\ 5|unknown) [NC]).


After successfully “non-redirecting” your incompatible visitors (keeping them in http insecure world) you can focus on https side.

HTTPS configuration

Now we assume you have already assigned the certificate to your web server and also enabled it.
In your vhost config file again, add following:

SSLProtocol All -SSLv2 -SSLv3
SSLCompression off
SSLHonorCipherOrder On

The CipherSuite used here is a bit longer than usual. It's for better compatibility. You can get your own from: or

I must again mention, you won’t ever get a perfect configuration to meet the high security policy and also compatibility. You should find a compromise.

After using these settings, you can test your server configuration and compatibility at:

You are going to find a long list of compatible devices and the incompatible ones, also some more information to point you for your own “perfect” solution.

Share this page:

2 Comment(s)