# SNI Check **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](/en/documentation/platform/workloads/certificate-manager/certificates/) 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: ![Request routing decision algorithm](/assets/docs/images/uploads/request-decision.png) ### 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`](https://www.openssl.org/docs/man3.0/man3/X509_check_host.html) 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](/en/documentation/platform/connectors/troubleshooting/#a-request-receives-421-misdirected-request). > **Note** > > The comparison between `Host` and `ssl_server_name` is performed in a case-insensitive manner. Differences in letter casing alone do not trigger a `421` response. > **Note** > > When TLS session data cannot be retrieved, the platform proceeds normally rather than blocking the request. This fail-open behavior prevents legitimate traffic from being disrupted due to transient infrastructure conditions. --- ## 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](https://www.azion.com/en/support/). --- ## Related resources - [Certificates](/en/documentation/platform/workloads/certificate-manager/certificates.md): The certificates whose Common Name and Subject Alternative Names decide which hostnames pass the check. - [Troubleshoot Connectors](/en/documentation/platform/connectors/troubleshooting.md#a-request-receives-421-misdirected-request): How to find the requests that receive a 421 response and fix the certificate or the hostname. - [Real-Time Events](/en/documentation/platform/real-time-events.md): The logs that show the host and the TLS server name of each request. - [Connectors](/en/documentation/platform/connectors.md): What a connector does once a request passes the check and reaches your application.