421 Misdirected Request

Question

I occasionally get the following 421 error:

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.

However, refreshing the browser clears the error and the page loads normally. The next time loading the page will not produce and error and as such the pattern seems pretty random. The only pattern I can see is that this may happen When I am redirecting a page using header("Location: " . $url);

I have a PositiveSSL Multi-Domain Certificate from Comodo. My servers are Apache on a shared web hosting service so I don't have access to the configuration.

I load pages from one domain and within the page are links to a second domain on the certificate.

Everything I've read regarding this error seems to point to this problem being related to this being a multi-domain certificate.

What I would like to know is if there is anything on the web page (php) coding side of things that can cause this (and can be fixed) or if it is a configuration error or possibly a server error and only my hosting service can fix it.

My hosting service has so far been unable to provide anything and requested calling back with the exact time it happens next so they can research it. Any help would be appreciated as I am not overly confident they can figure this out.

UPDATE Ok, almost a couple of years later and decided it was time to deal with it. I was able to get most of the problems resolved by removing my static domains which served images and javascript. However, I was still using a second domain for some of this content and Safari in particular was still giving me problems.

I did more research and came across another article that talks about it here. Exactly what @Kevin describes. The article confirmed that it happens in Safari. So taking the advice, I set about getting separate certificates for each domain. I am on a shared host (Webhostinghub) and discovered they now offer free SSL (AutoSSL) that auto renews. It sounded to good to be true. They set me up with 5 free certificates. So far so good. I may even try to re-enable the static domains to test. If this all works, I'll save $ to boot as a bonus and let my Comodo certificates expire in July.

Are you hosting multiple websites on the same Apache server AND using the same SSL certificate AND the error happens when switching between these domain names? — John Hanley, Jun 17 '18 at 13:33
If the answer is YES, check if the IP address for each domain maps to the same virtual server. If YES, then you have two choices (that I can think of): 1) Issue separate SSL certificates for each domain name. 2) Move the web servers for each domain to be on different servers (different IP addresses). Given that you are on shared hosting, option 1 is probably the best solution. You can test this solution using Let's Encrypt to issue several free certificates to install on the other web servers. — John Hanley, Jun 17 '18 at 13:43
@JohnHanley - re #1, yes it is the same SSL with 6 domains in it. It's not easy to tell exactly when the error happens. The main scenario is that I'm on one domain pulling content (images and js) from two other domains. Re #2: IP address is definitely the same - I gather issuing separate certificates each domain name would be quite more expensive. I looked into Let's Encrypt but it is not supported by my provider. My provider has in the past 6 months offered free certificates, so when renewal comes up this month, I will switch and see what happens. Re #3 - they can't disable mod_http2. Thanks — mseifert, Jun 17 '18 at 19:16
Actually, all providers support Let's Encrypt unless they specifically block it. SSL certificates are the same no matter where you get them. The only difference is the type of validation (DV, OV, EV) and the file packaging / format. Apache is so popular that everyone supports them. As long as your vendor supports you uploading your own cert (certificate and private key) you can use DNS validation to get around them. If they don't support uploading your own cert, then I would switch vendors. — John Hanley, Jun 17 '18 at 21:05
@JohnHanley - Yes, I read through the docs and it seems so. The downside is that there is not automatic support for renewing. Let's Encrypt is 90 days and that seems too often to manually have to deal with it. It's moot, I hope, since my vendor is now providing it free. Thanks again. — mseifert, Jun 18 '18 at 03:04

score 22 · Accepted Answer · edited Oct 07 '21 at 07:34

This is caused by the following sequence of events:

The server and client both support and use HTTP/2.
The client requests a page at foo.example.com.
During TLS negotiation, the server presents a certificate which is valid for both foo.example.com and bar.example.com (and the client accepts it). This could be done with a wildcard certificate or a SAN certificate.
The client reuses the connection to make a request for bar.example.com.
The server is unable or unwilling to support cross-domain connection reuse (for example because you configured their SSL differently and Apache wants to force a TLS renegotiation), and serves HTTP 421.
The client does not automatically retry with a new connection (see for example Chrome bug #546991, now fixed). The relevant RfC says that the client MAY retry, not that it SHOULD or MUST. Failing to retry is not particularly user-friendly, but might be desirable for a debugging tool or HTTP library.

Event #6 is out of your control, but depending on the server's software, #5 may be fixable. Consult your server's HTTP/2 documentation for more information on how and when it sends HTTP 421. Alternatively, you could issue separate certificates for each domain, but that creates more administrative overhead and may not be worth it. You could also turn off HTTP/2 entirely, but that's probably overkill in most cases.

I have a Comodo PositiveSSL Multi-Domain certificate - which is indeed a single SSL Certificate. Going to separate certificates is a significant effort and/or expense at this point. The main problems were coming with attempting to have static cookieless domains to serve my images. It wasn't worth the number of 421s I was getting. For the time being, I've disabled the static domains. I still have some sharing of resources between domains, but the number of 421s has dropped drastically. Not currently worth the supposed efficiency. Someday, I'll test out your recommendation when I have more time. — mseifert, Nov 02 '18 at 00:32
Thank you for the detailed explanation. While this is quite an annoying problem (and you only notice it when using Safari, largely), I find the chain of events that lead to this problem quite interesting :) — fritzmg, Jan 30 '19 at 13:26
This a very nice summary (upvoted) but the 421 error can occur with HTTP/1.1 - its an issue with SNI, not specifically HTTP2. https://lampe2e.blogspot.com/2020/06/http2-and-421-errors.html — symcbean, Jun 13 '20 at 10:33

score 1 · Answer 2 · answered May 16 '19 at 07:40

Maybe this will be helpful to someone.

I got this error when I tried to change my apache virtual host configuration to HTTPS but only changed port from 80 to 443 and forgot to add

   SSLEngine on
   SSLCertificateFile "/opt/lampp/htdocs/localhost.crt"
   SSLCertificateKeyFile "/opt/lampp/htdocs/localhost.key"

Configuration causing error 421:

<VirtualHost mydoamin.local:443>   <-- fistly I 
       DocumentRoot "/opt/lampp/htdocs/mydomain/"
       ServerName www.mydomain.local
</VirtualHost>

The correct configuration:

<VirtualHost mydoamin.local:443>
       DocumentRoot "/opt/lampp/htdocs/mydomain/"
       ServerName www.mydomain.local
       SSLEngine on
       SSLCertificateFile "/opt/lampp/htdocs/localhost.crt"
       SSLCertificateKeyFile "/opt/lampp/htdocs/localhost.key"
</VirtualHost>

score 0 · Answer 3 · answered May 09 '20 at 18:20

We observed the same issue with Safari (Desktop and iPhone) on some websites using Debian 10 with Apache.

Software:

Debian 10
Apache2 2.4.38-3+deb10u3 with HTTP/2
PHP 7.3.14-1~deb10u1 with php-fpm

Domains:

www.example.com
a.example.com
b.example.com
all domains are pointing to the same DocumentRoot

Certificate:

One certificate for all used domains
Issuer is DFN PKI

The solution was quite easy but it took much effort to find it. At the end it was trial an error.

Configuration causing error 421:

    # in /etc/apache2/site-enabled/www.example.com.conf
    SSLCertificateFile      /etc/apache2/ssl/www.example.com/cert-123.pem
    SSLCertificateKeyFile   /etc/apache2/ssl/www.example.com/www.example.com.key

    # in /etc/apache2/site-enabled/a.example.com.conf
    SSLCertificateFile      /etc/apache2/ssl/a.example.com/cert-123.pem
    SSLCertificateKeyFile   /etc/apache2/ssl/a.example.com/www.example.com.key

    # in /etc/apache2/site-enabled/b.example.com.conf
    SSLCertificateFile      /etc/apache2/ssl/b.example.com/cert-123.pem
    SSLCertificateKeyFile   /etc/apache2/ssl/b.example.com/www.example.com.key

Working configuration:

    # in /etc/apache2/site-enabled/www.example.com.conf
    SSLCertificateFile      /etc/apache2/ssl/www.example.com/cert-123.pem
    SSLCertificateKeyFile   /etc/apache2/ssl/www.example.com/www.example.com.key

    # in /etc/apache2/site-enabled/a.example.com.conf
    SSLCertificateFile      /etc/apache2/ssl/www.example.com/cert-123.pem
    SSLCertificateKeyFile   /etc/apache2/ssl/www.example.com/www.example.com.key

    # in /etc/apache2/site-enabled/b.example.com.conf
    SSLCertificateFile      /etc/apache2/ssl/www.example.com/cert-123.pem
    SSLCertificateKeyFile   /etc/apache2/ssl/www.example.com/www.example.com.key

Solution (in our case): It's not allowed to copy the same certificate and private key to different locations!

Before we copied the certificate to a VirtualHost specific directory. This results in the Misdirected Request behaviour only with Safari.

Unfortunately, I cannot explain you, why :-( (Apache2 bug? Safari bug? Safari feature?)

score 0 · Answer 4 · answered May 24 '21 at 13:05

It is only an issue on Safari, and due to the SSL certificate.

Many hosting providers give free certificates that are shared, and thus "www.site.com" and "site.com" will both share the same certificate.

When you setup your server to redirect all "site.com" requests to "www.site.com", this is where the issue occurs, as they both share the same certificate and Safari sees them as two different pages.

The only solution is to get a different certificate for each subdomain, something most hosting providers are a bit reluctant to do when letting you share these free certificates. Also, there is nothing wrong with sharing a certificate, and Safari should allow it.

In the meantime, harass Apple to fix the Safari bug.

score 0 · Answer 5 · answered Jun 14 '21 at 07:39

I had the same issue and the problem was with the server name, it was wrong

WRONG CONFIG:

<VirtualHost domain.name:443>

    ServerName domain.name2 # SERVER NAME NOT IDENTICAL TO VIRTUALHOST 
    DocumentRoot "/documents/"
    SSLEngine on
    SSLCertificateFile "/etc/apache2/ssl/domain.name.crt"
    SSLCertificateKeyFile "/etc/apache2/ssl/domain.name.key"
    
</VirtualHost>

The ServerName value must be the same as VirtualHost

When I changed to:

<VirtualHost domain.name:443>

    ServerName domain.name
    DocumentRoot "/documents/"
    SSLEngine on
    SSLCertificateFile "/etc/apache2/ssl/domain.name.crt"
    SSLCertificateKeyFile "/etc/apache2/ssl/domain.name.key"

</VirtualHost>

It all worked, hope it helps.

score -1 · Answer 6 · answered May 22 '19 at 13:56

-1

I had the same issue. Switching to two single-slot SSLs did the trick.

answered May 22 '19 at 13:56

Olivier

11

421 Misdirected Request

6 Answers6

Linked