HTTP/2 & Let’s Encrypt for WordPress

Let's Encrypt & HTTP/2 for WordPress

Our web blog is now meeting the latest security standards and making it HTTP2-ready is easier than you think. Here’s how we switched our web blog ( https://devblog.plesk.com ) running on Plesk + NGINX to HTTPS and made it HTTP/2-ready with a free, SSL certificate from Let’s Encrypt. Before we get into the details a few things to start with.

Protocol enhancements like SPDY and HTTP/2 have narrowed the performance gap between encrypted and un-encrypted web traffic, with encrypted HTTP/2 outperforming un-encrypted HTTP/1.1 in some cases. Even more importantly, encryption is now kind of mandatory as Google announced that HTTPS is used as a ranking signal in search results, with HTTPS-enabled sites ranking above their plaintext counterparts. ‘Yes, HTTP/2 is awesome,’ I hear you saying, ‘but it requires HTTPS which, in turn, requires an SSL certificate – and those things cost money, you know?’ Well, here comes the sales pitch: Plesk, together with Let’s Encrypt, makes HTTPS setup a breeze and brings you a faster Web with HTTP/2.

Let’s see how we did it.

HTTPS & Let’s Encrypt

First,  issued a free trusted certificate from Let’s Encrypt with automatic renewal and set it up for devblog.plesk.com, hosted on Plesk 12.5.

There are many manuals available online talking about how to install an SSL certificate on Linux so you might have already seen rows upon rows of command line calls, lists of changes to configuration files, and even instructions for building additional utilities. Well, we decided to make our life easier and just used the Plesk “Let’s encrypt” extension that enables Plesk users to issue and install certificates with auto-renewal functionality in the Plesk UI with just a few clicks.

 

You can find the details in one of our previous blog posts here: https://www.plesk.com/2015/12/lets-encrypt-plesk/. After a few clicks we were done and had a free, trusted SSL certificate installed on devblog.plesk.com. Let’s enable HTTP/2 next.

HTTP/2

HTTP/2 is the second major version of the HTTP network protocol used by the world wide web.

Ratified in May 2015, HTTP/2 was created to address some significant performance problems with HTTP 1.1 in the modern web era.

  •  HTTP/2 is supported in NGINX web server starting from version 1.9.5.
  •  Currently, HTTP/2 is supported by all major web browsers.
  •  Your sites do not require any changes to get the HTTP/2 advantages.

Now, HTTP/2 is available out-of-the-box for all Plesk 12.5 customers!

Sounds good, doesn’t it? Let’s move on.

First, you need to make sure that the latest Plesk update, Plesk 12.5.30 Update#28, is installed. We don’t, because  we have auto-updates enabled on the server and  recommend you enable them too. Then, we logged in to the server via SSH as root, and ran the following command line utility:

#/usr/local/psa/bin/http2_pref enable

That’s all it took to empower our HTTPS sites with HTTP/2! If you’re not sure about your websites go to https://tools.keycdn.com/http2-test to check for HTTP/2 compliance. 

 

Detailed User Instructions for enabling HTTP/2 in Plesk can be found here: https://kb.plesk.com/en/128733

If you’d like to get a second opinion, you are welcome to use the “HTTP/2 and SPDY indicator” extension for Google Chrome, found here.

WordPress

We have now secured the connection between the server and the website. Next step is to configure our WordPress site to only use HTTPS. This required a re-configuration of WordPress settings to replace all http:// links inside the WordPress database with  https://. If you fail to do so you will continue to receive “Mixed content warnings” for previously uploaded content:

  1. Go to the WordPress administrative interface and change both “WordPress Address” and “Site Address” to use https://
  2. Set-up a redirect for all http:// requests to https:// for the respective website.

Screen Shot 2016-04-15 at 11.14.43

Next step was to change the links inside the WordPress database. There are a lot of possible ways to do it, starting from direct SQL queries to wp-cli. We decided to do it via the WordPress interface using the “Better Search & replace” plugin, which can either be installed from the Plesk interface or from the WordPress Administrative interface.

This plugin helped us to find all matches for “https://devblog.plesk.com” in the WordPress database and replace it with “https://devblog.plesk.com“. This plug-in allows you to only find but also find and replace if you with to do so.

Last but not least we had to redirect all http:// requests to the https:// counterpart of our blog using the Plesk interface. We went to Websites & Domains , selected devblog.plesk.com, and then “Apache and nginx Settings”

to set-up the redirect in the “Additional nginx directives” section, like this:

if ($scheme = http) {

return 301 https://$server_name$request_uri;

}

 

That’s it! Now, all browser requests to https://devblog.plesk.com are redirected with the 301 code to https://devblog.plesk.com, and that’s just what we wanted.

On a separate note…. .

Load speed test with https://www.webpagetest.org/ shows that the transition from non-SSL HTTP to HTTPS + HTTP/2 has little impact to the site load speed.

In return, we now have a secure connection with a nice green trusted SSL certificate,  including better indexing from Google for free 🙂

By the way, we did not stop with the DevBlog – actually, the new Plesk website (https://www.plesk.com – check it out!) was built on Plesk 12.5 [+ WordPress Toolkit] + WordPress.

Have a nice day 🙂

What is the problem with “ß”

Our German customers frequently ask to start supporting the German “ß” character in Plesk. The character is also known as “sharp-s” or “Eszett”.  So why don’t we just fix this problem?

Well, the answer is that the problem is not in Plesk and is not at the server-side at all. As you may know, international (in fact, national) characters were enabled in domain names with IDNA 2003 protocol, which introduced a procedure converting national names (German, Cyrillic, Chinese, etc) into something looking like xn--fa-hia.com. The idea was that national domain names would  be equally converted into such an ASCII string on the client side (browser) and on the server side (DNS and Web servers), thus all existing Internet protocols  would easily pass this converted ASCII string without any modification. Cool? Exactly! Except that original IDNA 2003 protocol didn’t support several characters properly and one of those was “ß”.  It was interpreted as mere ‘ss’. So “faß.de” domain (for example) was processed as “fass.de”, ignoring the national character.

Continue reading

Why Plesk 11.5 changes UI?

For every new software release, barely there would be anything more painful than changes in the user interface. Plesk is known for changing the UI with almost every major release. Some people like the changes, some people don’t , but these changes are always dictated by the industry. We constantly learn from our customers for what is good and what is not and, in Plesk 11.5, we decided to improve the UI one more time.  Yes, again. And let us explain why.

Continue reading

How Plesk 11.5 solves Email Users problem

Since Plesk 10.0 and prior to Plesk 11.5 email user management has become greatly complicated by the need to operate through User account. While Users concept gave more power and flexibility, we recognised the simplicity of basic functions is equally important. So in Plesk 11.5 the one can still utilize “Users” to delegate some web mastering functions, but for mail users a simple solution will be suggested.

Continue reading

Meet plesk command-line hub (Linux)

Plesk 11.5 introduces s an easier way for Linux server admin to manage and troubleshoot Plesk. That is “plesk command-line hub“. The hub consolidates and shortcuts most of typical operations over Plesk. Lets briefly overview how it can help:

Continue reading