SNI Check
See when Azion answers an HTTPS request with 421 Misdirected Request because the SNI and Host header match no certificate on the workload.
SNI Check is a security enforcement mechanism built into the Azion Web Platform that validates the Server Name Indication (SNI) field of incoming HTTPS requests against the TLS certificate configured for the matching workload. When a mismatch is detected and the certificate cannot cover the requested hostname, the platform returns an HTTP 421 Misdirected Request response, preventing the request from being served under an incorrect security context.
What is SNI and why it matters
Server Name Indication (SNI) is a TLS extension that allows a client to specify the hostname it intends to reach during the TLS handshake, before the server sends its certificate. This enables a single server to host multiple TLS-enabled workloads on the same IP address, each with its own certificate.
On the Azion Web Platform, each workload is associated with a Certificate Manager entry. When a client establishes a TLS connection, the platform uses the SNI value to select the appropriate certificate. If the HTTP Host header used in the subsequent request does not match the certificate’s covered names (Common Name or Subject Alternative Names), the request is considered misdirected.
Request routing decision algorithm
For every incoming request, the platform applies the following decision logic to determine whether to serve the request normally or return a 421 response:
Decision steps explained
| Step | Condition | Outcome |
|---|---|---|
| 1 | Request is not HTTPS | Proceed normally — SNI check does not apply to plain HTTP |
| 2 | Host header matches ssl_server_name (case-insensitive) | Proceed normally — SNI and Host are consistent |
| 3 | ssl_server_name is empty | Proceed normally — no SNI was sent by the client |
| 4 | Workload is on the latest platform version and has a domain configured for the SNI value | Proceed normally — the SNI resolves to a known workload |
| 5 | Workload is on the latest platform version, no domain matches, and enforcement is enabled | Return 421 Misdirected Request |
| 6 | Workload is on the latest platform version, no domain matches, and enforcement is disabled | Proceed normally |
| 7 | TLS session data is unavailable | Proceed normally — the platform fails open to avoid disrupting legitimate traffic |
| 8 | Certificate is an Azion-managed certificate | Proceed normally — Azion certificates are trusted by the platform |
| 9 | X509_check_host confirms the Host is valid for the certificate | Proceed normally — the certificate covers the requested hostname |
| 10 | None of the above conditions are met and enforcement is enabled | Return 421 Misdirected Request |
| 11 | None of the above conditions are met and enforcement is disabled | Proceed normally |
The X509_check_host enforcement
The validation step uses OpenSSL’s X509_check_host function to verify whether the Host header value is covered by the certificate’s CN (Common Name) or SANs (Subject Alternative Names). This check is enforced for all workloads on the Azion Web Platform when SNI Check enforcement is enabled.
If the hostname is not within the certificate’s scope — for example, the certificate covers example.com but the request targets api.other-domain.com — the platform returns 421 Misdirected Request.
For more information on finding and fixing the requests that receive a 421 response, refer to Troubleshoot Connectors.
Enforcement scope
Enforcing strict SNI validation significantly reduces the risk of SNI Spoofing attacks, in which a malicious actor manipulates the SNI field to route a TLS connection through a certificate that does not legitimately cover the target hostname. By returning 421 Misdirected Request in these cases, the Azion Web Platform ensures that each HTTPS request is served only under a valid and appropriate security context.
SNI Check enforcement is not configurable through the Azion Console or the API. To enable or disable it for your workloads, contact Azion Support.