A recent update in Apache 2.4.64 introduced a CVE fix related to SNI (Server Name Indication), which inadvertently caused "HTTP 421 Misdirected Request" errors in many common reverse proxy configurations.
Solution
Reverse proxies must now be configured to comply with the stricter SNI behavior introduced in the update.
CDNs (e.g., Cloudflare, Bunny, QUIC.cloud, etc.) needed to ensure compatibility with Apache’s new handling of SNI information, as not all of them initially sent the correct/full SNI.
Plesk, cPanel and WP Squared (via ea-nginx) required the following adjustments:
Use HTTP/1.0 as the proxy protocol instead of HTTP/1.1.
Disable SSL session reuse for proxying.
Alternative approaches exist, but they have so far introduced greater performance drawbacks and security vulnerabilities.
Potential Impact
Some HTTP/1.1 features may be affected. These impacts should be transparent (i.e., not result in outright errors).
Performance may be slightly degraded due to the lack of SSL session reuse. This is more noticeable on servers hosting multiple virtual hosts on the same IP address (where SNI is relevant).
Note: If you use a proxy in your server's configuration we highly recommend that you verify your setup ahead of time. Please refer to the section below "Verifying The Impact Prior to August 11 Release" for more information. If the problem persists after you have checked your front end and you have confirmed you have the latest ea-nginx package, you'll need to disable or fix any custom SSL/TLS configuration settings for Apache and Nginx on the system.
Reverse proxies must now be configured to comply with the stricter SNI behavior introduced in the update.
CDNs (e.g., Cloudflare, Bunny, QUIC.cloud, etc.) needed to ensure compatibility with Apache’s new handling of SNI information, as not all of them initially sent the correct/full SNI.
Plesk, cPanel and WP Squared (via ea-nginx) required the following adjustments:
Use HTTP/1.0 as the proxy protocol instead of HTTP/1.1.
Disable SSL session reuse for proxying.
Alternative approaches exist, but they have so far introduced greater performance drawbacks and security vulnerabilities.
Potential Impact
Some HTTP/1.1 features may be affected. These impacts should be transparent (i.e., not result in outright errors).
Performance may be slightly degraded due to the lack of SSL session reuse. This is more noticeable on servers hosting multiple virtual hosts on the same IP address (where SNI is relevant).
Note: If you use a proxy in your server's configuration we highly recommend that you verify your setup ahead of time. Please refer to the section below "Verifying The Impact Prior to August 11 Release" for more information. If the problem persists after you have checked your front end and you have confirmed you have the latest ea-nginx package, you'll need to disable or fix any custom SSL/TLS configuration settings for Apache and Nginx on the system.
Updating to the August 11 Release
Undo any workarounds applied previously. If you've followed previous guidance and installed the file "/etc/nginx/conf.d/fixssl.conf," be sure to remove it before proceeding.
Update ea-apache24 to v2.4.65-1 and ea-nginx to v1.26.3-13.
To update via DNF manually ( AlmaLinux ):
To update via YUM manually ( CentOS ):
To update via apt manually ( Ubuntu ):
Post Update:
If you proxy from ea-nginx or CloudFlare you should no longer experience 421s.
Other proxy setups appear to be unaffected, but may still require adjustments similar to those made for ea-nginx and Cloudflare to function properly.
If you want to verify your setup ahead of time, see the section below "Verifying The Impact Prior to August 11 Release".
What happens if I pin cPanel & WHM to the current version so I don’t get the update?
Your server will be vulnerable to the noted CVEs until you unpin and upgrade.
Undo any workarounds applied previously. If you've followed previous guidance and installed the file "/etc/nginx/conf.d/fixssl.conf," be sure to remove it before proceeding.
Update ea-apache24 to v2.4.65-1 and ea-nginx to v1.26.3-13.
To update via DNF manually ( AlmaLinux ):
dnf clean all
dnf update ea-*
To update via YUM manually ( CentOS ):
yum clean all
yum update ea-*
To update via apt manually ( Ubuntu ):
apt clean && apt update
apt upgrade
Post Update:
If you proxy from ea-nginx or CloudFlare you should no longer experience 421s.
Other proxy setups appear to be unaffected, but may still require adjustments similar to those made for ea-nginx and Cloudflare to function properly.
If you want to verify your setup ahead of time, see the section below "Verifying The Impact Prior to August 11 Release".
What happens if I pin cPanel & WHM to the current version so I don’t get the update?
Your server will be vulnerable to the noted CVEs until you unpin and upgrade.
Verifying The Impact Prior to August 11 Release
Note: If you do this, you will need to undo it prior to/soon after actual release.
To safely test the updated Apache and NGINX configuration before deploying to production, follow these instructions:
1.) Set up the temporary package repository:
For servers that use RPM .repo files:
The .repo file can be found here: http://ea4testing.cpanel.net/Apache-2.4.64-421.repo
To configure please perform the following steps:
For servers that use Deb .list files:
Ubuntu 24.04: http://ea4testing.cpanel.net/Apache-2.4.64-421.xUbuntu_24.04.list
Ubuntu 22.04: http://ea4testing.cpanel.net/Apache-2.4.64-421.xUbuntu_22.04.list
Ubuntu 20.04: http://ea4testing.cpanel.net/Apache-2.4.64-421.xUbuntu_20.04.list
Note: You can ignore apt update’s gpg warning, which will look similar to this:
W: GPG error: http://ea4testing.cpanel.net/Apache-2.4.64-421/xUbuntu_22.04 ./ InRelease: The following signatures were invalid: BADSIG ACFD2F50F8D0C701 EA4 Tool (This is used by `et pub` to sign debs) <ea4-tool@cpanel>
Also you may need to adjust permissions on the file /etc/apt/trusted.gpg.d/ea4testing.gpg
2.) Get the new packages in place:
Undo any workarounds applied previously.
Update ea-apache24 to v2.4.65-1 and ea-nginx to v1.26.3-13.
3.) Perform tests:
The specifics of this will vary greatly based on your needs, environment, ability, etc. The basic idea is to try things important to you under this setup and see how it behaves.
Note: If you do this, you will need to undo it prior to/soon after actual release.
To safely test the updated Apache and NGINX configuration before deploying to production, follow these instructions:
1.) Set up the temporary package repository:
For servers that use RPM .repo files:
The .repo file can be found here: http://ea4testing.cpanel.net/Apache-2.4.64-421.repo
To configure please perform the following steps:
wget http://ea4testing.cpanel.net/Apache-2.4.64-421.repo -O /etc/yum.repos.d/Apache-2.4.64-421.repo
yum clean all
For servers that use Deb .list files:
Ubuntu 24.04: http://ea4testing.cpanel.net/Apache-2.4.64-421.xUbuntu_24.04.list
wget http://ea4testing.cpanel.net/Apache-2.4.64-421.xUbuntu_24.04.list -O /etc/apt/sources.list.d/Apache-2.4.64-421.xUbuntu_24.04.list
curl -fsSL http://ea4testing.cpanel.net/Apache-2.4.64-421/xUbuntu_24.04/Release.key | gpg --yes --dearmor | gpg --no-default-keyring --keyring gnupg-ring:/etc/apt/trusted.gpg.d/ea4testing.gpg --import
apt update
Ubuntu 22.04: http://ea4testing.cpanel.net/Apache-2.4.64-421.xUbuntu_22.04.list
wget http://ea4testing.cpanel.net/Apache-2.4.64-421.xUbuntu_22.04.list -O /etc/apt/sources.list.d/Apache-2.4.64-421.xUbuntu_22.04.list
curl -fsSL http://ea4testing.cpanel.net/Apache-2.4.64-421/xUbuntu_22.04/Release.key | gpg --yes --dearmor | gpg --no-default-keyring --keyring gnupg-ring:/etc/apt/trusted.gpg.d/ea4testing.gpg --import
apt update
Ubuntu 20.04: http://ea4testing.cpanel.net/Apache-2.4.64-421.xUbuntu_20.04.list
wget http://ea4testing.cpanel.net/Apache-2.4.64-421.xUbuntu_20.04.list -O /etc/apt/sources.list.d/Apache-2.4.64-421.xUbuntu_20.04.list
curl -fsSL http://ea4testing.cpanel.net/Apache-2.4.64-421/xUbuntu_20.04/Release.key | gpg --yes --dearmor | gpg --no-default-keyring --keyring gnupg-ring:/etc/apt/trusted.gpg.d/ea4testing.gpg --import
apt update
Note: You can ignore apt update’s gpg warning, which will look similar to this:
W: GPG error: http://ea4testing.cpanel.net/Apache-2.4.64-421/xUbuntu_22.04 ./ InRelease: The following signatures were invalid: BADSIG ACFD2F50F8D0C701 EA4 Tool (This is used by `et pub` to sign debs) <ea4-tool@cpanel>
Also you may need to adjust permissions on the file /etc/apt/trusted.gpg.d/ea4testing.gpg
2.) Get the new packages in place:
Undo any workarounds applied previously.
Update ea-apache24 to v2.4.65-1 and ea-nginx to v1.26.3-13.
3.) Perform tests:
The specifics of this will vary greatly based on your needs, environment, ability, etc. The basic idea is to try things important to you under this setup and see how it behaves.
- Page :
- 1
There are no replies made for this post yet.