Compartilhar via

Solucionar problemas de integridade de back-end no Gateway de Aplicativo

  • Artigo

Visão geral

Por padrão, o Gateway de Aplicativo do Azure investiga os servidores back-end para verificar seu status de integridade e se eles estão prontos para atender a solicitações. Os usuários também podem criar investigações personalizadas para mencionar o nome do host, o caminho a ser investigado e os códigos de status a serem aceitos como íntegros. Em cada caso, se o servidor back-end não responder com êxito, o Gateway de Aplicativo marcará o servidor como Não íntegro e interromperá o encaminhamento de solicitações ao servidor. Depois que o servidor começa a responder com êxito, o Gateway de Aplicativo retoma o encaminhamento das solicitações.

Como verificar a integridade do back-end

Para verificar a integridade do pool de back-end, você pode usar a página Integridade de Back-end no portal do Azure. Ou você pode usar o Azure PowerShell, a CLI ou a API REST.

O status recuperado por qualquer um desses métodos pode ser um dos seguintes:

  • Healthy
  • Unhealthy
  • Desconhecido

O Gateway de Aplicativo encaminha uma solicitação para um servidor do pool de back-end se o status dele estiver íntegro. Se todos os servidores em um pool de back-end estiverem não íntegros ou com estado desconhecido, os clientes poderão encontrar problemas para acessar o aplicativo de back-end. Leia mais para entender as diferentes mensagens relatadas pela Integridade do Back-End, as causas delas e como resolver.

Observação

Se o usuário não tiver permissão para ver os status de integridade de back-end, o No results. de saída será exibido.

Status de integridade de back-end: Não íntegro

Se o status da integridade do back-end for Não íntegro, a exibição do portal será semelhante à seguinte captura de tela:

Status da integridade de back-end do Gateway de Aplicativo - Não íntegro

Se você estiver usando uma consulta do Azure PowerShell, CLI ou API REST, obterá uma resposta semelhante ao seguinte exemplo:

PS C:\Users\testuser\> Get-AzApplicationGatewayBackendHealth -Name "appgw1" -ResourceGroupName "rgOne"
BackendAddressPools :
{Microsoft.Azure.Commands.Network.Models.PSApplicationGatewayBackendHealthPool}
BackendAddressPoolsText : [
{
                              "BackendAddressPool": {
                                "Id": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/rgOne/providers/Microsoft.Network/applicationGateways/appgw1/b
                          ackendAddressPools/appGatewayBackendPool"
                              },
                              "BackendHttpSettingsCollection": [
                                {
                                  "BackendHttpSettings": {
                                    "TrustedRootCertificates": [],
                                    "Id": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/rgOne/providers/Microsoft.Network/applicationGateways/appg
                          w1/backendHttpSettingsCollection/appGatewayBackendHttpSettings"
                                  },
                                  "Servers": [
                                    {
                                      "Address": "10.0.0.5",
                                      "Health": "Healthy"
                                    },
                                    {
                                      "Address": "10.0.0.6",
                                      "Health": "Unhealthy"
                                    }
                                  ]
                                }
                              ]
                            }
                        ]

Depois de você receber um status de servidor de back-end não íntegro para todos os servidores em um pool de back-end, as solicitações não serão encaminhadas para os servidores e o Gateway de Aplicativo retornará um erro "502 Gateway Incorreto" ao cliente solicitante. Para solucionar esse problema, verifique a coluna Detalhes na guia Integridade de Back-end.

A mensagem exibida na coluna Detalhes fornece mais informações detalhadas sobre o problema e, com base nelas, você pode começar a solucionar o problema.

Observação

A solicitação de análise padrão é enviada no formato do <protocolo>://127.0.0.1:<port>. Por exemplo, http://127.0.0.1:80 para uma investigação de integridade de HTTP na porta 80. Somente os códigos de status HTTP de 200 a 399 são considerados íntegros. O protocolo e a porta de destino são herdados das configurações de HTTP. Se você quiser que o Gateway de Aplicativo investigue um protocolo, nome do host ou caminho diferente e reconheça um código de status diferente como Íntegro, configure uma investigação personalizada e associe-a às configurações de HTTP.

Mensagens de erro

Tempo limite do servidor back-end

Message: o tempo gasto pelo back-end para responder à investigação de integridade do gateway de aplicativo é maior que o tempo limite na configuração da investigação.

Causa: depois que o Gateway de Aplicativo envia uma solicitação de investigação HTTP(S) ao servidor back-end, ele aguarda uma resposta do servidor back-end por um período configurado. Se o servidor back-end não responder dentro desse período (o valor do tempo limite), ele será marcado como Não íntegro até que responda dentro do período de tempo limite configurado novamente.

Resolução: verifique por que o servidor ou aplicativo back-end não está respondendo dentro do período de tempo limite configurado e verifique também as dependências do aplicativo. Por exemplo, verifique se o banco de dados tem algum problema que possa desencadear um atraso na resposta. Se você estiver ciente do comportamento do aplicativo e ele responder apenas após o valor de tempo limite, aumente o valor de tempo limite nas configurações personalizadas da investigação. Você deve ter uma investigação personalizada para alterar o valor de tempo limite. Para obter informações sobre como configurar uma investigação personalizada, confira a página de documentação.

Para aumentar o valor de tempo limite, siga estas etapas:

  1. Acesse o servidor back-end diretamente e verifique o tempo necessário para que o servidor responda nessa página. É possível usar qualquer ferramenta para acessar o servidor back-end, incluindo um navegador com ferramentas de desenvolvedor.
  2. Depois de descobrir o tempo necessário para o aplicativo responder, selecione a guia Investigações de Integridade e selecione a investigação associada às configurações de HTTP.
  3. Insira qualquer valor de tempo limite maior que o tempo de resposta do aplicativo, em segundos.
  4. Salve as configurações de investigação personalizadas e verifique se a integridade do back-end é mostrada como íntegra agora.

Erro de resolução de DNS

Mensagem: o Gateway de Aplicativo não pôde criar uma investigação para este back-end. Isso geralmente acontece quando o FQDN do back-end não é inserido corretamente. 

Causa: se o pool de back-end for do tipo Endereço IP, FQDN (nome de domínio totalmente qualificado) ou Serviço de Aplicativo, o Gateway de Aplicativo será determinado para o endereço IP do FQDN inserido pelo DNS (personalizado ou padrão do Azure). Em seguida, o gateway de aplicativo tenta se conectar ao servidor na porta TCP mencionada nas configurações HTTP. Mas se essa mensagem for exibida, ela sugere que o Gateway de Aplicativo não conseguiu determinar com êxito o endereço IP do FQDN inserido.

Resolução:

  1. verifique se o FQDN inserido no pool de back-end está correto e se é de domínio público e tente determiná-lo a partir do computador local.
  2. Se for possível determinar o endereço IP, pode haver algo errado com a configuração de DNS na rede virtual.
  3. Verifique se a rede virtual está configurada com um servidor DNS personalizado. Se estiver, verifique porque o servidor DNS não determina o endereço IP do FQDN especificado.
  4. Se você estiver usando o DNS padrão do Azure, verifique com o registrador de nomes de domínio se o registro A adequado ou o mapeamento do registro CNAME está concluído.
  5. Se o domínio for privado ou interno, tente determiná-lo a partir de uma VM na mesma rede virtual. Se for possível determiná-lo, reinicie o Gateway de Aplicativo e verifique novamente. Para reiniciar o Gateway de Aplicativo, é necessário parar e iniciar usando os comandos do PowerShell descritos nesses recursos vinculados.

Erro de conexão TCP

Mensagem: o Gateway de Aplicativo não pôde se conectar ao back-end. Verifique se o back-end responde na porta usada para a investigação. Verifique também se algum NSG/UDR/firewall está bloqueando o acesso ao IP e à porta desse back-end.

Causa: após a fase de resolução de DNS, o Gateway de Aplicativo tentará se conectar ao servidor de back-end na porta TCP definida nas configurações de HTTP. Se o Gateway de Aplicativo não puder estabelecer uma sessão TCP na porta especificada, o status da investigação passará a Não íntegro com esta mensagem.

Solução: se você receber esse erro, siga estas etapas:

  1. Verifique se você pode se conectar ao servidor back-end na porta mencionada nas configurações de HTTP usando um navegador ou o PowerShell. Por exemplo, execute o seguinte comando: Test-NetConnection -ComputerName www.bing.com -Port 443.

  2. Se a porta mencionada não for a porta desejada, insira o número da porta correta para que o Gateway de Aplicativo se conecte ao servidor back-end.

  3. Se também não for possível se conectar a partir do seu computador local, então:

    a. Verifique as configurações do NSG (grupo de segurança de rede) do adaptador de rede e da sub-rede do servidor back-end e se são permitidas conexões de entrada com a porta configurada. Se este não for o caso, crie uma nova regra para permitir as conexões. Para saber como criar regras de NSG, confira a página de documentação.

    b. Verifique se as configurações de NSG da sub-rede do Gateway de Aplicativo permitem tráfego de saída público e privado, para que uma conexão possa ser estabelecida. Verifique a página de documentação fornecida na etapa 3a para saber mais sobre como criar regras NSG.

            $vnet = Get-AzVirtualNetwork -Name "vnetName" -ResourceGroupName "rgName"
        Get-AzVirtualNetworkSubnetConfig -Name appGwSubnet -VirtualNetwork $vnet

    c. Verifique as configurações de UDR (rotas definidas pelo usuário) do Gateway de Aplicativo e a sub-rede do servidor back-end para quaisquer anomalias de roteamento. Verifique se o UDR não está direcionando o tráfego para longe da sub-rede de back-end. Por exemplo, verifique se há rotas para dispositivos virtuais em rede ou rotas padrão anunciadas para a sub-rede do Gateway de Aplicativo via Azure ExpressRoute e/ou VPN.

    d. Para verificar as rotas e regras em vigor para um adaptador de rede, você pode usar os seguintes comandos do PowerShell:

            Get-AzEffectiveNetworkSecurityGroup -NetworkInterfaceName "nic1" -ResourceGroupName "testrg"
        Get-AzEffectiveRouteTable -NetworkInterfaceName "nic1" -ResourceGroupName "testrg"

  4. Se você não encontrar problemas com NSG ou UDR, verifique no servidor back-end se há problemas relacionados a aplicativos que estão impedindo os clientes de estabelecer uma sessão TCP nas portas configuradas. Alguns pontos a verificar:

    a. Abra um prompt de comando (Win + R-> cmd), insira netstat e selecione Enter.

    b. Verifique se o servidor está escutando na porta configurada. Por exemplo:

            Proto Local Address Foreign Address State PID
        TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 4

    c. Se não estiver escutando na porta configurada, verifique as configurações do servidor Web. Por exemplo: associações de site no IIS, bloco de servidor no NGINX e host virtual no Apache.

    d. Verifique as configurações do firewall do sistema operacional para garantir que o tráfego de entrada para a porta seja permitido.

Incompatibilidade de código de status HTTP

Message: o código de status da resposta HTTP do back-end não corresponde à configuração da investigação. Esperado:{HTTPStatusCode0} Recebido:{HTTPStatusCode1}.

Causa: depois que a conexão TCP for estabelecida e um handshake do TLS for concluído (se o TLS estiver habilitado), o Gateway de Aplicativo enviará a investigação como uma solicitação HTTP GET para o servidor back-end. Conforme descrito anteriormente, a investigação padrão é definida como <protocol>://127.0.0.1:<port>/ e considera os códigos de status de resposta no intervalo de 200 a 399 como íntegros. Se o servidor retornar qualquer outro código de status, ele será marcado como Não íntegro com esta mensagem.

Solução: dependendo do código de resposta do servidor back-end, você pode realizar as etapas a seguir. Alguns dos códigos de status comuns estão listados aqui:

Erro Ações
Incompatibilidade de código de status de investigação: Recebido 401 Verifique se o servidor back-end requer autenticação. As investigações do Gateway de Aplicativo não podem passar credenciais para autenticação. Permita que o código de status "HTTP 401" em investigação corresponda ou investigue um caminho em que o servidor não exija autenticação.
Incompatibilidade de código de status de investigação: Recebido 403 Acesso proibido. Verifique se o acesso ao caminho é permitido no servidor back-end.
Incompatibilidade de código de status de investigação: Recebido 404 Página não encontrada. Verifique se o caminho do nome do host está acessível no servidor back-end. Altere o nome do host ou o parâmetro do caminho para um valor acessível.
Incompatibilidade de código de status de investigação: Recebido 405 As solicitações de investigação do Gateway de Aplicativo usam o método HTTP GET. Verifique se o seu servidor permite esse método.
Incompatibilidade de código de status de investigação: Recebido 500 Erro interno do servidor. Verifique a integridade do servidor de back-end e se os serviços estão em execução.
Incompatibilidade de código de status de investigação: Recebido 503 Serviço indisponível. Verifique a integridade do servidor de back-end e se os serviços estão em execução.

Ou, se você acredita que a resposta é legítima e deseja que o Gateway de Aplicativo aceite outros códigos de status como Íntegros, é possível criar uma investigação personalizada. Essa abordagem é útil em situações em que o site de back-end precisa de autenticação. Como as solicitações de investigação não carregam as credenciais do usuário, elas falharão e um código de status HTTP 401 será retornado pelo servidor back-end.

Para criar uma investigação personalizada, siga estas etapas.

Incompatibilidade no corpo da resposta HTTP

Mensagem: o corpo da resposta HTTP do back-end não correspondia à configuração de investigação. O corpo da resposta recebida não contém {cadeia de caracteres}.

Causa: ao criar uma investigação personalizada, você tem a opção de marcar um servidor back-end como Íntegro, combinando com uma cadeia de caracteres do corpo da resposta. Por exemplo, você pode configurar o Gateway de Aplicativo para aceitar "não autorizado" como uma cadeia de caracteres a ser correspondida. Se a resposta do servidor back-end para a solicitação de investigação contiver a sequência não autorizada, ele será marcado como Íntegro. Caso contrário, ele será marcado como Não íntegro com a mensagem fornecida.

Solução: para resolver o problema, siga estas etapas:

  1. Acesse o servidor back-end localmente ou a partir de um computador cliente no caminho da investigação e verifique o corpo da resposta.
  2. Verifique se o corpo da resposta na configuração de investigação personalizada do Gateway de Aplicativo corresponde ao que está configurado.
  3. Se não houver correspondência, altere a configuração da investigação para que ela tenha o valor correto da cadeia de caracteres a ser aceito.

Saiba mais sobre a correspondência de investigação do Gateway de Aplicativo.

Observação

Com relação a todas as mensagens de erro relacionadas ao TLS, para saber mais sobre o comportamento do SNI e as diferenças entre os SKUs v1 e v2, confira a página Visão geral do TLS.

O Nome Comum (CN) não corresponde

Mensagem:: (na V2) O Nome Comum do certificado folha apresentado pelo servidor back-end não corresponde ao nome do host da Investigação ou da Configuração de Back-end do gateway de aplicativo.
(Na V1) o CN (Nome Comum) do certificado de back-end não é correspondente.

Causa: (para a V2) isso ocorre quando você seleciona o protocolo HTTPS na configuração de back-end e nem o nome do host da Investigação personalizada nem o da Configuração de back-end (nessa ordem) correspondem ao CN (Nome comum) do certificado do servidor back-end.
(Na V1) o FQDN do destino do pool de back-end não corresponde ao CN (Nome Comum) do certificado do servidor back-end.

Solução: as informações de nome do host são críticas para a conexão HTTPS de back-end, pois esse valor é usado para definir a SNI (Indicação de Nome de Servidor) durante o handshake do TLS. Corrija o problema das maneiras mostradas a seguir de acordo com a configuração do gateway.

Na V2,

  • Se estiver usando uma investigação padrão, especifique um nome do host na configuração de back-end associada do gateway de aplicativo. Selecione “Substituir pelo nome do host específico” ou “Escolher nome do host do destino de back-end” na configuração de back-end.
  • Se estiver usando uma investigação personalizada, use o campo “host” para especificar o Nome Comum do certificado do servidor back-end. Como alternativa, se a configuração de back-end já estiver definida com o mesmo nome do host, você poderá selecionar a opção “Escolher nome do host na configuração de back-end" nas configurações de investigação.

Na v1, verifique se o FQDN do destino do pool de back-end tem o mesmo CN (Nome Comum).

Dicas: para determinar o CN (Nome comum) do certificado do servidor back-end, use um destes métodos. Observe também que, de acordo com o RFC 6125, se houver uma SAN, a verificação de SNI será feita somente nesse campo. O campo de nome comum será correspondido se não houver SAN no certificado.

  • Usando o navegador ou qualquer cliente: acesse o servidor back-end diretamente (não por meio do Gateway de Aplicativo) e clique no cadeado de certificado na barra de endereços para ver os detalhes do certificado. Você pode encontrá-lo na “seção Emitido para”. Captura de tela que mostra os detalhes do certificado em um navegador.

  • Fazendo logon no servidor back-end (Windows):

    1. Entre no computador em que o seu aplicativo está hospedado.
    2. Selecione Win+R ou clique com o botão direito do mouse no botão Iniciar e selecione Executar.
    3. Insira certlm.msc e selecione ENTER. Você também pode procurar pelo Gerenciador de Certificados no menu Iniciar.
    4. Localize o certificado (que normalmente fica em Certificados – Computador Local\Pessoal\Certificados) e abra o certificado.
    5. Na guia Detalhes, verifique o Assunto do certificado.

  • Fazendo logon no servidor back-end (Linux): execute este comando do OpenSSL especificando o nome de arquivo do certificado correto openssl x509 -in certificate.crt -subject -noout

O certificado de back-end expirou

Mensagem: o certificado de back-end é inválido. A data atual não está dentro do intervalo de datas "Válido de" e "Válido até" no certificado.

Causa: um certificado expirado é considerado não seguro e, portanto, o gateway de aplicativo marca o servidor back-end com um certificado expirado como não íntegro.

Solução: a solução depende de qual parte da cadeia de certificados expirou no servidor back-end.

No SKU V2,

  • Certificado folha expirado (também conhecido como domínio ou servidor): renove o certificado do servidor com o provedor de certificados e instale o novo certificado no servidor back-end. Instale a cadeia de certificados completa composta por Leaf (topmost) > Intermediate(s) > Root. Com base no tipo de AC (Autoridade de Certificação), você pode realizar as ações a seguir no gateway.

    • AC conhecida publicamente: se o emissor do certificado for uma AC conhecida, você não precisará realizar nenhuma ação no gateway de aplicativo.
    • AC privada: se o certificado folha for emitido por uma AC privada, você precisará verificar se o certificado de AC raiz de autenticação foi alterado. Nesses casos, você precisa carregar o novo certificado de Autoridade de Certificação raiz (.CER) na configuração de back-end associada do gateway.

  • Certificado intermediário ou raiz expirado: normalmente, esses certificados têm períodos de validade relativamente estendidos (uma ou duas décadas). Quando o certificado raiz/intermediário expirar, recomendaremos que você verifique com seu provedor de certificados os arquivos de certificado renovados. Instale essa cadeia de certificados atualizada e completa que contém Leaf (topmost) > Intermediate(s) > Root no servidor back-end.

    • Se o certificado raiz permanecer inalterado ou se o emissor for uma AC conhecida, você NÃO precisará realizar nenhuma ação no gateway de aplicativo.
    • Ao usar uma AC privada, se o próprio certificado de Autoridade de Certificação raiz ou a raiz do certificado intermediário renovado tiver sido alterado, você precisará carregar o novo certificado raiz na configuração de back-end do gateway de aplicativo.

No SKU V1,

  • Renove o certificado folha expirado (também conhecido como domínio ou servidor) com a AC e carregue o mesmo certificado folha (.CER) na configuração de back-end associada do gateway de aplicativo.

O certificado intermediário não foi encontrado

Mensagem: o certificado intermediário está ausente da cadeia de certificados apresentada pelo servidor back-end. Verifique se a cadeia de certificados está completa e ordenada corretamente no servidor back-end.

Causa: Os certificados intermediários não estão instalados na cadeia de certificados no servidor de back-end.

Solução: um certificado intermediário é usado para assinar o certificado folha e, portanto, é necessário para concluir a cadeia. Verifique com a AC (Autoridade de Certificação) o(s) certificado(s) intermediário(s) necessário(s) e instale-o(s) no servidor de back-end. Esta cadeia deve começar com o certificado de folha; em seguida, os certificados intermediários e, por fim, o certificado de AC raiz. É recomendável instalar a cadeia completa no servidor de back-end, incluindo o certificado de AC raiz. Para referência, examine o exemplo de cadeia de certificados em A folha deve ser superior na cadeia.

Observação

Um certificado autoassinado que NÃO é uma Autoridade de Certificação também resulta no mesmo erro. Isso ocorre porque o gateway de aplicativo considera o certificado autoassinado do tipo “Folha” e procura o respectivo certificado intermediário de autenticação. Siga este artigo para gerar um certificado autoassinado corretamente.

Estas imagens mostram a diferença entre os certificados autoassinados. Captura de tela mostrando a diferença entre os certificados autoassinados.

O certificado folha ou do servidor não foi encontrado

Mensagem: o certificado folha está ausente da cadeia de certificados apresentada pelo servidor back-end. Verifique se a cadeia está completa e ordenada corretamente no servidor back-end.

Causa: o certificado Folha (também conhecido como Domínio ou Servidor) está ausente da cadeia de certificados no servidor back-end.

Solução: obtenha o certificado folha da AC (Autoridade de Certificação). Instale esse certificado de folha e todos os certificados de autenticação (certificados intermediários e de AC raiz) no servidor de back-end. Esta cadeia deve começar com o certificado de folha; em seguida, os certificados intermediários e, por fim, o certificado de AC raiz. É recomendável instalar a cadeia completa no servidor de back-end, incluindo o certificado de AC raiz. Para referência, examine o exemplo de cadeia de certificados em A folha deve ser superior na cadeia.

O certificado de servidor não é emitido por uma AC conhecida publicamente

Mensagem: o certificado do servidor de back-end não é assinado por uma AC (Autoridade de Certificação) conhecida. Para usar certificados de AC desconhecida, o certificado raiz precisa ser carregado na Configuração de Back-end do gateway de aplicativo.

Causa: você escolheu o "certificado de CA bem conhecida" na configuração de back-end, mas o certificado Raiz apresentado pelo servidor de back-end não é conhecido publicamente.

Solução: quando um certificado folha é emitido por uma AC (Autoridade de Certificação) privada, o certificado da AC raiz de autenticação precisa ser carregado na Configuração de Back-end associada ao gateway de aplicativo. Isso permite que o gateway de aplicativo estabeleça uma conexão confiável com esse servidor de back-end. Para corrigir isso, vá para a configuração de back-end associada, selecione "não é uma CA bem conhecida" e carregue o certificado Raiz da CA (. CER). Para identificar e baixar o certificado raiz, você pode seguir as mesmas etapas descritas em Incompatibilidade de certificado raiz confiável.

O certificado intermediário NÃO é assinado por uma AC conhecida publicamente.

Mensagem: o certificado intermediário não é assinado por uma AC (Autoridade de Certificação) conhecida. Verifique se a cadeia de certificados está completa e ordenada corretamente no servidor back-end.

Causa: você escolheu "certificado de AC conhecido" na configuração de back-end, mas o certificado intermediário apresentado pelo servidor back-end não é assinado por nenhuma AC conhecida publicamente.

Solução: quando um certificado é emitido por uma AC (Autoridade de Certificação) privada, o certificado da AC raiz de autenticação precisa ser carregado na Configuração de Back-end associada ao gateway de aplicativo. Isso permite que o gateway de aplicativo estabeleça uma conexão confiável com esse servidor back-end. Para corrigir isso, entre em contato com sua AC privada para obter o certificado de AC raiz (.CER) apropriado e carregue esse arquivo CER na configuração de back-end do gateway de aplicativo selecionando "não é uma AC conhecida". Também recomendamos instalar a cadeia completa no servidor back-end, incluindo o certificado de AC raiz, para facilitar a verificação.

Incompatibilidade de certificado raiz confiável (nenhum certificado raiz no servidor back-end)

Mensagem: o certificado intermediário não assinado por nenhum certificado raiz foi carregado no gateway de aplicativo. Verifique se a cadeia de certificados está completa e ordenada corretamente no servidor back-end.

Causa: nenhum dos certificados de AC raiz carregados na configuração de back-end associada assinou o certificado Intermediário instalado no servidor back-end. O servidor back-end tem apenas certificados folha e intermediário instalados.

Solução: um certificado folha é assinado por um certificado intermediário, que é assinado por um Certificado de Autoridade de Certificação raiz. Ao usar um certificado de Autoridade de Certificação (AC) privada, você deve carregar o certificado de AC raiz correspondente para o gateway de aplicativo. Entre em contato com sua AC privada para obter o certificado de autoridade de certificação raiz apropriado (. CER) e carregue esse arquivo CER na configuração back-end do gateway do seu aplicativo.

Incompatibilidade de certificado raiz confiável (o certificado raiz está disponível no servidor back-end)

Mensagem: o certificado raiz do certificado do servidor usado pelo back-end não corresponde ao certificado raiz confiável adicionado ao gateway de aplicativo. Adicione o certificado raiz correto à lista de permissões de back-end.

Causa: Esse erro ocorre quando nenhum dos certificados raiz carregados na configuração de back-end do gateway de aplicativo corresponde ao certificado raiz presente no servidor back-end.

Solução: isso se aplica a um certificado de servidor back-end emitido por uma AC (Autoridade de Certificação) Privada ou a um autoassinado. Identifique e carregue o certificado de AC raiz correto para a configuração de back-end associada.

Dicas: para identificar e baixar o certificado raiz, use um destes métodos.

  • Usando um navegador: acesse o servidor back-end diretamente (não por meio do Gateway de Aplicativo) e clique no cadeado do certificado na barra de endereços para ver os detalhes do certificado.

    1. Escolha o certificado raiz na cadeia e clique em Exportar. Por padrão, isso é um arquivo .CRT.
    2. Abra esse arquivo .CRT.
    3. Acesse a guia Detalhes e clique em “Copiar para Arquivo”.
    4. Na página Assistente para Exportação de Certificados, clique em Avançar.
    5. Selecione “X.509 codificado em Base-64 (.CER)” e clique em Avançar.
    6. Dê um novo nome de arquivo e clique em Avançar.
    7. Clique em Concluir para obter um arquivo .CER.
    8. Carregue este certificado raiz (.CER) da AC privada para a configuração de back-end do gateway de aplicativo.

  • Como fazer logon no servidor back-end (Windows)

    1. Entre no computador em que o seu aplicativo está hospedado.
    2. Selecione Win+R ou clique com o botão direito do mouse no botão Iniciar e selecione Executar.
    3. Insira certlm.msc e selecione ENTER. Você também pode procurar pelo Gerenciador de Certificados no menu Iniciar.
    4. Localize o certificado, que normalmente fica em Certificados – Computador Local\Pessoal\Certificados e abra-o.
    5. Selecione o certificado raiz e, em seguida, selecione Exibir Certificado.
    6. Nas propriedades do Certificado, selecione a guia Detalhes e clique em “Copiar para Arquivo”.
    7. Na página Assistente para Exportação de Certificados, clique em Avançar.
    8. Selecione “X.509 codificado em Base-64 (.CER)” e clique em Avançar.
    9. Dê um novo nome de arquivo e clique em Avançar.
    10. Clique em Concluir para obter um arquivo .CER.
    11. Carregue este certificado raiz (.CER) da AC privada para a configuração de back-end do gateway de aplicativo.

A folha precisa ser a mais alta da cadeia.

Mensagem: o certificado folha não é o certificado mais alto da cadeia apresentado pelo servidor back-end. Verifique se a cadeia de certificados está ordenada corretamente no servidor back-end.

Causa: o certificado Folha (também conhecido como Domínio ou Servidor) não está instalado na ordem correta no servidor de back-end.

Solução: a instalação do certificado no servidor back-end precisa incluir uma lista ordenada de certificados que incluem o certificado folha e todos os certificados de autenticação (certificados de Autoridades de Certificação intermediário e raiz). Essa cadeia deve começar com o certificado folha; em seguida, os certificados intermediários e, por fim, o certificado de AC raiz. É recomendável instalar a cadeia completa no servidor de back-end, incluindo o certificado de AC raiz.

Confira um exemplo de uma instalação de certificado do servidor junto com os respectivos certificados de Autoridades de Certificação intermediária e raiz, indicados como as profundidades (0, 1, 2 etc.) no OpenSSL. Você pode verificar o mesmo para o certificado do servidor back-end usando os comandos do OpenSSL a seguir.
s_client -connect <FQDN>:443 -showcerts
OU
s_client -connect <IPaddress>:443 -servername <TLS SNI hostname> -showcerts

Captura de tela mostrando a cadeia típica de certificados.

Falha na verificação do certificado

Mensagem: não foi possível verificar a validade do certificado de back-end. Para descobrir o motivo, verifique o diagnóstico do OpenSSL para obter a mensagem associada ao código de erro {errorCode}

Causa: esse erro ocorre quando o gateway de aplicativo não pode verificar a validade do certificado.

Solução: para resolver esse problema, verifique se o certificado no seu servidor foi criado corretamente. Por exemplo, você pode usar o OpenSSL para verificar o certificado e suas propriedades e tentar recarregar o certificado nas configurações de HTTP do Gateway de Aplicativo.

Status de integridade de back-end: Desconhecido

Atualizações para as entradas DNS do pool de back-end

Mensagem: Não foi possível recuperar o status de integridade do back-end. Isso acontece quando um Firewall NSG/UDR na sub-rede do gateway de aplicativo está bloqueando o tráfego nas portas 65503-65534 no caso da SKU v1 e as portas 65200-65535 no caso da SKU v2 ou se o FQDN configurado no pool de back-end não pôde ser resolvido para um endereço IP. Para saber mais, consulte - https://aka.ms/UnknownBackendHealth.

Causa: para destinos de back-end baseados em FQDN (nome de domínio totalmente qualificado), o Gateway de Aplicativo armazena em cache e usa o último endereço IP conhecido se ele não consegue obter uma resposta para a pesquisa DNS seguinte. Uma operação PUT em um gateway nesse estado limpará por completo o cache DNS. Como resultado, não haverá nenhum endereço de destino que o gateway possa acessar.

Solução: verifique e corrija os servidores DNS para garantir que eles forneçam uma resposta à pesquisa DNS do FDQN especificado. Você também precisa verificar se os servidores DNS podem ser acessados por meio da Rede Virtual do gateway de aplicativo.

Outras razões

Se a integridade do back-end for mostrada como Desconhecida, a exibição do portal será semelhante à seguinte captura de tela:

Status da integridade de back-end do Gateway de Aplicativo - Desconhecido

Esse comportamento pode ocorrer por uma ou mais das seguintes razões:

  1. O NSG na sub-rede do Gateway de Aplicativo está bloqueando o acesso de entrada às portas 65503-65534 (v1 SKU) ou 65200-65535 (v2 SKU) da "Internet".
  2. O UDR na sub-rede do Gateway de Aplicativo é definido como a rota padrão (0.0.0.0/0) e o próximo salto não é especificado como "Internet".
  3. A rota padrão é anunciada por uma conexão ExpressRoute/VPN à rede virtual através do BGP.
  4. O servidor DNS personalizado está configurado em uma rede virtual que não pode resolver nomes de domínio público.
  5. O Gateway de Aplicativo está em um estado Não Íntegro.

Solução:

  1. Verifique se o NSG está bloqueando o acesso às portas 65503-65534 (v1 SKU) ou 65200-65535 (v2 SKU) da Internet:

    a. Na guia Visão Geral do Gateway de Aplicativo, selecione o link Rede Virtual/Sub-rede. b. Na guia Sub-redes da sua rede virtual, selecione a sub-rede na qual o Gateway de Aplicativo foi implantado. c. Verifique se algum NSG está configurado. d. Se um NSG estiver configurado, procure esse recurso NSG na guia Pesquisar ou em Todos os Recursos. e. Na seção Regras de Entrada, adicione uma regra de entrada para permitir o intervalo de porta de destino 65503-65534 para SKU v1 ou 65200-65535 v2 SKU com a Fonte definida como marca de serviço GatewayManager. f. Selecione Salvar e verifique se você pode exibir o back-end como Íntegro. Como alternativa, você pode fazer isso por meio do PowerShell/CLI.

  2. Verifique se o UDR tem uma rota padrão (0.0.0.0/0) com o próximo salto não definido como Internet:

    a. Siga as etapas 1a e 1b para determinar sua sub-rede. b. Verifique se uma UDR está configurada. Se houver, pesquise o recurso na barra de pesquisa ou em Todos os Recursos. c. Verifique se há alguma rota padrão (0.0.0.0/0) com o próximo salto não definido como Internet. Se a configuração for Solução de Virtualização ou Gateway de Rede Virtual, verifique se a solução de virtualização ou o dispositivo local pode rotear corretamente o pacote de volta ao destino da Internet sem modificar o pacote. Se as investigações forem roteadas por meio de uma solução de virtualização e modificadas, o recurso de back-end exibirá um código de status 200 e o status da integridade do Gateway de Aplicativo poderá ser exibido como Desconhecido. Isso não indica um erro. O tráfego ainda será roteado pelo Gateway de Aplicativo sem problemas. d. Caso contrário, altere o próximo salto para Internet, selecione Salvar e verifique a integridade do back-end.

  3. Rota padrão anunciada pela conexão ExpressRoute/VPN à rede virtual através do BGP (Border Gateway Protocol):

    a. Se você tem uma conexão ExpressRoute/VPN com a rede virtual via protocolo BGP e está anunciando uma rota padrão, verifique se o pacote é roteado novamente para o destino da Internet sem modificá-lo. Você pode verificar usando a opção Solução de Problemas de Conexão no portal do Gateway de Aplicativo. b. Escolha o destino manualmente como qualquer endereço IP roteável da Internet, como 1.1.1.1. Defina a porta de destino como qualquer uma, e verifique a conectividade. c. Se o próximo salto for o gateway de rede virtual, pode haver uma rota padrão anunciada pelo ExpressRoute ou VPN.

  4. Se houver um servidor DNS personalizado configurado na rede virtual, verifique se os servidores pode determinar domínios públicos. A resolução de nomes de domínio público pode ser necessária em cenários em que o Gateway de Aplicativo deve acessar domínios externos como servidores OCSP (Online Certificate Status Protocol) ou verificar o status de revogação do certificado.

  5. Para verificar se o Gateway de Aplicativo está íntegro e em execução, acesse a opção Resource Health no portal e verifique se o estado é Íntegro. No caso de um estado Não Íntegro ou Degradado, entre em contato com o suporte.

  6. Se a Internet e o tráfego privado estiverem indo por um Firewall do Azure hospedado em um hub virtual seguro (usando o Hub de WAN Virtual do Azure):

    a. Para garantir que o gateway de aplicativo possa enviar tráfego diretamente para a Internet, configure a seguinte rota definida pelo usuário:

    Prefixo de endereço: 0.0.0.0/0
    Próximo salto: Internet

    b. Para garantir que o gateway de aplicativo possa enviar tráfego para o pool de back-end por meio de um Firewall do Azure no hub de WAN Virtual, configure a seguinte rota definida pelo usuário:

    Prefixo de endereço: Sub-rede do pool de back-end
    Próximo salto: endereço IP privado do Firewall do Azure

Observação

Se o Gateway de Aplicativo não conseguir acessar os pontos de extremidade de CRL, pode marcar o status da integridade do back-end como "desconhecido". Para evitar esses problemas, verifique se a sub-rede do gateway de aplicativo consegue acessar crl.microsoft.com e crl3.digicert.com. Isso pode ser feito configurando seus Grupos de Segurança de Rede para enviar tráfego para os pontos de extremidade da CRL.

Próximas etapas

Saiba mais sobre Diagnóstico e log do Gateway de Aplicativo.