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):
ServerName default.localhost
DocumentRoot /usr/local/apache2/htdocs/
ServerName service1.localhost
ServerAdmin webmaster@localhost
DocumentRoot /usr/local/apache2/htdocs/
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
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
Test:
2.4.64:
# curl -k -H 'Host: service1.localhost' https://127.0.0.1:8443
421 Misdirected Request
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.
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) 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
