Hi Yes, we're also seeing some different behaviour since the update to 2.4.64
To us, it seems like an incomplete fix that has unwanted side effects. This is the patch for CVE-2025-23048 -> https://github.com/apache/httpd/commit/c4cfa50c9068e8b8134c530ab21674e77d1278a2 How to reproduce: Simple vHost Config (default apache setup with SSL): <VirtualHost *:80> ServerName default.localhost DocumentRoot /usr/local/apache2/htdocs/ </VirtualHost> <VirtualHost *:80> ServerName service1.localhost ServerAdmin webmaster@localhost DocumentRoot /usr/local/apache2/htdocs/ </VirtualHost> <VirtualHost *:443> ServerName default.localhost DocumentRoot /usr/local/apache2/htdocs/ SSLEngine on SSLCertificateFile /usr/local/apache2/conf/default+1.pem SSLCertificateKeyFile /usr/local/apache2/conf/default+1-key.pem </VirtualHost> <VirtualHost *:443> ServerName service1.localhost ServerAdmin webmaster@localhost DocumentRoot /usr/local/apache2/htdocs/ SSLEngine on SSLCertificateFile /usr/local/apache2/conf/service1+1.pem SSLCertificateKeyFile /usr/local/apache2/conf/service1+1-key.pem </VirtualHost> Test: 2.4.64: # curl -k -H 'Host: service1.localhost' https://127.0.0.1:8443 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>421 Misdirected Request</title> </head><body> <h1>Misdirected Request</h1> <p>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.</p> </body></html> 2.4.63: # curl -k -H 'Host: service1.localhost' https://127.0.0.1:8443 Hi 2.4.63% If I understand the config option "SSLStrictSNIVHostCheck" correctly, the default has been (unintentionally) changed with version 2.4.64? - Pascal > On 15.07.2025 00:57 CEST Dan Mahoney (Gushi) <d...@prime.gushi.org> wrote: > > > On Fri, 11 Jul 2025, Pavel Matěja wrote: > > > Hi, > > I've just updated Apache to the 2.4.64 version and it's kind of strange. > > I used to got proper response from Apache with multiple virtual hosts. > > > > When I tested using > > openssl s_client -connect A.B.C.D:443 -crlf -noservername > > after upgrade I got: > > > > 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." > > > > But as the s_client had -noservername parameter there was no SNI hostname > > at > > all. > > > > There is > > AH02032: Hostname our_first_vhost.test.com (default host as no SNI was > > provided) and hostname hostname_from_s_client_header.test.com provided via > > HTTP have no compatible SSL setup > > in Apache error log. > > > > I had to enable SNI in Nagios checks, etc. > > > > Was this intended? > > Also seeing this issue over at the dayjob (we make a DNS server > software and run a root DNS server?) If it matters at all, we're hitting > this under FreeBSD 14.2 or 14.3 (they use the same packages). If someone > from the devteam wants to contact me privately, I can send my configs. > > I would guess that the fixes for CVE-2025-23048 and possibly > CVE-2024-47252 broke this (both mention SNI in the release notes). > > It would appear that this is a regression, as the previous behavior > without specifying an SNI would be that the "first" virtual host would be > used. > > In our particular case, it's normal for us to configure a "Just make sure > apache is answering on port 443, we don't care about the site or cert, a > redirect over ssl is a perfectly valid answer" health check, before > drilling down and checking the state of certs/expiry/http response codes > for individual vhosts. > > (We do the same sort of check with http -- we just care that it answers, > and a redirect is fine, but an http error is not). > > Reading through the config knobs, Did the default value of > SSLStrictSNIVHostCheck change? > > Is the correct answer to make one of our ssl hosts more specifically the > default, by configuring a wildcard, or would that still depend on SNI > being present? > > (Also: > https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslstrictsnivhostcheck > should probably say which error code is returned in the event a client is > not > allowed). > > Should this perhaps have been mentioned in the release notes? > > -Dan > > -- > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org > For additional commands, e-mail: users-h...@httpd.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
