aziontech · GabrielAzion · Jul 15, 2026
@@ -0,0 +1,109 @@
+---
+title: SNI Check
+description: >-
+  Understand how Azion validates Server Name Indication (SNI) against TLS certificates on incoming HTTPS requests, and how the enforcement of this check protects your workloads against SNI Spoofing attacks.
+meta_tags: 'SNI, TLS, HTTPS, certificate, misdirected request, 421, SNI spoofing, security, Connectors, Firewall'
+namespace: documentation_products_secure_edge_connector_sni_check
+permalink: /documentation/products/secure/connectors/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/products/secure/firewall/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:
+
+```
+IF (NOT HTTPS) THEN:
+    → Regular Request Flux
+
+ELSE IF (lowercase(Host) == lowercase(ssl_server_name)) THEN:
+    → Regular Request Flux
+
+ELSE IF (ssl_server_name == "") THEN:
+    → Regular Request Flux
+
+ELSE IF (Certificate is issued by Azion) THEN:
+    → Regular Request Flux
+
+ELSE IF (X509_check_host: Host is valid for the current certificate?) THEN:
+    → Regular Request Flux
+
+ELSE:
+    → 421 Misdirected Request
+```
+
+### 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 | Certificate is an Azion-managed certificate | Proceed normally — Azion certificates are trusted by the platform |
+| 5 | `X509_check_host` confirms the Host is valid for the certificate | Proceed normally — the certificate covers the requested hostname |
+| 6 | None of the above conditions are met | Return `421 Misdirected Request` |
+
+### The X509_check_host enforcement
+
+The final 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 now enforced for all workloads on the Azion Web Platform.
+
+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`.
+
+:::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.
+:::
+
+---
+
+## How to identify if your application is affected
+
+Monitor your application logs for HTTP `421 Misdirected Request` responses. This status code indicates that a request arrived over a TLS connection established for a different hostname than the one specified in the `Host` header, and the certificate in use does not cover that hostname.
+
+**Common scenarios that produce a `421` response:**
+
+- Web applications, APIs, or HTTP clients that reuse an existing TLS connection (connection pooling or HTTP/2 multiplexing) to send requests targeting a different hostname than the one used during the TLS handshake.
+- Clients that send a `Host` header pointing to a hostname not covered by the certificate associated with the TLS session.
+
+**How to investigate:**
+
+Use [Real-Time Events](/en/documentation/products/observe/real-time-events/) to filter requests with status code `421`. The event data will show the `host` and `ssl_server_name` fields, helping you identify which part of your application is sending requests with a hostname outside the scope of the certificate in use.
+
+---
+
+## How to fix SNI mismatches
+
+**Ensure your certificates cover all required hostnames.**
+
+Each hostname your application serves over HTTPS must be covered by the certificate associated with the corresponding workload on the Azion Web Platform. A certificate covers a hostname if that hostname appears in the certificate's CN or in its SAN list.
+
+Recommended actions:
+
+- Review the certificates configured in [Certificate Manager](/en/documentation/products/secure/firewall/certificate-manager/) for each of your workloads.
+- If a workload serves multiple hostnames, use a wildcard certificate (e.g., `*.example.com`) or a multi-SAN certificate that explicitly lists all required hostnames.
+- Investigate any `421` responses in Real-Time Events to identify which hostname is being requested outside the certificate's scope, then update the certificate or the application's connection logic accordingly.
+
+---
+
+## Why this enforcement matters
+
+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.
+
+---
+
+## Related resources
+
+- [Certificate Manager](/en/documentation/products/secure/firewall/certificate-manager/)
+- [Connectors](/en/documentation/products/secure/connectors/)
+- [Real-Time Events](/en/documentation/products/observe/real-time-events/)
+- [HTTP 421 Misdirected Request — MDN Web Docs](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/421)
@@ -0,0 +1,109 @@
+---
+title: SNI Check
+description: >-
+  Entenda como a Azion valida o Server Name Indication (SNI) em relação aos certificados TLS nas requisições HTTPS recebidas e como a aplicação dessa verificação protege seus workloads contra ataques de SNI Spoofing.
+meta_tags: 'SNI, TLS, HTTPS, certificado, misdirected request, 421, SNI spoofing, segurança, Connectors, Firewall'
+namespace: documentation_products_secure_edge_connector_sni_check
+permalink: /documentacao/produtos/secure/connectors/sni-check/
+---
+
+O **SNI Check** é um mecanismo de segurança integrado à Azion Web Platform que valida o campo Server Name Indication (SNI) das requisições HTTPS recebidas em relação ao certificado TLS configurado para o workload correspondente. Quando uma incompatibilidade é detectada e o certificado não cobre o hostname solicitado, a plataforma retorna uma resposta HTTP `421 Misdirected Request`, impedindo que a requisição seja servida em um contexto de segurança incorreto.
+
+---
+
+## O que é SNI e por que é importante
+
+O **Server Name Indication (SNI)** é uma extensão do TLS que permite ao cliente especificar o hostname que deseja acessar durante o handshake TLS, antes que o servidor envie seu certificado. Isso permite que um único servidor hospede múltiplos workloads com TLS habilitado no mesmo endereço IP, cada um com seu próprio certificado.
+
+Na Azion Web Platform, cada workload está associado a uma entrada no [Certificate Manager](/pt-br/documentacao/produtos/secure/firewall/certificate-manager/). Quando um cliente estabelece uma conexão TLS, a plataforma usa o valor do SNI para selecionar o certificado apropriado. Se o cabeçalho HTTP `Host` utilizado na requisição subsequente não corresponder aos nomes cobertos pelo certificado (Common Name ou Subject Alternative Names), a requisição é considerada misdirected.
+
+---
+
+## Algoritmo de decisão de roteamento de requisições
+
+Para cada requisição recebida, a plataforma aplica a seguinte lógica de decisão para determinar se a requisição deve ser servida normalmente ou se deve retornar `421`:
+
+```
+SE (NÃO é HTTPS) ENTÃO:
+    → Fluxo de Requisição Normal
+
+SENÃO SE (lowercase(Host) == lowercase(ssl_server_name)) ENTÃO:
+    → Fluxo de Requisição Normal
+
+SENÃO SE (ssl_server_name == "") ENTÃO:
+    → Fluxo de Requisição Normal
+
+SENÃO SE (Certificado emitido pela Azion) ENTÃO:
+    → Fluxo de Requisição Normal
+
+SENÃO SE (X509_check_host: Host é válido para o certificado atual?) ENTÃO:
+    → Fluxo de Requisição Normal
+
+SENÃO:
+    → 421 Misdirected Request
+```
+
+### Explicação das etapas de decisão
+
+| Etapa | Condição | Resultado |
+|-------|----------|-----------|
+| 1 | A requisição não é HTTPS | Prossegue normalmente — o SNI Check não se aplica a HTTP simples |
+| 2 | O cabeçalho `Host` corresponde ao `ssl_server_name` (sem distinção de maiúsculas/minúsculas) | Prossegue normalmente — SNI e Host são consistentes |
+| 3 | `ssl_server_name` está vazio | Prossegue normalmente — nenhum SNI foi enviado pelo cliente |
+| 4 | O certificado é gerenciado pela Azion | Prossegue normalmente — certificados da Azion são confiáveis pela plataforma |
+| 5 | `X509_check_host` confirma que o Host é válido para o certificado | Prossegue normalmente — o certificado cobre o hostname solicitado |
+| 6 | Nenhuma das condições acima é atendida | Retorna `421 Misdirected Request` |
+
+### A aplicação do X509_check_host
+
+A etapa final de validação utiliza a função [`X509_check_host`](https://www.openssl.org/docs/man3.0/man3/X509_check_host.html) do OpenSSL para verificar se o valor do cabeçalho `Host` está coberto pelo CN (Common Name) ou pelos SANs (Subject Alternative Names) do certificado. Essa verificação agora é aplicada para todos os workloads na Azion Web Platform.
+
+Se o hostname não estiver dentro do escopo do certificado — por exemplo, o certificado cobre `example.com`, mas a requisição tem como alvo `api.outro-dominio.com` — a plataforma retorna `421 Misdirected Request`.
+
+:::note
+A comparação entre `Host` e `ssl_server_name` é realizada sem distinção de maiúsculas e minúsculas. Diferenças apenas na capitalização das letras não acionam uma resposta `421`.
+:::
+
+---
+
+## Como identificar se sua aplicação será afetada
+
+Monitore os logs da sua aplicação em busca de respostas HTTP `421 Misdirected Request`. Esse status indica que uma requisição chegou por uma conexão TLS estabelecida para um hostname diferente do especificado no cabeçalho `Host`, e o certificado em uso não cobre esse hostname.
+
+**Cenários comuns que produzem uma resposta `421`:**
+
+- Aplicações web, APIs ou clientes HTTP que reutilizam uma conexão TLS existente (connection pooling ou multiplexação HTTP/2) para enviar requisições direcionadas a um hostname diferente do utilizado durante o handshake TLS.
+- Clientes que enviam um cabeçalho `Host` apontando para um hostname não coberto pelo certificado associado à sessão TLS.
+
+**Como investigar:**
+
+Use o [Real-Time Events](/pt-br/documentacao/produtos/observe/real-time-events/) para filtrar requisições com status code `421`. Os dados do evento exibirão os campos `host` e `ssl_server_name`, ajudando a identificar qual parte da sua aplicação está enviando requisições com um hostname fora do escopo do certificado em uso.
+
+---
+
+## Como corrigir incompatibilidades de SNI
+
+**Garanta que seus certificados cubram todos os hostnames necessários.**
+
+Cada hostname que sua aplicação serve via HTTPS deve estar coberto pelo certificado associado ao workload correspondente na Azion Web Platform. Um certificado cobre um hostname se esse hostname aparecer no CN do certificado ou na sua lista de SANs.
+
+Ações recomendadas:
+
+- Revise os certificados configurados no [Certificate Manager](/pt-br/documentacao/produtos/secure/firewall/certificate-manager/) para cada um dos seus workloads.
+- Se um workload serve múltiplos hostnames, utilize um certificado wildcard (ex.: `*.example.com`) ou um certificado multi-SAN que liste explicitamente todos os hostnames necessários.
+- Investigue as respostas `421` no Real-Time Events para identificar qual hostname está sendo solicitado fora do escopo do certificado e, em seguida, atualize o certificado ou a lógica de conexão da aplicação.
+
+---
+
+## Por que essa aplicação é importante
+
+A aplicação rigorosa da validação de SNI reduz significativamente o risco de ataques de **SNI Spoofing**, nos quais um agente malicioso manipula o campo SNI para rotear uma conexão TLS por um certificado que não cobre legitimamente o hostname de destino. Ao retornar `421 Misdirected Request` nesses casos, a Azion Web Platform garante que cada requisição HTTPS seja servida apenas em um contexto de segurança válido e apropriado.
+
+---
+
+## Recursos relacionados
+
+- [Certificate Manager](/pt-br/documentacao/produtos/secure/firewall/certificate-manager/)
+- [Connectors](/pt-br/documentacao/produtos/secure/connectors/)
+- [Real-Time Events](/pt-br/documentacao/produtos/observe/real-time-events/)
+- [HTTP 421 Misdirected Request — MDN Web Docs](https://developer.mozilla.org/pt-BR/docs/Web/HTTP/Reference/Status/421)