20

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.

Improve this question
6
  • 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, 2018 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, 2018 at 13:43
  • Ask your hosting provider if they can disable mod_http2.
    – John Hanley
    Jun 17, 2018 at 14:33
  • @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, 2018 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, 2018 at 21:05

6 Answers 6

Reset to default
25

This is caused by the following sequence of events:

  1. The server and client both support and use HTTP/2.
  2. The client requests a page at foo.example.com.
  3. 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.
  4. The client reuses the connection to make a request for bar.example.com.
  5. 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.
  6. 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.

Improve this answer
3
  • 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 2, 2018 at 0: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, 2019 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. lampe2e.blogspot.com/2020/06/http2-and-421-errors.html
    – symcbean
    Jun 13, 2020 at 10:33
1

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>
Improve this answer
0

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?)

Improve this answer
0

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.

Improve this answer
0

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.

Improve this answer
-1

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

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.