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 421 Misdirected Request 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.
The Cause of the 421 Misdirected Request Response Code
Going all the way back to the source of things is helpful here, so I went to the Apache web server documentation about HTTP2 and SSL. This article here describes the problem, and the solution to 421 Misdirected Request errors, 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].
Gone are the days of clicking “Update” and hoping for the best. Let Webidextrous manage your maintenance. We’ll give you back your time and peace of mind.
Supporting Information About the 421 Misdirected Request Response Code
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].
GoDaddy and the 421 Misdirected Request Response Code
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 to the 421 Misdirected Request Response Code
So, the options appear to be:
- 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.
- 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.
- 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.
thanks man, leaving a comment so this gets more attention.
No problem. Glad it was helpful. It sure was puzzling to us for a while.
Thanks for writing. I just got off the phone with GoDaddy they refused to refund my wildcard cert. I’m thinking a whole new hosting provider will be the go.
Sorry to hear that. GoDaddy is really hard to work with when it comes to making things right for their customers who bought something that no longer works for them. They always want to up sell you or keep you trapped in some long term plan. I’m sure there are other hosts who can provide wildcard certs that are more configurable and flexible. Drop by and let us know what host you chose. 🙂
I am getting this exact same error. All started when we purchased our SSL. Which we share across 3 sites. The problem is intermittent, but sometimes I don’t get the Misdirected Request error, I get the Cannot connect to Database error instead. The errors for us seem to only happen on mobile phone browsers (both IOS and Android). Doesn’t do it on desk top computers. We are also with GoDaddy. I am not quite sure what to hammer GoDaddy into doing?? Is this something setting they are supposed to fix on their end?
They need to change their technology and approach to providing shared SSL certs. The problem is with when site visitors have user agents (browsers) that don’t support SNI. Often, the mobile device browsers suffer from lack of support for SNI. But the true resolution of the issue needs to come from the server stack and not expecting visitors to use a different browser.
I have tried several times to get GoDaddy to do this right but they shift the blame or deny that the problem exists. Lately I’ve been telling clients with multiple domains who don’t want to pay multiple times for SSL per domain to instead switch to another hosting company that uses LetsEncrypt. It’s free, it autorenews every 3 months (if your new host has that feature) and each domain can have its own SSL instead of wildcarding off of a primary domain.
Rob, do you have any specific domain hosts you’d recommend? I am having this issue, and I am the end of my ability to troubleshoot it. I really just need to know my websites are working when people visit them.
My Connections page has a link to Pantheon (https://webidextrous.com/connections) where you can sign up for hosting that won’t do this to you. Pretty much all other mainstream hosts don’t have this problem from what I’m seeing. This seems to be strictly an issue with how GoDaddy incorrectly set up multi-domain SSL certs. If anyone reading this has an example of other hosts where this is also a problem, please comment. It would be good info to have out there.
Thank you for responding. You are definitely correct in that GoDaddy does nothing but try to deflect blame. The last tech support person tried to tell me it was because of bots that was causing this. I found that incredibly hard to believe as the reports did not indicate that. I don’t think moving hosting is practical for us right now. I will try my luck with getting them to refund our SSL purchase. It’s not right that they are selling a knowingly faulty product. Mobile browsers are the norm now, and it’s crazy that it’s not supported.
If you’re looking for a reliable host that won’t deflect blame, I can provide you with the Preferred Pricing plans at Pantheon.io (Full Disclosure: Webidextrous is an agency partner with them, but we don’t get a dime as an affiliate or reseller…we just really love their service and want to evangelize it).
This write up was very informative, Thanks! In my client’s case, the hosting for all three sites is Godaddy shared, however the SSL. cert was purchased from DigiCert. That being said, is the issue still with the hosting, or could it be that the certs are configured incorrectly? Just trying to figure out who to press on this issue.
Hmm. That’s a good question. I’m not entirely sure without digging into the details of the DigiCert and how the GoDaddy shared domains are set up. Have you had any luck with GoDaddy support or DigiCert on it?
Thank you very much for the info. I use HostGator Cloud Business package with 11 WP installs. Each domain is added as subdomain of a main domain for a package.
For example my main website in this package is iblog.ee, and every added domain is a second level domains of course that is being added as third level domain.
So I get this tallinails.com domain is added as tallinails.iblog.ee and tallinails.com has it’s own SSL certificate, but iblog.ee has it’s own SSL too! This causes some issues for Safari and other browsers to recognize. Only solution that I found so far is to use 1 package for 1 domain! Yes it is a little bit pricey, but it fixes the problem for good!
Such a small world. I first saw this error this morning on my phone, so I googled the error message and clicked the first link I saw that specifically mentioned WordPress, and I got about a third of the way through before I recognized your photo in my peripheral vision. Like the last commenter before me, I’m also using HostGator, though because of my liberal use of subdomains and the fact that almost all of my domains and WP installs are for personal use, I had to find a more cost-effective solution to 1 certificate for 1 domain, so I just renamed my htaccess file to stop it from redirecting from http: to https:. It’s not a pretty solution, but since I’m the only one who is looking at the page giving me errors and it’s filled with non-personal info (it’s just a list of things to do in our city), it’s quick and acceptable, though far from ideal. Thanks for the explanation of what the issue is, even though the best solution seems to be either pestering or switching one’s hosting provider.
Yes, your solution does work, and I’m glad that it solves the issue for your particular situation. I wish it were something that simple for others who have different needs. GoDaddy definitely needs to step up its game and configure its servers to properly handle multi-domain certs and eliminate this bothersome error. Thanks for commenting!
I have a client who gets this error. They have their own hostgator account and no other domains on the account. But they do have a sub domain (example m.website.com). Does this sound like the same issue and if so what are their options?
Yes, this definitely sounds like the same issue. I’d suggest trying to add a separate SSL certificate to m.website.com to see if the error stops happening.
Hi Jason, I’m having the same issue with Hostgator and my subdomain. Did you get a separate SSL? If so did it solve your problem?
Thank you, Rob, for the article!
Way to resolve this.
1) Avoid GoDaddy hosting + any EIG owned hosting company.
2) Use Apache-2.4.41+ configured correctly.
3) Use https://LetsEncrypt.org free certs, so if you do have a problem, just generate another free cert to fix the problem
What hosting provider would you recommend? I am running into this issue with GoDaddy similar to everyone else.
Hi Michelle,
I highly recommend Pantheon.io for WordPress and Drupal hosting. Another great host is WP Engine.
Thanks! How about for sites not on WordPress? Our sites are coded from scratch using Bootstrap.
For the 421 Misdirected Request error, WordPress isn’t a factor. The main issue is how the SSL certificates are set up. So, a Bootstrap site, or even a plain HTML site coded in Notepad++ or Sublime is going to suffer from this issue if you’re hosted on GoDaddy, or your host is doing the same type of SSL setup as GoDaddy.
Sorry, I meant which hosting provider should I use for a site that isn’t on WordPress? Looks like the two you previously recommended are for WordPress. Thanks for your help!
Oh, I see what you mean. SiteGround, InMotion, A2 Hosting, DreamHost, MDD Hosting, or Stable Host will be able to accommodate your needs in that direction. Be sure that any host you choose is NOT an EIG-owned host (Endurance International Group). Every hosting company that EIG absorbs has a nasty habit of becoming terrible at hosting and customer service.
I’m running int this exact same problem now. After jumping through so many hoops to get my SSL working with multiple domains and dealing with GoDaddy not knowing what this problem is. What is the point of a multi domain cert if it doesn’t work. My clients can’t even pull up my website.
Exactly. It makes no sense at all that GoDaddy ignores this issue. Well, I guess it does from their perspective because it’s just “rare” enough to fly under their radar, but it still is a problem for real people with real websites that are important to them. It’s best to just switch hosts and use free LetsEncrypt for every single domain.
What did you end up doing to resolve this? I take it after your escalations at GoDaddy they ended up doing nothing to help you.
I’m having this exact problem now and it’s a major issue.
It remains unresolved as far as I know. GoDaddy showed no interest in taking care of the issue. The recommendation would be to change to another host that doesn’t engage in the multi-domain SSL practices that GoDaddy is engaging in.
Thanks so much for leaving this discussion up. The same thing is happening for my clients’ site (with two subdomains). I just literally got off the phone with GoDaddy. Because this is only happening for us in Safari, they called it a browser problem and did not investigate.
Frustrating, to say the least.
Having the same issue with GoDaddy hosting and the multi-domain SSL, users receive the error page and then refresh and it works. Not happy with moving everything over to another provider- I have too many domains and sites, I guess that’s why I found myself with a multi-domain SSL. How about using Cloudflare for SSL ?
It is my understanding that Cloudflare does its SSL per individual domain or subdomain. So, you should be able to resolve this by having them provide your SSL.
I have to disagree with you regarding how Cloudflare works. First, if you want to use SSL you have to be using SSL at the origin server. But if you look at the SSL cert being provided to the end user it is that of the CDN proxy and not that of the origin server. Interestingly enough the certificate is issued to sni.cloudflaressl.com. So it’s right there in the (subdomain) name. I’m getting an SNI related error and I have a certificate tied to a server clearly being used for SNI.
Our Safari users didn’t start getting this error until we started proxying ourselves under Cloudflare.
Thank you for posting this information! Up until this point, I was at a loss with what to do to resolve my issue since it was only happening intermittently on certain devices, namely iOS devices running Safari, Chrome, or Firefox.
Every once in a while one of my pages would display “421 Misdirected Request,” but the bigger issue I was experiencing was that I have Javascript, CSS, and image files that I’m sharing between multiple domains which are all connected to the same UCC SSL certificate and none of these shared resources were loading on any domains except the one where they are stored. These files always load on my Surface, but most of the time they don’t load on my iPhone. I plugged my iPhone into a Mac and by using the developer console observed that the loading of all these files failed with error 421. In Googling that error code, I stumbled upon this article.
During my first call with GoDaddy, the technician was able to replicate the issue on his mobile device, so he submitted a support ticket. A few hours later, I received an email response that said, “We reviewed your hosting and found that the site is loading correctly on desktop and mobile, please review your contents for mobile optimization.” Apparently the person working on this ticket wasn’t able to replicate the issue.
The second time I called, the technician was also able to replicate the issue on his mobile device, but claimed that it was an error with my code. He also suggested I get a free 90-day SSL certificate for the domain where I was storing the files to see if that fixed the issue. First, I placed the exact same code into each individual domain’s directory and was able to load all the files normally, proving that it wasn’t my code. I then got a free 90-day SSL certificate and connected it to the domain that was storing the files. As expected, the files loaded correctly, proving that it is an issue with their UCC SSL certificate.
I switched everything back (in order to replicate the issue) and called them a third time. I shared my findings with the technician, but he was unable to replicate the issue on his mobile device. Therefore, he was unwilling to help or accept responsibility for the issue. We got disconnected midway through the call and I never received a return call.
At this point, I was so fed up with dealing with GoDaddy support that I purchased a separate SSL certificate for my domain that is storing the shared files and now everything works like it should. It’s unfortunate I had to go this route since GoDaddy should’ve accepted responsibility and done something to make it right. At least my clients are happy now that their sites work correctly.
I hope your article is able to help others resolve similar issues as well.
I’m glad this helped! And thank you for the detailed writeup of what it’s like to deal with GoDaddy on this issue. It’s a longshot, but I hope someone in GoDaddy’s hierarchy sees this post and recognizes that they are at fault for this poor setup of things, and then fix it.
Seeing this issue with BlueHost as well. Thanks for the write.
Interesting. Thanks for sharing that bit of information. I don’t know why it’s not being addressed by major hosting companies, other than the possibility that they just don’t care about the experiences of Safari browser users (a small minority).
Just started happening to me yesterday. The site is hosted on bluehost.
Were you able to resolve this with bluehost?
I’m not sure if my problem is related. I get the same 421 Misdirected Request message on Safari, but only on pages using H5P interactive content.
I’m seeing your thread on this at https://h5p.org/comment/36062. Thanks for the mention. If anyone will know how to connect the issues with H5P it should be the folks on that forum. I hope someone can figure that out. My only guess is that your site educationalhub.org has a certificate with a CN = fredures.org rather than educationalhub.org. That difference may be where Safari and the SNI is getting tripped up. If you set your CN to educationalhub.org, the problem may be resolved.
Here may be a clue.
As a retired SW Engineer having spent a hideous year testing SSL,
I tackled making and installing my own 10-slot SSL certificate
using the GoDaddy SSL tools circa 2018, and it had worked okay.
Recently, to use that 10-th slot, and again going up to 15 slots,
GoDaddy sales said we could use a MANAGED certificate (also saying
we somehow overspent some $400 which they refunded), and GoDaddy
tech support would take care of everything, which seemed heavenly.
But immediately, the MAC/Safari started intermittently reporting:
“Misdirected Request”
“The client needs a new connection for this request as the requested host name does not match the Server Name Indication (SNI) in use for this connection.”
And that on an untouched website that had been working perfectly.
(That probably also explains why the DIVI editor sometimes cannot save our work.)
masOS Version 10.15.7 (19H2)
Safari Version 14.0 (15610.1.28.1.9, 15610)
I found at least one of my own old certificates, and another date’s
old CSR, and some old examples of a recommended prefix to .htaccess,
so I may be able to see how the GoDaddy MANAGED SSL differs…
I’ll let you know if I do!
More: Comparing my old (good) and new (bad?) certificates,
All non-binary data looked identical to my SW eyeball, except:
1. The order of www. and non-www domains was scrambled;
2. The old cert has 3 “Signed Certificate Timestamp” sections;
The new cert only has 2 “Signed Certificate Timestamp” sections.
Neither of those two differences seem significant to me.
I have this very top block from an 2018 (good) backup of .htaccess file:
# This block added to .htaccess in root folder of trump4all.us
# by Glenn Johnson Scheper 2018-08-26 after setting up a new SSL certificate,
# also adding the https to URL 2 places in WP Settings General:
# BEGIN GD-SSL
Options +FollowSymLinks
RewriteEngine On
RewriteCond %{HTTPS} =off [OR]
RewriteCond %{HTTP_HOST} !^trump4all\.us$
RewriteRule ^(.*)$ “https://trump4all.us/$1” [R=301,L]
Header add Strict-Transport-Security “max-age=300”
# END GD-SSL
# BEGIN WordPress…..
=============================================
But this block is atop the new 2020 (problematic?) .htaccess:
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteCond %{HTTP_HOST} ^(www\.)?trump4all\.us$ [NC]
RewriteRule ^(.*)$ https://trump4all.us/$1 [L,R=301]
# This block added to .htaccess in root folder of trump4all.us
# by Glenn Johnson Scheper 2018-08-26 after setting up a new SSL certificate,
# also adding the https to URL 2 places in WP Settings General:
# BEGIN GD-SSL
Options +FollowSymLinks
RewriteEngine On
RewriteCond %{HTTPS} =off [OR]
RewriteCond %{HTTP_HOST} !^trump4all\.us$
RewriteRule ^(.*)$ “https://trump4all.us/$1” [R=301,L]
Header add Strict-Transport-Security “max-age=300”
# END GD-SSL
# BEGIN WordPress…..
So, I plan to strip off their (GoDaddy) added 6 line prefix,
and wait and watch whether the (intermittent) problem ceases.
Thanks for your comments! I’ll be interested to see how it turns out for you. I get a lot of traffic to this article. I’m realizing that I need to write more about problems GoDaddy causes so I can get more visits! haha
My wife hates it when I clear her cache, but for you guys,
I’ve been doing it all night until just now the cock crew.
It is not in the .htaccess, nor a downrev WP, nor downrev
themes or plugins, neither just one one particular theme.
Here is a canonical sequence that will produce the failure:
On MAC SAFARI:
paste and go to URL1: about:blank
Do History, clear (#1) all history
paste and go to URL2: https://personaltouchrecruiters.com/
Do History, clear (#2) all history
paste and go to URL3: https://coachwithaudrey.com/wp-admin/
URL1 can be anywhere else: google, amazon, blank.
URL2 must be the domain of the COMMON NAME of the Certificate.
URL3 must be any domain listed in the SERVER ALTERNATE NAMES.
E.g., another failing example from my current websites:
https://www.amazon.com
clear all history
https://personaltouchrecruiters.com
clear all history
https://trump4all.us/wp-admin/
A Failure means that Safari reports for URL3:
Misdirected Request
The client needs a new connection for this request as the requested host name does not match the Server Name Indication (SNI) in use for this connection.
Two SAN domains/wp-admin/ in URLS 2 and 3 do not fail:
https://www.amazon.com
clear all history
https://trump4all.us/wp-admin/
clear all history
https://coachwithaudrey.com/wp-admin/
(Passed, got to the login screen)
But wait, I just noticed the URLs are not similar: Far above
URL2 was the bare CN domain, but here a SAN + wp-admin/.
So test may need some more tightening up, but not by me.
I Wiresharked the MAC failure from my PC over WIFI:
Filtering on ip.src and ip.dst of the TSLv1.2 address,
I saw: a few TCP packets, only one TLS handshake, then
some TLS application data, all in a span of one second.
Browsing URL3 never raised another peep on the wire.
What about MAC CHROME? I am not erasing another cache!
I lay my task to rest, out of my hands to fix my website.
Who needs sleep? Caffeine >= Sleep.
I pushed harder on a SAFARI fault than GoDaddy,
because the Wireshark of a failure showed that
Safari made no attempt to fetch, just errored.
Googling, I find MAC SAFARI had an update that
was recalled, circa my SSL certificate change.
Then I discovered a “SAFARI TECHNOLOGY PREVIEW”
which is the coming state of their art, and can
be downloaded next to plain SAFARI, just for an
Apple ID and agreeing to a developer agreement.
I got the current last version 114 for Catalina.
IT FAILED, IT FAILED, I AM SURE IT FAILED VERY
MANY TIMES while I honed in my canonical test:
about:blank
clear all history
https://personaltouchrecruiters.com/
clear all history
https://trump4all.us/
FAILS in SAFARI TECHNOLOGY PREVIEW version 114.
The first URL must be the bare CN domain.
The second URL is any other SAN domain url.
FWIW, TEMPERA theme has a slider on bare CN,
and slider keeps moving after clear history.
I briefly fiddled .htaccess to show bare.html:
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteCond %{HTTP_HOST} ^(www\.)?personaltouchrecruiters\.com$ [NC]
RewriteRule ^(.*)$ https://personaltouchrecruiters.com/bare.html [L,R=301]
And browsed rewritable http://www.personaltouchrecruiters.com/
which showed my trivial (html + jpg) page, but the test PASSED.
Also, a top URL to a similar “nivo” slider CN subpage PASSED:
https://personaltouchrecruiters.com/sliders/
Curiously, I was not seeing any initial TLS Handshake before
the TLS app data in my Wireshark captures of these failures.
So I figured the OS was playing some connection cache trick
beyond my savvy, and I rebooted the MAC, Wiresharking it all.
Thereafter the same canonical failing test started PASSING!
Furthermore, I went back to try the Plain-Old SAFARI app,
and now that same canonical failing test is PASSING too!
Now I am really done, because I lost the failure symptom.
Perhaps you too can first prove the canonical test fails,
then install SAFARI TECHNOLOGY PREVIEW version 114, also
doing a reboot, and then prove the canonical test passes.
And see whether your intermittent failures went away too.
If so, IMHO, GoDaddy is excused, the fault was in Safari.
Very interesting. Thank you for your diligence and for publishing your finding here. For SEO purposes, I’m going to insert this keyword: “SOLVED”. Just in case it helps anyone and is actually the solution.
Just got off the phone with Godaddy and the issue was not the 5 domain ssl cert but it was that I had old expired SSL on the system. By deleting the old ssl cert it was able to fix the misdirection request. Hope this helps someone before going through a ton of steps.
Great! Thank you for sharing. Hope it helps someone. This issue is, by far, the most popular blog post on my site. It’s apparently a real problem for a LOT of people.
Another fix…I had purchased the Wildcard SSL to cover all the sites on our subdomain oriented multi site, and then started seeing this on renewal.
I was on the phone with GoDaddy tech support for two hours. They finally realized I was on Enhance business hosting which comes with an ‘auto-SSL’ feature I was unaware of. We turned off the Wildcard, turned on the Auto-SSL, and -VOILA- no more MR errors!
So if you have a GODADDY plan, see if it comes with that, or if you can even swap Wildcard for Auto-SSL.
Although after reading the above, I had some outdated SSL certs on a few subs….I wonder if applying the new certificate to those would have fixed it too. But then I wouldn’t have received a $500 credit refund for my unnecessary Wildcard….
That’s fantastic! Thank you for sharing your solution. Little by little we are all chipping away at this mystery.
I am having the same problem with BlueHost with https://diantharau.com, a site that includes two sub-domains, and I am attempting to link from one to the other. The problem only occurs with Safari, not every time but almost every time.
It’s great to read an approach to the problem that is both common-sense and technically deep. I will hammer on BlueHost support for a solution, and attempt to get separate certificates assigned to each subdomain.
Thanks for the Bluehost report. Definitely keep on them to set this up correctly. Let us know how it goes! 🙂
Hi Rob, I came across your article here when I ran into this same problem, so I thought I’d leave a comment to explain the solution I found in my case.
The problem: when a cPanel account has a subdomain, navigating between the main site (like whatever.com or http://www.whatever.com) to the subdomain (like sub.whatever.com), the dreaded 421 “misdirected request” error keeps popping up in Safari.
The reason: the main account had a wildcard SSL certificate (from Let’s Encrypt). But the subdomain had its own SSL certificate too. This causes an issue where the main site has already loaded the wildcard certificate, but when navigating to the subdomain, it tries to use the same wildcard certificate when it should be using the subdomain’s certificate.
The solution (at least in my case): We had to get rid of the wildcard certificate and make sure that the domain and subdomain each had their own non-wildcard certificates. This was not possible to do with Let’s Encrypt certificates, so we switched to cPanel-issued AutoSSL certificates. Works like a charm.
Thank you for the tips and information! Glad this worked out for your case and I hope it helps others.
Hi thanks for all the helpful comments above. I am having the same issue on UK2.net hosting. Would this affect google ranking? My rankings have dropped considerably over the last few months and I’ve only noticed this error message now. I am using a PositiveSSL Multi-Domain cert on my 9 sites.
I believe it could affect your ranking. Anytime there is an error message presented to the crawler, the ranking could suffer. Once you’ve solved the issue, you’ll be able to confirm (barring other changes) by watching the ranking to see if it improves.
Experiencing this now with GoDaddy multisite SSL, but it only pops up on mobile and only on one of my 6 domains. VERY frustrating. After an initial brush-off where they tried to blame my content, I’m hopefully getting escalated. I’ll report back soon.