7

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.

  • 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
  • Ask your hosting provider if they can disable mod_http2. – John Hanley Jun 17 '18 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 '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
8

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.

  • 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 '18 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 at 13:26
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>
-2

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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