https://bz.apache.org/bugzilla/show_bug.cgi?id=69743
--- Comment #8 from Yann Ylavic <ylavic....@gmail.com> --- Without an SNI provided by the client, there is nothing httpd can do to determine which vhost/configuration should be used to provide the correct certificate (and TLS authentication eventually) whenever multiple vhosts listen on the same ip:port. That's because reading the HTTP Host header necessarily has to happen after the TLS handshake/auth/decryption (and later renegotiation is not an option with TLSv1.3). So those connections fall back to the first vhost declared on the ip:port for the TLS handshake part, and if the request Host header finally matches a different vhost with a different TLS configuration it's rejected with AH02032. Before 2.4.64 the check was not accurate and would allow that, with security implications. I don't think it's fixable on the httpd side, besides maybe adding a new UnsafeNoSNIBypass flag to restore the old behaviour, which almost no one would use... Note that AH02032 is different from "SSLStrictSNIVHostCheck on" which dissallows connections with no SNI to access any vhost, while the default allows to reach all the vhosts with the same TLS configuration than the first vhost (hence wildcard certs work). -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
