How to Activate HTTP/2 Support on DirectAdmin (CentOS)

HTTP/2 is the newest version of the HTTP protocol, based off SPDY. Its development was initiated by Google and HTTP/2 is largely based on the codebase and concepts of SPDY.

SPDY has now been deprecated and worldwide adoption for HTTP/2 is in progress. Many hosting companies have already provided support for HTTP/2 due to its added speed.

At the time of writing, DirectAdmin does not provide a one-click way to enable HTTP/2. However, there are multiple ways to achieve HTTP/2 support. The method outlined below has proven to be the most robust and stable approach.

Several components need to be updated in order for HTTP/2 to take effect. Because of this, I strongly advise you to take a snapshot. If possible, follow this guide on a completely new server.

This guide consists of two parts: enabling HTTP/2 support in the web server (Apache) for clients (visitors) and the activation of HTTP/2 in cURL. Enabling HTTP v2 for cURL forces cURL requests originating from your server to make use of HTTP/2 for its destination servers, if possible.

Key points

• It’s not required to update both Apache and cURL to use HTTP/2. It’s fine if you follow either guides, as they function separately from each other.
• There have been a few strange cases in which Apache and HTTP/2 seem to function fine, but loading succeeds on ”random” browsers and sites become unreachable (timeout) on others. Simply reverting to the original Apache configuration will fix this, as Apache will not know about HTTP/2 and not attempt to serve content over it.
• Always take a backup or make a snapshot in advance. Enabling HTTP/2 can be a relatively fragile process so it’s important to be able to revert changes if needed.
• Recompiling software can always cause slight downtime. In some cases, this is under a minute, but there’s no way to tell exactly. You should be prepared for some downtime at the very least.
• You need root access to the server for this guide. If you do not have the ability to elevate your permissions level to root, you should contact the server administrator to enable HTTP/2 on the server.

HTTP/2 and SSL

Although it is not a technical requirement from HTTP/2 itself, in most cases you will need an SSL certificate in order to use HTTP/2. As mentioned, HTTP/2 does not technically require this, but many browsers (Safari, Chrome, Firefox, etc.) have created this standard. Content will not be served over HTTP/2 when a page is loaded without SSL using these browsers. Considering most users use these browsers (and others) which also participate in this standard, you should use an SSL certificate.

If you’re looking for a free SSL certificate, you should take a look at one of our Let’s Encrypt guides:

Recommended: Installing Let’s Encrypt on DirectAdmin

Alternative control panels:

• Let’s Encrypt on Plesk
• Let’s Encrypt on cPanel

General guides:

• Setup LetsEncrypt On Linux
• Setup Let’s Encrypt With Apache on Ubuntu 14.04
• Setup Let’s Encrypt With Apache on Ubuntu 16.04

FAQ

Does this guide document the installation of Brotli?

No, there is no method outlined for installing Brotli alongside HTTP/2 in this article.

Compiling fails for no reason, and I have followed the exact steps outlined in this article. How do I resolve this?

Even though there are many possible reasons for this, taking into account different environments and the like, possibly, your locale settings are not correct. Try putting LC_ALL=C in front of your commands, so the command for recompiling Apache would look like this for example: LC_ALL=C ./build apache
Don’t forget the space between LC_ALL=C and the command!

Will I lose any data?

In case you are currently using a reverse proxy setup, for example with Apache and Nginx, you should revert it back to Apache, in which case you would indeed lose your Nginx configuration files. In case you’ve made custom VirtualHost configurations (be it through the command line or DirectAdmin itself) you should alter these on a per domain basis so the Apache versions will stay active. You will not lose any data in regards to user data, website content, databases, etc.

Will these custom versions stop me from updating packages and software in the future?

Generally, there’s no need to worry about this. Taking into account DirectAdmin’s modular setup (and therefore CustomBuild’s) you should be able to downgrade or upgrade to other software versions in the future without any problems. Though you should document the changes in case an alternative upgrade path is required in the future, there should be no need to worry about incompatibility versions with new software releases.

DirectAdmin does not offer HTTP/2 out of the box; surely that means it’s not compatible or they have their reasons not to be. Why is this workaround required?

The methods for installing and enabling HTTP/2 described below are not so much workarounds, but solely mere package updates and configuration changes. Due to DirectAdmin’s modular setup, these changes are perfectly fine and should not cause issues or other trouble.
It’s hard to determine why DirectAdmin doesn’t support this out of the box, given that the authors have not given an explanation for this. However, a pretty solid conclusion is that DirectAdmin makes use of the version packages by the operating system. These are generally not as up-to-date as the packages below.
There is nothing wrong with HTTP/2, the technology itself, and its compatibility. Just like many other technologies it can take some time to natively adapt.

What are the possible risks of activating HTTP/2 with Apache?

In the activation of HTTP/2 (consisting of an upgrade and configuration process) there are many variables that can turn out to be non-standard. The biggest risk lies in human error, however. Take a snapshot beforehand, make sure to announce the maintenance to your users (if there are any on the server aside from yourself) and be careful. Furthermore, don’t copy and paste the commands without thinking about what they do first.

I highly recommend temporarily spinning up a separate Vultr cloud instance with DirectAdmin and to walk through the steps. Should something go wrong on a ‘fresh’ install, you’ll know where and how to debug it so you don’t have to in a production environment.

Part 1: Apache (web server)

If you are currently making use of a reverse proxy, you should switch back to an Apache-only environment. That is because HTTP/2 is very hard to debug if something goes wrong. By being able to make use of Apache’s integrated HTTP/2 functionality, you are effectively able to eliminate a very large part of trouble.

Step 1: Upgrading OpenSSL

In many cases, your OpenSSL version is not compatible with ALPN, which is required for HTTP/2. Therefore, let’s enable ALPN by updating OpenSSL.

First off, let’s make sure your OpenSSL version is not compatible by executing:

openssl version

If your OpenSSL version is less than 1.1.0f, execute the following as root. Otherwise, skip to step 2.

cd ~
wget ftp://ftp.openssl.org/source/openssl-1.1.0f.tar.gz
tar xzf openssl-1.1.0f.tar.gz
cd openssl-1.1.0f
./config --prefix=/usr/local/lib_http2 no-ssl2 no-ssl3 zlib-dynamic -fPIC
make depend
make install

Step 2: Installing nghttp2

In order for HTTP/2 to work, we need to install nghttp2. Nghttp2 is an implementation of HTTP/2 (and HPACK) in C. Nghttp2 is a combined version of the HTTP/2 client, server and proxy in C.

To install nghttp2, execute the following commands. Luckily, nghttp2 can be built straight from CustomBuild.

cd /usr/local/directadmin/custombuild
./build update
./build nghttp2

Step 3: Enabling HTTP/2 in Apache

We need to alter a few values in the Apache configuration file in order for it to make use of HTTP/2. When the web server is not getting instructions to use an alternative HTTP version, it won’t make use of it. Therefore we need to add HTTP/2 to the configuration file.

For these changes to take effect, a rebuild of Apache through CustomBuild is necessary. As the parameters and values used by CustomBuild when building software are determined in a dedicated configuration file, best practice is to put these changes in a dedicated custom configuration file.

Note: if you do not put these changes in a custom file, they will most likely be overwritten and your setup will break. Please follow the instructions outlined below.

Execute the following commands in order to create the file and prefill it with the default values so we can alter it afterwards:

mkdir -p /usr/local/directadmin/custombuild/custom/ap2
cp -p /usr/local/directadmin/custombuild/configure/ap2/configure.apache /usr/local/directadmin/custombuild/custom/ap2/configure.apache

As of now, we have a custom file which is identical to the default configuration file for Apache used by CustomBuild. We have to alter the /usr/local/directadmin/custombuild/custom/ap2/configure.apache file by replacing the following string:

"--with-ssl=/usr" /

with:

"--enable-http2" /
"--enable-ssl-staticlib-deps" /
"--with-ssl=/usr/local/lib_http2" /

Note: Make sure that there is no white space after any of the backslashes. Excess whitespace there will cause the build to break.

Next, rebuild Apache. CustomBuild will use the custom configuration file you have just created:

./build apache

Step 4: Altering the Apache configuration

Apache has now been rebuilt including the necessary modules and settings for HTTP/2. That means we now have an Apache version installed on our server with support for HTTP/2, but we need to tell Apache to actually use it first.

Add the following lines in /etc/httpd/conf/extra/httpd-includes.conf:

ProtocolsHonorOrder On
Protocols h2 h2c http/1.1

Save these changes and rewrite the configuration files so they’re persistent across rebuilds:

cd /usr/local/directadmin/custombuild
./build rewrite_confs

HTTP/2 should now be active on your web (Apache) server.

Step 5: Reboot the server

Reboot the server to make sure that our changes persist across reboots. Please reboot the server though the Vultr control panel or by executing the reboot command.

Step 6: Test HTTP/2

HTTP/2’s functionality can easily be tested by using the following tool: HTTP/2 Test

Considering HTTP/2 is server-specific and cannot be restricted to a specific pair of domains or websites, entering any domain name pointing to the server or even the server IP address should work.

The test will tell you if it’s able to reach the web server through HTTP/2. In case the tool says HTTP/2 is activated on your server, DirectAdmin websites can now be reached through either HTTP/1.1 or HTTP/2. In case HTTP/2 support is not available for the client (visitor) its browser will fall back to HTTP/1.1.

In case the tool cannot reach your web server through HTTP/2, follow above steps again. Generally (as the above steps don’t actively overwrite anything) this won’t damage or break your setup.

Part 2: cURL

I recommend updating cURL so it’s able to reach servers with HTTP/2 support. In case a server does not support HTTP/2, it will fall back to HTTP/1.1.

Step 1: Adding the custom configuration file

Just like with Apache, we will create a custom configuration file so cURL built by CustomBuild will use our custom settings.

Create the directory:

mkdir -p /usr/local/directadmin/custombuild/custom/curl

Create the file:

touch /usr/local/directadmin/custombuild/custom/curl/configure.curl

Copy and paste the following contents to the file:

#!/bin/sh
perl -pi -e 's|CURL_CHECK_PKGCONFIG/(zlib/)|#CURL_CHECK_PKGCONFIG(zlib)|g' configure.ac
LIBS="-ldl" ./configure --with-nghttp2=/usr/local --with-ssl=/usr/local/lib_http2

As you can see, these contents tell cURL to be compiled using the lib_http2 SSL library.

Save the file and give it the correct permissions:

chmod 700 /usr/local/directadmin/custombuild/custom/curl/configure.curl

Step 2: Building cURL

Next, all we need to do is to build cURL.

cd /usr/local/directadmin/custombuild
./build curl

cURL has now been compiled with HTTP 2 support.