This commit is contained in:
2026-07-20 21:42:12 -06:00
parent 3a781a129a
commit e6befea75e

View File

@@ -0,0 +1,32 @@
<!DOCTYPE html>
<html>
<head>
<title>Fix Apache 421 SNI Errors Behind AWS ALB</title>
<meta content="Description of post" name="description">
<meta name="robots">
<meta content="keywords" name="Apache SNI Fix 421">
<meta content="description" name="How to fix the Apache SNI issues (421 misdirected) behind AWS ALB">
<meta charset="utf-8" content="utf-8" name="charset">
<link href="/index.css" rel="stylesheet">
</head>
<body>
<a href="/">&lt;&lt; back</a>
<h1>Fixing Apache SNI 421 Errors Behind AWS ALB</h1>
<h2>Understanding the Problem</h2>
<p>
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 <code>Host</code> 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.
</p>
<h2>Solution</h2>
<p>
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 <code>SSLVHostSNIPolicy</code> directive, setting it to <code>authonly</code> 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.
</p>
</body>
</html>