Select Page

In April 2019, a client was suddenly having problems editing their WordPress posts. They kept getting intermittent, yet frustratingly frequent, browser errors saying “421 Misdirected Request”. It mostly happened in Safari, but through independent testing, we were able to reproduce the issue in Chrome and Firefox, and on disparate networks, though not so nearly as frequently or consistently. In terms of reproducibility, it seemed to favor this one client’s IP address, computers, tablets, and mobile devices (all Apple running Safari).

The only major change we had made was on the client’s hosting on GoDaddy. We had moved them from one legacy plan for multiple blogs on various domains to a newer and more capable plan. That hosting change itself did not produce the error. It was only when we put all of their sites on a single SSL certificate under a primary domain, with all other domains as “children” of that domain on the same certificate.

From then on, they got the 421 Misdirected Request errors.

We went several rounds with multiple tiers of GoDaddy’s support team, getting on a first-name basis with several. They made many suggestions and tried several things. But nobody could begin to resolve the issue for us.

In July 2019, after the problem persisted to various degrees, I did a new search for the same issue to see if any new answers have been found since I last researched the topic in April. Everything I saw in July conclusively points to the setup at GoDaddy around having a single SSL certificate with multiple domains attached to it. Going all the way back to the source of things is helpful here, so I went to the Apache webserver documentation about HTTP2 and SSL. This article here describes the problem, and the solution, in better detail than I was able to get from GoDaddy after MANY rounds with escalated support. The key part is quoted below:

Multiple Hosts and Misdirected Requests

Many sites use the same TLS certificate for multiple virtual hosts. The certificate either has a wildcard name, such as ‘*.example.org’ or carries several alternate names. Browsers using HTTP/2 will recognize that and reuse an already opened connection for such hosts.

While this is great for performance, it comes at a price: such vhosts need more care in their configuration. The problem is that you will have multiple requests for multiple hosts on the same TLS connection. And that makes renegotiation impossible, in face the HTTP/2 standard forbids it.

So, if you have several virtual hosts using the same certificate and want to use HTTP/2 for them, you need to make sure that all vhosts have exactly the same SSL configuration. You need the same protocol, ciphers and settings for client verification.

If you mix things, Apache httpd will detect it and return a special response code, 421 Misdirected Request, to the client.

httpd.apache.org. (2019). mod_http2 – Apache HTTP Server Version 2.4. [online] Available at: https://httpd.apache.org/docs/2.4/mod/mod_http2.html [Accessed 9 Jul. 2019].

Another authoritative piece of documentation straight from the horse’s mouth at apache.org is found here and describes it in a bit more understandable terminology. It says:

Summary

Using name-based virtual hosts with SSL adds another layer of complication. Without the SNI extension, it’s not generally possible (though a subset of virtual host might work). With SNI, it’s necessary to consider the configuration carefully to ensure security is maintained.

(Note: this page is just about support that comes with the Apache web server. Alternatives such as mod_gnutls are another topic.)

The Problem

The problem with using named virtual hosts over SSL is that named virtual hosts rely on knowing what hostname is being requested, and the request can’t be read until the SSL connection is established. The ordinary behavior, then, is that the SSL connection is set up using the configuration in the default virtual host for the address where the connection was received.

While Apache can renegotiate the SSL connection later after seeing the hostname in the request (and does), that’s too late to pick the right server certificate to use to match the request hostname during the initial handshake, resulting in browser warnings/errors about certificates having the wrong hostname in them.

And while it’s possible to put multiple hostnames in a modern certificate and just use that one certificate in the default vhost, there are many hosting providers who are hosting far too many sites on a single address for that to be practical for them.

cwiki.apache.org. (2019). NameBasedSSLVHostsWithSNI – HTTPD – Apache Software Foundation. [online] Available at: https://cwiki.apache.org/confluence/display/HTTPD/NameBasedSSLVHostsWithSNI [Accessed 9 Jul. 2019].

The solution to the problem is entirely upon GoDaddy to perform. It’s in their deepest server configurations around SSL and how they’re handling your multi-domain certificate.

Server Name Indication

The solution is an extension to the SSL protocol called Server Name Indication (RFC 4366), which allows the client to include the requested hostname in the first message of its SSL handshake (connection setup). This allows the server to determine the correct named virtual host for the request and set the connection up accordingly from the start.

With SNI, you can have many virtual hosts sharing the same IP address and port, and each one can have its own unique certificate (and the rest of the configuration).

Ibid.

Note that the date on that article, when I accessed it, post-dated my own initial discovery and investigation of this problem, which tells me that someone actually discovered it around the same time I did and made an effort to document their findings in the official web server documentation. That also tells me that this is a recent discovery after something Apache changed, GoDaddy changed, or GoDaddy wasn’t aware of and didn’t change about what they’re doing. So, the consequence is that this new issue is appearing.

While I saw it occur with Chrome browsers, it seems to mostly affect Safari browsers, further complicating things for troubleshooting. As Safari is not very commonly used in comparison to Chrome (Safari is only 5% of browsers used while Chrome is 60%), there are not as many eyes seeing the issue and trying to figure it out.

Resolution

So, the options appear to be:

  1. Hammer on GoDaddy support until they give you someone who can affirmatively acknowledge this very real problem and escalate it appropriately for a firm resolution.
  2. Failing #1, purchase a separate SSL certificate per domain. Depending on your budget, this may require prioritizing which domains get their own, individual HTTPS and which do not.
  3. Failing #2, change to a different web host that has conquered this issue using the information I’ve quoted above, or provides a solid workaround such that you don’t break your budget and can still have HTTPS for all your domains.
The following two tabs change content below.
Rob Watson is a Web professional. Beginning in 1996 as a self-taught web designer, he now owns and operates a web creative agency named Webidextrous.com. If you need website coordination (a.k.a. "webmastering"), media production, social media, and SEO, ask Rob for help!

Pin It on Pinterest

Shares
Share This