diff --git a/posts/fix-apache-sni-behind-alb.html b/posts/fix-apache-sni-behind-alb.html new file mode 100644 index 0000000..782807d --- /dev/null +++ b/posts/fix-apache-sni-behind-alb.html @@ -0,0 +1,32 @@ + + + + Fix Apache 421 SNI Errors Behind AWS ALB + + + + + + + + + << back +

Fixing Apache SNI 421 Errors Behind AWS ALB

+

Understanding the Problem

+

+ 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. +

+

Solution

+

+ 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. +

+ +