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. Apache/2.4.52

If you're managing several virtual hosts, it's crucial to maintain consistent SSL settings across all of them for smooth operation. This means using the identical SSL certificate and SSLCipherSuite for every virtual host, including the one designated as your default. Also, to prevent potential conflicts, verify that SSLStrictSNIVHostCheck is off in both your primary Apache configuration and each individual virtual host file. To identify which site Apache considers default, simply execute apache2ctl -S.

For seamless SSL functionality across your multiple virtual hosts, here's what to do:

• Standardize your SSL certificate and SSLCipherSuite: Apply the exact same ones to all your virtual hosts, including your default site.
• Disable Strict SNI Checking: Set SSLStrictSNIVHostCheck to off in your main Apache configuration and in every virtual host file.
• Identify Default Site: Use apache2ctl -S to confirm which site Apache is treating as the default.

@Oliver Valls Thanks for the response, we have started getting this issue after upgrading apache to 2.4.64 from 2.4.63. everything is working fine with 2.4.63. To this fix 421 midirected request issue we have downgraded apache to officially available 2.4.52-1ubuntu4.14 then apache upgraded to 2.4.52-1ubuntu4.15 after that all the websites are working fine for 3 days and now today we are getting the same error

Hi there, no provided solution is working except downgrading Apache which works as long as the version is available in repo. We're using few vhosts with separate certificate for each of them behind ALB.

From what I can determine, only downgrading Apache or chaging backend server certs to include all hostnames, actually fixes this at the moment. Anyone want to correct that statement?

The AI generated horse manure posted by "Makendra G" does not resolve this for me - or, I suspect, anyone else. But that does not stop other posts quoting it as having been "identified as community workarounds". Such as: https://repost.aws/questions/QUbWv0O9GoQ1yN1a9apWfH7Q/apache-2-4-46-elb

Anyone posting this AI bilge without testing should be ashamed of calling themselves "expert".

This issue appears to be related to a mismatch between the domain name in the request and the Server Name Indication (SNI) being used for the connection through your Application Load Balancer (ALB).

When you're receiving a "421 Misdirected Request" error with the message indicating that the requested host name doesn't match the SNI in use, it suggests there's a problem with how the HTTPS requests are being handled between your clients and the load balancer.

Here are some potential causes and solutions:

1. Certificate Configuration: Ensure that the SSL certificate on your ALB includes all the domain names you're serving as either the primary domain or Subject Alternative Names (SANs). If a domain is missing from the certificate, it could cause this type of error.

2. Host Header Listener Rules: Implement host header listener rules on your ALB to properly route traffic based on the domain name in the request. This ensures that if none of the listener rules match the client request host header, the default listener rule applies.

3. Monitor Access Logs: Check your ALB access logs for the requests to the unrecognized domain, specifically looking at the client:port and user_agent fields to get more details about where these requests are originating from.

4. DNS Configuration: Since the sites work when pointing directly to the server IP, verify that your DNS records are correctly pointing to the ALB and not elsewhere. Use tools like dig or nslookup to confirm proper DNS resolution.

5. Unknown Domain Requests: If you're receiving requests for domains you don't recognize, consider blocking the IP addresses that generate these requests in your network access control lists (ACLs).

The fact that the sites work when pointing directly to the server IP suggests that the issue is in the communication path through the ALB rather than with your Apache configuration. This could be related to how the ALB is handling the SNI information or how it's passing the requests to your backend instances.

Since you've already tried disabling HTTP/2, changing certificates, and restarting Apache, you might want to focus on the host header configuration in your ALB and ensure that all your domains are properly included in your SSL certificate.
Sources
Resolve requests with unknown domain names in ELB | AWS re:Post
Troubleshoot a Classic Load Balancer: Client connectivity - Elastic Load Balancing
EC2 HTTPS Requests Not Getting Through... | AWS re:Post

Hi All, is anyone fixed the issue by appliying the above solutions? or any further fix is available? pls share. as i am still facing same issue. Thanks in advance.

Amazon Linux 2 Auto upgrades all the packages whenever a new instance is launched. This is mentioned in their FAQ https://aws.amazon.com/amazon-linux-ami/faqs/#topic-1 Q: How do I disable the automatic installation of critical and important security updates on initial launch? Downgrading apache version to 2.4.62 fixed the issue for me. Downgrade to your previous working version..

#To Check updated packages on instance 
yum history info 376

#downgrade the httpd
yum downgrade httpd-2.4.62-1.amzn2.0.2 httpd-tools-2.4.62-1.amzn2.0.2 mod_ssl-2.4.62-1.amzn2.0.2  httpd-devel-2.4.62-1.amzn2.0.2 mod_session-2.4.62-1.amzn2.0.2 httpd-filesystem-2.4.62-1.amzn2.0.2

#to apply lock on specific version 
yum -y install yum-versionlock
sudo yum versionlock httpd-*

#to stop autoupgrade of the packages add below config in user-data (Autoscaling)

#cloud-config
repo_upgrade: none

The issue stems from the recent Apache upgrade (2.4.63 to 2.4.64) and its interaction with ALB. Your error logs show:

• Missing server name in TLS extension
• SSL handshake failures
• HTTP/HTTPS protocol mismatches

This behavior is documented in Apache's changelog and several community reports (Reference).

1. Apache Configuration Updates

SSLStrictSNIVHostCheck off
SSLOptions +StdEnvVars

# Update SSL Protocol Configuration
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384

• SSLStrictSNIVHostCheck off: This relaxes the strict SNI checking that's causing the misdirected request errors
• SSLOptions +StdEnvVars: Enables standard SSL environment variables needed for proper SSL/TLS handling
• The SSL Protocol configuration ensures secure communication while maintaining compatibility
• The cipher suite selection provides strong encryption while being compatible with modern browsers

Reference: https://httpd.apache.org/docs/2.4/ssl/ssl_howto.html

2. Essential Apache Modules

sudo a2enmod ssl
sudo a2enmod headers

• mod_ssl is crucial for handling HTTPS connections properly
• mod_headers allows manipulation of HTTP request and response headers, necessary for ALB integration

Reference: https://httpd.apache.org/docs/2.4/mod/mod_ssl.html

3. Header Configuration

RequestHeader set X-Forwarded-Proto "https"
RequestHeader set X-Forwarded-Port "443"

• These headers ensure proper protocol information is passed from ALB to Apache
• Helps Apache understand that the original request was HTTPS, preventing protocol confusion
• Critical for proper SSL/TLS handshake between client, ALB, and Apache

Reference: https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/x-forwarded-headers.html

4. ALB Configuration Review

Verify:

• SSL certificate in ACM includes all domain names

• Listener rules configuration

• Target group protocol settings

• Security group rules

• Mismatched certificates can cause SNI issues

• Incorrect listener rules can lead to routing problems

• Proper security group configuration is essential for traffic flow

References:

• https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html
• https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-target-groups.html

Additional Recommendations:

1. Backup & Testing

• Create an AMI of working configuration
• Test in staging environment
• Document changes

2. Monitoring Setup

• Enable ALB access logs
• Monitor Apache error logs
• Configure CloudWatch alarms

we have moved order of virtual host in apache config on server and getting below error: [Fri Jul 18 13:37:40.029296 2025] [ssl:info] [pid 1999485] [client 192.168.0.24:43302] AH01996: SSL handshake failed: HTTP spoken on HTTPS port; trying to send HTML error page [Fri Jul 18 13:37:40.029316 2025] [ssl:info] [pid 1999485] SSL Library Error: error:0A00009C:SSL routines::http request [Fri Jul 18 13:37:44.863890 2025] [ssl:info] [pid 1999502] [client 192.168.0.24:47098] AH01964: Connection to child 7 established (server searchunify.com:443) [Fri Jul 18 13:37:44.864060 2025] [ssl:debug] [pid 1999502] ssl_engine_kernel.c(2341): [client 192.168.0.24:47098] AH02645: Server name not provided via TLS extension (using default/first virtual host) [Fri Jul 18 13:37:44.865942 2025] [ssl:debug] [pid 1999502] ssl_engine_kernel.c(2170): [client 192.168.0.24:47098] AH02041: Protocol: TLSv1.3, Cipher: TLS_AES_256_GCM_SHA384 (256/256 bits) [Fri Jul 18 13:37:44.866115 2025] [ssl:debug] [pid 1999502] ssl_engine_kernel.c(341): [client 192.168.0.24:47098] AH02034: Initial (No.1) HTTPS request received for child 7 (server searchunify.com:443) [Fri Jul 18 13:37:44.866667 2025] [ssl:debug] [pid 1999502] ssl_engine_io.c(1147): [client 192.168.0.24:47098] AH02001: Connection closed to child 7 with standard shutdown (server searchunify.com:443) [Fri Jul 18 13:37:45.152958 2025] [ssl:info] [pid 1999488] [client 192.168.0.14:23316] AH01964: Connection to child 22 established (server searchunify.com:443) [Fri Jul 18 13:37:45.153117 2025] [ssl:debug] [pid 1999488] ssl_engine_kernel.c(2341): [client 192.168.0.14:23316] AH02645: Server name not provided via TLS extension (using default/first virtual host) [Fri Jul 18 13:37:45.155279 2025] [ssl:debug] [pid 1999488] ssl_engine_kernel.c(2170): [client 192.168.0.14:23316] AH02041: Protocol: TLSv1.3, Cipher: TLS_AES_256_GCM_SHA384 (256/256 bits)

I ran into the same issue recently, and in my case it wasn’t caused by an Apache upgrade - nothing had changed on that side. My suspicion is that something changed on the AWS side.

After spending hours testing different configurations (including downgrading the health check from HTTPS to HTTP), the only temporary fix I found was to roll Apache back from 2.4.65 to 2.4.62 (the only downgrade available).

However, the permanent solution turned out to be much simpler and didn’t require downgrading Apache at all: 👉 Use one SSL certificate for all hosts on the same server, with Subject Alternative Names (SANs) covering every domain.

In my setup, the server uses self-signed certificates that are never shown to end users - clients only see the AWS Load Balancer certificate. Once I switched to a single SAN certificate, everything worked perfectly and the configuration was actually simpler.

PS: Whenever you add a new host in Apache and in the AWS LB configuration, you’ll need to regenerate the certificate to include that domain.

I ran into the SNI error after Apache was upgraded on my servers and it affected my sites. Posting this in case it helps someone too. It appears that apache does not load the ssl_module when the ssl configuration uses ‘<IfModule mod_ssl>’
 after the recent upgrade.     <IfModule mod_ssl>
        SSLEngine on
        ...      </IfModule>

changing the ssl configuration to ' <IfModule mod_ssl.c>' or  ‘<IfModule ssl_module>’ loads the ssl_module and fixed the issue.

Sorry for my English.

I faced the same issue after upgrading Apache from 2.4.62 to 2.4.66 behind an ALB.

In my environment, the server handles many subdomains such as:

- abc.domain.com
- xyz.domain.com
- foo.sub.domain.com

After the upgrade, Apache started returning HTTP 421 errors because the ALB reuses backend HTTPS connections without sending SNI information consistently.

My workaround was reducing the number of SSL VirtualHosts and using wildcard-based VirtualHosts instead.

Example:

<VirtualHost *:443>
    ServerName sub.domain.com
    ServerAlias *.domain.com

    UseCanonicalName Off
    VirtualDocumentRoot /var/www/html/%1

    Include whatever
</VirtualHost>

<VirtualHost *:443>
    ServerName sub-sub.domain.com
    ServerAlias *.sub.domain.com

    UseCanonicalName Off
    VirtualDocumentRoot /var/www/html/%1

    Include whatever
</VirtualHost>

This reduced the number of SSL contexts significantly and solved the 421 issue in my case. Of course, this approach introduces some risks such as:

- Host Header Injection
- unexpected directory mapping
- invalid host access

So I recommend validating the Host header:

RewriteEngine On

RewriteCond %{HTTP_HOST} !^[a-z0-9-]+\.domain\.com$ [NC]
RewriteRule ^ - [F,L]

You can also validate hosts at the application layer.
For example, Laravel validates APP_URL and trusted hosts.

If your environment handles many custom domains with different SSL certificates, I think using NLB may be a better choice because NLB does TLS passthrough and does not create a new backend TLS connection without SNI like ALB does.

I am not sure whether this is the best solution, but it worked in my environment.
Please let me know if there are better approaches or concerns with this design.