SNI (Server Name Indicator) is a flag set in the "Client Hello" of a TLS request. It tells the server what domain you want,
without having to decrypt the request later to get the Host header, or whatever else you might be using to route traffic with.
Apache uses SNI to figure out what cert to use to decrypt the request. When SNI is missing, or Apache can't find a VHost associated
with the domain in the SNI, it will route to the default VHost for decryption and request handling. This is now the default behaviour in 2.4.64 and up,
it was applied to fix CVE-2025-23048. Note this is a good change, and means that Apache will reject potentially dangerous requests where SNI isn't the same as the Host header.
If you're using HTTPS on your Apache, behind an AWS ALB, you're going to run into this issue, because AWS ALB's seemingly don't set SNI at all.
The solution is to tell Apache to relax its policy, and allow the default VHost to decrypt the message,
and then route on the Host header to the next VHost (I think this is how it works, I could be wrong).
You can do this with the SSLVHostSNIPolicy directive, setting it to authonly will
return the pre 2.4.64 functionality, however it supposedly only works on 2.4.65, so you may have to skip 2.4.64.