Plesk has native HTTP/2 support. Its deployment process requires careful planning, although rolling out HTTP/2 on Plesk is much easier compared to other control panels. This guide applies to a variety of operating systems. The steps provided here will work as long as you have the sufficient Plesk and OpenSSL versions. I will describe these requirements in “Step 1: Checking requirements”.
You should take into account that many browsers will only support HTTP/2 for your website if you use an SSL certificate. When an SSL certificate is not used, the content will not be served over HTTP/2. Luckily, there are many ways to obtain an SSL certificate. If you’re interested in getting a Let’s Encrypt certificate, check out this guide for creating one on Plesk: Let’s Encrypt on Plesk.
Even though there’s a good chance you’re able to enable HTTP/2 without your users or visitors noticing it (and without any downtime), you should announce this maintenance. In case your SSL cipher suite hasn’t been correctly configured there could be some downtime. Luckily, it’s very easy to revert the changes using Plesk’s built-in tool.
You should be absolutely sure that there has been no direct changes made to configuration files, as we will be overwriting some configuration files. There is nothing to worry about in case you have exclusively made changes using supported methods (in custom files), though.
If possible, you should spin up another Vultr cloud server with a plain Plesk installation and execute the command(s) below. Then, based on its success (or failure), you can take steps to instantly debug and/or resolve any issues that might arise in future HTTP/2 deployments on production servers currently in use.
Enabling HTTP/2
Step 1: Checking requirements
Out-of-the-box, you can enable HTTP/2 support for the reverse proxy that which Plesk was deployed. In case you’re not sure if your server uses a reverse proxy, you should check the “Service Monitor”. If you see both Apache and Nginx listed there, it’s safe to assume that your installation is currently using a reverse proxy. If you only see Apache or only Nginx, you’ll most likely be using a single web server.
In the core, there is one specific requirement that’s absolutely required for HTTP/2 to work, which is an OpenSSL version with ALPN support.
However, if you have Plesk version 12.5.30 or greater installed on CentOS / RHEL 7, Ubuntu 14.04, Debian 8 or greater, Nginx is deployed with ALPN support out-of-the-box.
If you have an older Plesk or operating system version, you could upgrade some packages. However, I do not support or document this. These versions and operating systems are very old, and best practice would be to update them. Consider the security risks of using outdated software as well.
There is no document explicitly stating which operating systems and versions are compatible with HTTP/2 on Plesk; however, if you use the newest version (at the time this guide was published), you should meet the requirements. You can safely assume that older operating systems such as CentOS / RHEL 5 will not be compatible.
Aside from the OpenSSL version requirements, note that Apache does not necessarily need to be compatible with HTTP/2 as well. HTTP/2 support for Apache has been available since version 2.4.17, but in case you make use of a reverse proxy (which is the default setting in Plesk) only the Nginx version has to suffice. The backend server, Apache, would not have to be compatible. You can consult the “Service Manager” in Plesk to make sure you’re using a reverse proxy. When Nginx is listed there, it’s safe to assume Apache and Nginx are installed as a reverse proxy setup where Nginx acts as the frontend server.
The following command shows whether or not Nginx has been activated.
/usr/local/psa/admin/bin/nginxmng -s
For OpenSSL, you should have version 1.0.1 at least. You can check using the following command:
rpm -qa | grep openssl
This will print a version similar to:
openssl-1.0.1e-42.el6_7.4.x86_64
If the OpenSSL version is not equal to or greater than 1.0.1, you should update your operating system. Plesk deployed on newer operating systems will make use of OpenSSL 1.0.1 out of the box.
Step 2: Enabling HTTP/2 in Plesk
Depending on the operating system used, enable HTTP/2 using the http2_pref
tool. This command should be executed as root.
Enabling HTTP/2 on CentOS / RHEL
Execute: /usr/local/psa/bin/http2_pref enable
Enabling HTTP/2 on Ubuntu / Debian
Execute: /opt/psa/bin/http2_pref enable
Step 3: Improve cipher suite
Using a good cipher suite is incredibly important for security. Supporting outdated protocols will effectively defeat the effect of your security measures. Make sure to adjust the available protocols and available TLS versions using the built-in Plesk tool sslmng
.
For example, enabling the following ciphers and TLS versions will ensure compatibility with HTTP/2. If you’re rather unsure of the ciphers and versions you should enable, then stick to the following settings:
plesk sbin sslmng --services=nginx --custom --ciphers="EECDH+AESGCM+AES128:EECDH+AESGCM+AES256:EECDH+CHACHA20:EDH+AESGCM+AES128:EDH+AESGCM+AES256:EDH+CHACHA20" --protocols="TLSv1 TLSv1.1 TLSv1.2"
This command modifies /etc/nginx/conf.d/ssl.conf
. You can modify this file directly, but using the command listed above will persist changes across Plesk updates.
In order to get “Perfect forward secrecy” using another cipher suite, you can try the following ciphers:
ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS
There are many cipher suites available, and you should pick the one that fits your needs best. You should consult a website such as Cipherli.st in order to gather a cipher suite that fits your needs. By specifying it in the sslmng
tool, the cipher suite will be used instantly.
To check the TLS support of your browser as a client, use the Qualys SSL tool. When you are not allowing sufficient ciphers or TLS versions, some websites may become unreachable.
Step 4: Checking HTTP/2 compatibility
After enabling HTTP/2, you should check if your websites and web server can be reached over HTTP/2. There’s a very handy web-based tool for this: HTTP/2 Test.
In order to get an accurate result, make sure you’ve disabled all reverse proxies located in front of your server. For example, if you’re utilizing a CDN that doesn’t support HTTP/2, the testing tool will return your website doesn’t support HTTP/2 even if it’s successfully enabled on the server level. Just like the other way around: if you have a reverse proxy such as Cloudflare in front of your website (which supports HTTP/2) the tool will always return HTTP/2 as being enabled and working, regardless of its functionality on the server level.
If some browsers are refusing to load your website(s) or serve any content from your web server after enabling HTTP/2, you should analyze your SSL setup using Qualys’ SSL tool.
(Optional) Reverting HTTP/2 configuration
If needed, if you need time to debug, you can (temporarily) disable HTTP/2 simply by executing the command below. Once you want to re-enable HTTP/2, simply execute the command for activating it and retry reaching any of your websites. There is no way to enable or disable HTTP/2 for specific domains or websites; it’s a server-wide setting.
Disabling HTTP/2 on CentOS / RHEL
Execute: /usr/local/psa/bin/http2_pref disable
Disabling HTTP/2 on Ubuntu / Debian
Execute: /opt/psa/bin/http2_pref disable
Troubleshooting
Considering the many components of a server involved in enabling HTTP/2, in some cases you might need to troubleshoot when websites are not loading correctly or not at all after activating HTTP/2 support.
Note: make sure not to disable HTTP/2 support using the http2_pref
tool when following these steps.
Check requirements
First, make sure you meet the requirements outlined at the beginning of this article.
Recreate Nginx configuration
If you meet the requirements for HTTP/2, you can attempt to recreate the Nginx configuration files. You should know that this will remove any custom configurations, so create a backup of the Nginx configuration directory beforehand. As the configuration files can be spread throughout the server, it’s better to simply make a snapshot or take a backup. Then, execute this command:
/usr/local/psa/admin/bin/httpdmng --reconfigure-all
Recheck cipher suite
If that doesn’t have any effect either, most likely, the cipher suite is to blame. Execute the following command again:
plesk sbin sslmng --services=nginx --custom --ciphers="EECDH+AESGCM+AES128:EECDH+AESGCM+AES256:EECDH+CHACHA20:EDH+AESGCM+AES128:EDH+AESGCM+AES256:EDH+CHACHA20" --protocols="TLSv1 TLSv1.1 TLSv1.2"
Error in panel.ini
Make sure the file /usr/local/psa/admin/conf/panel.ini
contains the following content:
[webserver]
nginxHttp2 = true
You could check if the file contains this quickly by executing: cat /usr/local/psa/admin/conf/panel.ini | grep nginxHttp2
Does this command return nothing? Then most likely, the file is read-only, for example due to a chattr
attribute. It may have been added when the http2_pref
command (to enable HTTP/2) was executed.
Check if SSL is used
When a website does not use SSL, it will fall back to HTTP/1.1. Only websites making use of SSL will be served using HTTP/2. Make sure you’re not enforcing HTTP/2 locally in all cases, because that won’t work and is not a server-side problem.
Other options
Should this not work either, you should consult a Plesk expert, for example on the Plesk forums. In many cases, the above steps will fix most issues, though.
One last measure you can take is simply rebooting the server. In some strange cases this has fixed issues out of the blue. However, you should always be able to pinpoint issues to prevent them from (suddenly) happening again.
That concludes my guide, thank you for reading.
Want to contribute?
You could earn up to $300 by adding new articles
Suggest an update
Request an article