• Plesk Uservoice will be deprecated by October. Moving forward, all product feature requests and improvement suggestions will be managed through our new platform Plesk Productboard.
    To continue sharing your ideas and feedback, please visit features.plesk.com

Issue 421 Misdirected Request on Apache-only Plesk server after recent Apache update (CVE-2025-23048)

NatuurlijkHosting

New Pleskian
Server operating system version
CloudLinux 8.10
Plesk version and microupdate number
18.0.73 #2
Hi all,


We’re seeing the following issue on a shared hosting server that runs Apache-only (no Nginx proxy):
When Cloudflare Proxy is enabled, affected websites instantly return:
421 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.

When the Cloudflare proxy is turned off, the websites start loading normally again.


The problem affects only a small number of domains that use Cloudflare proxy.
Domains not behind Cloudflare continue to work fine. However, we do see a continuoes stream of SNI warnings in the apache errorlog for seemingly every domain and subdomain on the server.

This is the setup:
  • OS: CloudLinux 8.10
  • Plesk: Obsidian 18.0.73 Update #2
  • Web stack: Apache only (Nginx disabled)
  • SSL:
    • Each domain has its own valid Let’s Encrypt certificate configured in Plesk.
    • We have selected the default /fallback certificate for both "Certificate for securing Plesk" and "Certificate for securing mail" in the SSL/TLS settings within plesk.
    • The default certificate is a wildcard certificate that we use for securing all of our servers hostnames.
Symptoms/checks:
  • apachectl -S shows fallback/default vhost responding on port 443 instead of the vhost for the requested SNI
  • Apache error log contains large numbers of warnings:
    AH01909: server certificate does NOT include an ID which matches the server name
  • Any online and local checks we've done on certificates of some of the main domains on the server show that their first certificate corresponds correctly with the Let's Encrypt certificate of their respective domains. The second certificate (referred to as #2 on SSLlabs) shows a mismatch because it uses the default certificate.
  • All of the "mail." subdomain checks return an SNI mismatch instantly.
  • The issue seems to have started after the recent Apache update related to CVE-2025-23048 but appears to have been invicible untill the cloudflare proxy of a particular website was enabled
  • I've seen some similar looking issues on the forum, but Nginx workarounds are not applicable, since Nginx is not used here at all

So in summary:

Expected behavior is:
  • Cloudflare → SNI → correct Apache VirtualHost selected
Actual current behavior on this server is:
  • Cloudflare → SNI → Apache selects default vhost → certificate mismatch → Cloudflare blocks → 421 error
Questions
  1. Could this be an Apache-only variant of the same issue referenced in PPS-18041 / recent CVE fixes?
  2. Is there a recommended fix or hotfix for setups that do not use Nginx reverse proxy?
  3. Could it be that we misinterpreted the way the servers SSL/TLS settings need to be setup?
  4. Is there a bulletproof way to check why the server seems to be pulling the wrong vhosts?

Any guidance from the Plesk team or others who run Apache-only environments would be much appreciated!


Thank you!
 
apachectl -S 2>/dev/null | grep -Ei "default" | grep -Ei "443" gave us 4 different entries:
- two of which are located in the /etc/httpd/conf/plesk.conf.d/ip_default/[servername].conf
- and two others (with names like default-[ipv4], and default-[ipv6]) inside the /etc/httpd/conf/plesk.conf.d/server.conf.
Am I right in assuming there should only be 2 returned or is this to be expected when you install a custom certificate?
 
And can anyone tell me if there have been issues when performing # plesk repair web -sslcerts? Most of the time the plesk repair tools work nicely, but I don't want to risk making things worse in this particular case.
 
Back
Top