# 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/plataforma/workloads/certificate-manager/certificados/). 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`: ![Request routing decision algorithm](/assets/docs/images/uploads/request-decision.png) ### 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 | Workload está na versão mais recente da plataforma e tem um domínio configurado para o valor do SNI | Prossegue normalmente — o SNI resolve para um workload conhecido | | 5 | Workload está na versão mais recente da plataforma, nenhum domínio corresponde e a aplicação está habilitada | Retorna `421 Misdirected Request` | | 6 | Workload está na versão mais recente da plataforma, nenhum domínio corresponde e a aplicação está desabilitada | Prossegue normalmente | | 7 | Dados da sessão TLS estão indisponíveis | Prossegue normalmente — a plataforma falha de forma aberta para evitar interrupção do tráfego legítimo | | 8 | O certificado é gerenciado pela Azion | Prossegue normalmente — certificados da Azion são confiáveis pela plataforma | | 9 | `X509_check_host` confirma que o Host é válido para o certificado | Prossegue normalmente — o certificado cobre o hostname solicitado | | 10 | Nenhuma das condições acima é atendida e a aplicação está habilitada | Retorna `421 Misdirected Request` | | 11 | Nenhuma das condições acima é atendida e a aplicação está desabilitada | Prossegue normalmente | ### A aplicação do X509\_check\_host A etapa 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 é aplicada para todos os workloads na Azion Web Platform quando a aplicação do SNI Check está habilitada. 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`. Para mais informações sobre como encontrar e corrigir as requisições que recebem uma resposta `421`, consulte [Solucionar problemas de Connectors](/pt-br/documentacao/plataforma/connectors/solucao-de-problemas/#uma-requisicao-recebe-421-misdirected-request). > **nota** > > 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`. > **nota** > > Quando os dados da sessão TLS não podem ser recuperados, a plataforma prossegue normalmente em vez de bloquear a requisição. Esse comportamento de falha aberta evita que tráfego legítimo seja interrompido devido a condições transitórias de infraestrutura. --- ## Escopo da aplicação 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. A aplicação do SNI Check não é configurável pelo Azion Console ou pela API. Para habilitá-la ou desabilitá-la nos seus workloads, entre em contato com o [Suporte da Azion](https://www.azion.com/pt-br/suporte/). --- ## Recursos relacionados - [Certificados](/pt-br/documentacao/plataforma/workloads/certificate-manager/certificados.md): Os certificados cujos Common Name e Subject Alternative Names definem quais hostnames passam na verificação. - [Solucionar problemas de Connectors](/pt-br/documentacao/plataforma/connectors/solucao-de-problemas.md#uma-requisicao-recebe-421-misdirected-request): Como encontrar as requisições que recebem uma resposta 421 e corrigir o certificado ou o hostname. - [Real-Time Events](/pt-br/documentacao/plataforma/real-time-events.md): Os logs que mostram o host e o nome do servidor TLS de cada requisição. - [Connectors](/pt-br/documentacao/plataforma/connectors.md): O que um connector faz quando uma requisição passa na verificação e chega à sua aplicação.