HTTP/2 not working on browsers

[TonyD]

Hello,

I have spent a couple of days trying to set up http/2 for my website. I also performed all troubleshooting available on the plesk support site. All in all everything is looking like my site should be ready to serve http/2 using nginx. I went through all the notes that I found online and everything looks OK but still my browsers both Chrome and Firefox keep receiving the assets in http 1.1.

The online tools are showing success. Both the Geek Flare one and the keycdn one.

Any other troubleshooting procedure that I could try?
What could it mean that the tools are showing success but the browsers are not using it?

Any help would be appreciated.

 

[trialotto]

@TonyD

In general, there are two reasons for the behaviour you described:

1 - lack of ALPN support - if you are using OpenSSL version 1.0.2 or higher AND Nginx has been compiled with OpenSSL version 1.0.2 or higher, then you are fine

2 - use of incorrect TLS ciphers - specific browsers (or other types of web clients) do not allow specific ciphers for HTTP/2 protocol

Some tips:

- check that you have the proper OpenSSL version, used at compilation time of Nginx, by running the command: nginx -V (in the output, you can see the OpenSSL version)
- check that your cipher suite is supporting HTTP/2 in all common browsers: just run the site through the online check tool at SSL Server Test (Powered by Qualys SSL Labs)

Hope the above helps a bit.

Regards..........

 

[TonyD]

@trialotto Thank you so much for your answer!

Here are some further details regarding the tips you mentioned:

Nginx is compiled using the correct version of OpenSSL

sudo nginx -v && sudo nginx -V
nginx version: nginx/1.13.8
nginx version: nginx/1.13.8
built with OpenSSL 1.0.2g  1 Mar 2016
TLS SNI support enabled
configure arguments: --prefix=/usr/share --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --modules-path=/usr/share/nginx/modules --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --user=nginx --group=nginx --with-ipv6 --with-file-aio --with-http_v2_module --with-compat --with-http_ssl_module --with-http_realip_module --with-http_sub_module --with-http_dav_module --with-http_gzip_static_module --with-http_stub_status_module --add-dynamic-module=/usr/share/passenger/ngx_http_passenger_module

In the SSL server test that you mentioned everything looks OK I reckon: SSL Server Test: contratium.com (Powered by Qualys SSL Labs)

Any further help would be very much appreciated.

 

[trialotto]

@TonyD

It seems to be the case that there is some issue with the cipher suite, it might be somewhat to strict.

Although that is not certain to explain specific browser behavior, it can explain the behavior of browsers that you mentioned: a simple fallback to HTTP/1 in case of mismatches.

I would recommend to run the following command from the command line

plesk sbin pci_compliance_resolver --enable all

and that would result in an average cipher suite that is strict to some degree, but not too strict.

Can you try that?

Regards.......

 

[TonyD]

@trialotto I did, configs where rebuit but the problem persists. I also restarted apache2 and nginx services. Anything else I should do for this to take effect?

 

[learning_curve]

@trialotto Thank you so much for your answer!
~~
In the SSL server test that you mentioned everything looks OK I reckon: SSL Server Test: contratium.com (Powered by Qualys SSL Labs)

If it helps... @TonyD It can't just be the ciphers, as they are almost the same as the ones that we use (images - yours first) and we have no issues at all with HTTP/2. There appears to be an issue with your SSL Certificate chain, so that should be / could be fixed (image) and adding HSTS and DNS CAA would probably do you no harm either.

What you could do quickly, which might add some light, is test all the browser(s) that you are using, not your own server / and or QSSL testing your server eg: Qualys SSL Labs - Projects / SSL Client Test then go from there...

In our case, if we see a HTTP/1 example via QSSL, it's purely because it is an old or out of updates browser e.g. Android 6.0. In all our own browser tests (we have no old ones...) it's HTTP/2 every time.

Despite the ciphers being very similar, we can see that you're getting handshake failures where we don't get any at all ... e.g. in your case: Safari 6 / iOS 6.0.1 Server sent fatal alert: handshake_failure or IE 11 / Win Phone 8.1 R Server sent fatal alert: handshake_failure So there is some glitch somewhere but contents of the QSSL provided check lists of simulated and non-simulated browsers are exactly the same in both our cases.

We're TLSv1.2 only and made all the required, associated changes, including cipher selections, in all instances, manually. We didn't use plesk sbin pci_compliance_resolver --enable all

 

[trialotto]

@TonyD

At this moment, we can safely assume that there is no problem with the cipher suite.

Now, we pay attention to the other potential culprits, which have been nicely described by @learning_curve, being

1 - browser related issue and/or not properly updated browsers: note that this can be an explanation, but it is not likely to be the root cause of the problem
2 - certificate related issues: very likely to be an issue here

Can you

- regenerate Let's Encrypt certificate (if used) for your domain,
- rerun the tests you did before (and give us some output),
- provide both the Apache and the Nginx config for the specific domain/vhost

and any other valuable information (like OS, Apache version, Plesk version etc) is always welcome.

Kind regards......

 

[TonyD]

@trialotto
I was testing using mod_http2 instead of nginx to serve in HTTP/2 but I am still getting HTTP/1.1. What's weird in this case is that looking at my assets I see that the .js files and the initial request to index both contain Upgrade: h2 headers while the .css files don't at all. I also enabled all ciphers again but that also didn't do anything. I read that some of them should not be enabled for HTTP/2 to work.

I just turned everything back to nginx and enabled pci compliance again, also renewed my let's encrypt certificate as you suggested.
The rest of my settings are as follows:
In the Apache & Nginx settings I have "Serve static files directly by nginx" checked and everything else is default (image attached) except the nginx directives below:

#W3 TOTAL CACHE CHECK
set $cache_uri $request_uri;

# POST requests and urls with a query string should always go to PHP
if ($request_method = POST) {
    set $cache_uri 'null cache';
}
if ($query_string != "") {
    set $cache_uri 'null cache';
}

# Don't cache uris containing the following segments
if ($request_uri ~* "(/wp-admin/|/xmlrpc.php|/wp-(app|cron|login|register|mail).php|wp-.*.php|/feed/|index.php|wp-comments-popup.php|wp-links-opml.php|wp-locations.php|sitemap(_index)?.xml|[a-z0-9_-]+-sitemap([0-9]+)?.xml)") {
    set $cache_uri 'null cache';
}

# Don't use the cache for logged in users or recent commenters
if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_logged_in") {
    set $cache_uri 'null cache';
}

# Use cached or actual file if they exists, otherwise pass request to WordPress
location / {
    try_files /wp-content/w3tc/pgcache/$cache_uri/_index.html $uri $uri/ /index.php?$args ;
}

# ENABLE COMPRESSION
gzip on;
gzip_disable "MSIE [1-6]\\.(?!.*SV1)";
gzip_proxied any;
gzip_comp_level 5;
gzip_types text/plain text/css application/javascript application/x-javascript text/xml application/xml application/xml+rss text/javascript image/x-icon image/bmp image/svg+xml;
gzip_vary on;

# HSTS
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";

# NGINX/PLESK CONFIG
if (!-e $request_filename) {
    set $test P;
}
if ($uri !~ ^/(plesk-stat|webstat|webstat-ssl|ftpstat|anon_ftpstat|awstats-icon|internal-nginx-static-location)) {
    set $test "${test}C";
}
if ($test = PC) {
    rewrite ^/(.*)$ /index.php?$1;
}

Checking everything again:
- HTTP/2 Test | A simple HTTP/2.0 test tool says that my HTTP/2 works and all is well.
- my certificate turned to A+ after all that SSL Server Test: contratium.com (Powered by Qualys SSL Labs)
- in my local browsers I am still getting HTTP/1.1

 

[learning_curve]

@TonyD FWIW... We've just looked at the latest QSSL (Assessed on: Sat, 08 Dec 2018 10:54:32 UTC) on your domain. You've added HSTS, which will have aided the jump from A to A+ with QSSL. Probably not the main cause of your issue, but....

1) You've gone from TLSv1.2 only, back to TLSv1.0 / TLSv1.1 / TLSv1.2. Was that your intent? TLSv1.0 for example is pretty pointless now

2) The additional effect of that change, is the addition of lots of weak ciphers. QSSL lists them all for you by protocol. That's far from ideal really.

3) The certificate with the issues that we posted before, was certificate #2 (self-signed Plesk) in the certificate chain, not certificate #1 (Let's Encrypt - your domain). In the latest QSSL assessment, it's still the same certificate, still with the same issues. The question is: Has your Plesk installation been setup with the correct FQDN and if so, has the certifcate for that FQDN been issued via Let's Encrypt (or a.n.other) and if so, has that certificate been assigned correctly etc? A self-signed certificate will usually cause lots of issues, hence the question...

@trialotto will post lots more usefull stuff to help you we're sure, but you could look at these 3 things meantime...

PS You didn't say, but did you test all your own browsers too?

 

[trialotto]

@TonyD

It is important to make the STR (steps to reproduce) "pure" and unbiased: please copy your current nginx config and deactivate W3TC (and check for W3TC pollution in both Apache and Nginx files afterwards.

Anyway, it is good to know that you are talking about a setup consisting of

- WordPress
- W3TC plugin
- some custom Nginx config

and that is all valuable (read: necessary) information for us to be of any (proper) assistance.

Well, to be honest, it might be the case that you only have to deactivate "serve static files directly by Nginx".

You can test that hypothesis by simply removing "css" from the textbox that includes the file extensions that are served directly by Nginx.

After all, you noticed a problem with css files and if my hypothesis is correct, your css files would be served via HTTP/2 protocol when not served directly by Nginx.

If that is not the case, then it is very likely that W3TC is enforcing some settings that prevent HTTP/2 protocol enablement for specific files.

By the way, W3TC is a bit "overcomplicated" - the same can also be achieved (in a more easy fashion) with Nginx and the Nginx caching functionality: that is another topic.

I hope that you can report back soon, since I am rather interested in this topic by now.

Regards.....

PS The before mentioned hypothesis is based on the fact that I am aware of some pitfalls in the default Nginx configuration, as shipped with Plesk. One of them is that the option to set "serve static files directly by Nginx" does not leave any space to configure Nginx in such a fashion that it is setting response headers differently in comparison to request headers, which is important for server performance and even in the context of security. In short, it might also be the case that this peculiar behavior caused by Nginx default config is related to your current issue and/or will result in a bias of the analysis of your current problem.

 

[TonyD]

@learning_curve I went back to TLS1.2 and the previous list of certificates which I found here HTTP/2 Support in Plesk step 6 in troubleshooting but I only selected TLS1.2 in the --protocols parameter as you suggested. SSL Server Test: contratium.com (Powered by Qualys SSL Labs)

@trialotto I disabled W3TC, and removed css from the textbox of file types that are served directly from nginx but I'm still getting HTTP/1.1 on all of my local browsers: Chrome, FF, IE edge.

Please let me know if there's anything else we can test.

 

[TonyD]

Also removed the self-signed certificate in case that caused any of the issues

 

[learning_curve]

Again, these items may not be the cure for the issue you're having, but

@learning_curve I went back to TLS1.2 and the previous list of certificates which I found here HTTP/2 Support in Plesk step 6 in troubleshooting but I only selected TLS1.2 in the --protocols parameter as you suggested. SSL Server Test: contratium.com (Powered by Qualys SSL Labs)

As mentioned, when we did this, we didn't follow the information on the HTTP/2 page link you've posted, for two reasons: 1) By default (at that time) we found that running # plesk bin http2_pref enable meant that TLSv1 was being added to /etc/nginx/conf.d/ssl.conf and that 2) This error: Enabling HTTP/2 in Advisor extension does not work on Plesk server was still present even though tests and workarounds are clearly shown too. That's mainly why we did everything manually... including HTTP/2, all ciphers, in all different areas etc However, using TLSv1.2 only, as you have now done in Nginx (not sure if you've applied TLSv1.2 everywhere else too) is a positive move. We and many other users do still believe this (but, roll on TLSv1.3 )

Also removed the self-signed certificate in case that caused any of the issues

Yes we can see this has changed, but as you've probably noticed, the replacement Certificate #2 is still not trusted.... Probably, it appears anyway, because Certificate #2 is for a different domain name than your own domain name (Certificate #1) So there appears to be no visible SAN or Sub-Domain (Wildcard) certificate relationship between the two. That should easily be fixable though, depending on 'who, how and why is hosting who' with regards to those 2 domains

 

[TonyD]

@learning_curve I thought that certificate #2 would no longer be displayed there. Do you happen to know how to remove it? In the global list of certificates I now only have my let's encrypt one.

Also thank you both for all the help and please excuse my naivety in some of these issues. I am new to this space.

 

[learning_curve]

@TonyD Both certificates are Let's Encrypt Certificates, but one is trusted and one isn't. That goes back to the comment we made: "...there appears to be no visible SAN or Sub-Domain (Wildcard) certificate relationship between the two..."

Certificate #1 has been created for contratium.com aka the domain name that you entered into QSSL to run the test and a domain that (we are guessing) you are in full control of. So in your own Plesk account, what hostname is entered within the Full hostname field on this Plesk page: *your-domain-name*8443/plesk/server/preferences/ ?

We ask, because Certificate #2 has been created for triton237.startdedicated.net aka the domain name that we think, will probably have been entered within the Full hostname field mentioned above, as the FQDN but... this domain may actually also be the server IP FQDN and so possibly, it is out of your control, if say, you are running a VPS on this server or one of the many other, different available hosting setups**

In our last post, we said; "...depending on 'who, how and why is hosting who' with regards to those 2 domains..." because that's the information, that only you know, but in that information, is the answer you need.

If you own and run both domains, you can fix it yourself quite easily. If you only own and run contratium.com and triton237.startdedicated.net is owned and run by somebody else, then it will be more difficult Regardless and @trialotto may confirm, the non-trusted certificate is probably not the reason for your main HTTP/2 concern anyway

**There is also the FQDN that's been applied to the server (IP) itself, outside of Plesk, which you may (or may not) have access to and control of.

 

[TonyD]

@learning_curve I have full control over that server but I don't understand why that certificate is added to contratium.com since its use is for https within plesk

 

[learning_curve]

Okay, understand a little better now. What was the answer to this question:

So in your own Plesk account, what hostname is entered within the Full hostname field on this Plesk page: *your-domain-name*8443/plesk/server/preferences/ ?

FWIW If you run checks on the IP Address shown in your QSSL, they return triton237.startdedicated.net as the Hostname, not contratium.com. It's the same result with Reverse DNS Tests etc. So this issue does appear to relate to the coments in italics we made in our last post. You can run lots of different tests on something like MXToolbox and if you do, you'll see other issues too (mainly relating to mail etc... but you will clearly see the triton237.startdedicated.net Hostname not contratium.com and other records relating to the certificate path issue)

 

[TonyD]

@learning_curve triton237.startdedicated.net is on the full hostname field on the page you mentioned. But that plesk has several sites on it

 

[trialotto]

@TonyD

Is your issue resolved at this moment?

Note that I do get the right protocol when using Firefox....... and, in addition, I also noticed that you changed "some settings": nice job!

Regards......

 

[learning_curve]

@learning_curve triton237.startdedicated.net is on the full hostname field on the page you mentioned. But that plesk has several sites on it

Yeah! So there's your answer right there ^^
You've checked and the FQDN triton237.startdedicated.net is the current entry in the Full hostname field on the Plesk page: *your-domain-name*8443/plesk/server/preferences/ and that's why, it is appearing as Certificate #2.

Just guessing, but it's probably the same hostname setup on the server outside of Plesk too (because of the active reverse DNS etc) unless, you've purposely set this up in the DNS records within Plesk.

You have contratium.com setup as one of several domains on the same server and both this specific domain plus, the hostname domain already have valid Let's Encryt Certificates, but "...there appears to be no visible SAN or Sub-Domain (Wildcard) certificate relationship between the two..." aka there's no 'connection' between the two domains / certificates. Or in very simple terms, it's just a 'one domain hosted on another domain' certificate quandry

Again just FWIW we have a FQDN hostame and lots of other domains, all on the same server, all within the same Plesk account too. Let's Encrypt will issue a multi-domain / wildcard certifcate, so our FQDN hostname domain has one of this type of Let's Encrypt certifcates, which also names all the other domains / sub-domains. This means all the certificates on any domain has no path / chain / trust issues.

It's probably easier (in terms of work effort) to just purchase a SAN Certificate and do it that way, but we happy to do the extra work and use the Let's Encrypt multi-domain / wildcard certifcate option which is free and works just fine.

Whilst this certificate trust issue can be fixed, we're still pretty sure that this is not the cause of your original HTTP/2 issue.