Nginx configured with http2 doesn't deliver HTTP/2

Question

I have a problem with my Nginx configuration. I upgraded to nginx 1.9.6 to test http/2 but it does not work on my server.

I used ubuntu 14.04.2 LTS

This is the nginx -V output :

nginx version: nginx/1.9.6
built with OpenSSL 1.0.2d 9 Jul 2015
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-log-path=/var/log/nginx/access.log --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid --with-pcre-jit --with-debug --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_geoip_module --with-http_gzip_static_module --with-http_image_filter_module --with-http_realip_module --with-http_stub_status_module --with-http_ssl_module --with-http_sub_module --with-http_xslt_module --with-http_v2_module --with-stream --with-ipv6 --with-mail --with-mail_ssl_module --with-openssl=/build/nginx-GFP362/nginx-1.9.6/debian/openssl-1.0.2d --add-module=/build/nginx-GFP362/nginx-1.9.6/debian/modules/nginx-auth-pam --add-module=/build/nginx-GFP362/nginx-1.9.6/debian/modules/nginx-echo --add-module=/build/nginx-GFP362/nginx-1.9.6/debian/modules/nginx-upstream-fair --add-module=/build/nginx-GFP362/nginx-1.9.6/debian/modules/nginx-dav-ext-module --add-module=/build/nginx-GFP362/nginx-1.9.6/debian/modules/nginx-cache-purge

And this is my vhost config :

server {
    listen         80;
    server_name    localhost;
    return         301 https://$server_name$request_uri;
}

server {
    listen 443 ssl http2; ## listen for ipv4; this line is default and implied

    root /var/www/rendez-vous;
    index index.phtml index.html index.htm;

    # Make site accessible from http://localhost/
    server_name localhost;
    ssl_certificate /etc/nginx/certificates/myeventsportal/server.crt;
    ssl_certificate_key /etc/nginx/certificates/myeventsportal/server.key;

/...

If I navigate to my site with the latest version of chrome, it is only served over http/1.1.

Answer 1

I've just run into the same problem, but I think I know why it happens. nginx 1.9.6 is not a stock package on Ubuntu 14.04, so you're probably getting it from an nginx PPA. That's fine, but those packages are built with the stock libraries from 14.04, which is to say OpenSSL 1.0.1f. Unfortunately that version of OpenSSL does not contain RFC7301 ALPN support which is needed for proper HTTP/2 negotiation; it only supports the now-deprecated NPN. It looks like Chrome has already removed support for NPN, so it's incapable of negotiating an HTTP/2 connection without ALPN. Firefox 41 on the other hand, still has NPN support and you should be able to use HTTP/2 with that.

You can test your server like this - you will need OpenSSL 1.0.2d installed on your client (run openssl version to check):

Test with ALPN:

echo | openssl s_client -alpn h2 -connect yourserver.example.com:443 | grep ALPN

If ALPN is working, you should see:

ALPN protocol: h2

otherwise you'll get:

No ALPN negotiated

Test with NPN:

echo | openssl s_client -nextprotoneg h2 -connect yourserver.example.com:443

If that works, you will get:

Next protocol: (1) h2
No ALPN negotiated

That means that it's successfully negotiating an HTTP/2 connection via NPN, which is what Firefox does.

So how to solve this? The only way I can see is to install a later build of openssl from a PPA (I use this one for PHP, which also contains openssl) and build your own nginx linked to it. You can find the config params for your existing nginx build by running nginx -V, and you should be able to use that to build your own version.

Update: I've discovered that the reason that Chrome doesn't support HTTP/2 with NPN is not that it doesn't support NPN (though it will be dropped at some point), but that it specifically doesn't support h2 with NPN, as shown on the chrome://net-internals/#http2 page:

Answer 2

Short version.

I found that ESET antivirus can prevent HTTP/2 from working when SSL/TLS filtering is turned on, on the browsing computer. Check to see that your antivirus is not filtering the SSL/TLS.

---

TLDR version

I ran into the same problem as the poster, but with an interesting twist. I upgraded my server configuration to nginx 1.12.1. compiled with OpenSSL 1.0.2.g and on initial inspection it had “solved” the problem of HTTP/2 not working. In my browser, I could see that the server certificate was verified by Let’s Encrypt. Content was also being served with HTTP/2.

Some time later, I found that the very same page and same resources were no longer being served over HTTP/2. Coincidentally, the site was no longer verified by Let’s Encrypt, but by Eset?!!?! To my amazement, the new http2 problem had nothing to do with my server configuration at all. It turned out that I had SSL/TLS filtering on in my antivirus on my local computer and this was causing the issue. The solution was to turn off SSL/TLS filtering in the antivirus. Once I had turned it off (and rebooted the computer) HTTP/2 worked again and the certificate was verified by Let’s Encrypt again.

For instructions on how to turn off SSL/TLS in ESET, check out http://support.eset.com/kb3126/?locale=en_US

Answer 3

As Synchro says in his answer, the issue is most nginx packages are not built with OpenSSL 1.0.2. Compilation of ALPN requires symbols only present in the relevant OpenSSL development source.

You could try using the official nginx distribution, selecting xenial rather than trusty. This works for me with Debian Jessie and jessie-backports OpenSSL 1.0.2 - it may work for you. However, be aware that it is an unsupported configuration - rebuilding it is the "right" answer.