Troubleshoot backend health issues in Application Gateway

Descrição geral

Por predefinição, a Gateway de Aplicação do Azure pesquisa os servidores de back-end para verificar o estado de funcionamento e para verificar se estão prontos para executar pedidos. Users can also create custom probes to mention the host name, the path to be probed, and the status codes to be accepted as Healthy. In each case, if the backend server doesn't respond successfully, Application Gateway marks the server as Unhealthy and stops forwarding requests to the server. Depois de o servidor começar a responder com êxito, o Gateway de Aplicação retoma o reencaminhamento dos pedidos.

Como verificar a integridade do backend

Para verificar a saúde do seu pool de back-end, pode utilizar a página de Estado de Funcionamento do Back-End no portal do Azure. Em alternativa, pode utilizar o Azure PowerShell, a CLI ou a API REST.

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

• Saudável
• Pouco saudável
• Desconhecido

The Application Gateway forwards a request to a server from the backend pool if its status is healthy. If all the servers in a backend pool are unhealthy or unknown, the clients could encounter problems accessing the backend application. Leia mais para entender as diferentes mensagens relatadas pela Backend Health, suas causas e sua resolução.

Nota

If your user doesn't have permission to see backend health statuses, the output No results. is displayed.

Estado de saúde do backend: Não saudável

If the backend health status is Unhealthy, the portal view resembles the following screenshot:

Caso esteja usando uma consulta do Azure PowerShell, CLI ou API REST do Azure, você receberá uma resposta semelhante ao exemplo a seguir:

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"
                                    }
                                  ]
                                }
                              ]
                            }
                        ]

After you receive an unhealthy backend server status for all the servers in a backend pool, requests aren't forwarded to the servers, and Application Gateway returns a "502 Bad Gateway" error to the requesting client. To troubleshoot this issue, check the Details column on the Backend Health tab.

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

Nota

A solicitação de teste padrão é enviada no formato de <protocol>://127.0.0.1:<port>. Por exemplo, http://127.0.0.1:80 para uma sonda HTTP na porta 80. Somente 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 HTTP. Se pretender que o Application Gateway sonde num protocolo, host ou caminho diferente e reconheça um código de status diferente como Saudável, configure uma sondagem personalizada e associe-a às configurações de HTTP.

Mensagens de erro

Backend server timeout

Message: Time taken by the backend to respond to application gateway's health probe is more than the timeout threshold in the probe setting.

Cause: After Application Gateway sends an HTTP(S) probe request to the backend server, it waits for a response from the backend server for a configured period. Se o servidor back-end não responder dentro deste período (o valor de tempo limite), será marcado como Não saudável até responder novamente dentro do período de tempo limite configurado.

Resolução: verifique o motivo pelo qual o servidor de back-end ou a aplicação não está a responder dentro do período de tempo limite configurado, bem como as dependências da aplicação. Por exemplo, verifique se a base de dados tem algum problema que possa acionar um atraso na resposta. Se estiver ciente do comportamento da aplicação e esta dever responder apenas após o valor de tempo limite, aumente o valor de tempo limite nas definições de sonda personalizadas. Tem de ter uma sonda personalizada para alterar o valor do tempo limite. Para obter informações sobre como configurar uma sonda personalizada, consulte 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 o servidor responder nessa página. Você pode usar qualquer ferramenta para acessar o servidor de back-end, incluindo um navegador usando ferramentas de desenvolvedor.
2. Depois de descobrir o tempo necessário para o aplicativo responder, selecione o separador Sondas de saúde e, depois, selecione a sonda associada às suas definições HTTP.
3. Insira qualquer valor de tempo limite maior que o tempo de resposta do aplicativo, em segundos.
4. Guarde as configurações da sonda personalizada e verifique se o estado de integridade do back-end está agora como Saudável.

Erro de resolução de DNS

Mensagem: O Application Gateway não pôde criar uma sonda para esse back-end. Isso geralmente acontece quando o FQDN do back-end não é inserido corretamente. 

Cause: If the backend pool is of type IP Address, FQDN (fully qualified domain name) or App Service, Application Gateway resolves to the IP address of the FQDN entered through DNS (custom or Azure default). Em seguida, o gateway de aplicação tenta ligar-se ao servidor na porta TCP mencionada nas definições HTTP. No entanto, se esta mensagem for apresentada, sugere que o Gateway de Aplicação não conseguiu resolver com êxito o endereço IP do FQDN introduzido.

Resolução:

1. Verifique se o FQDN introduzido no conjunto de back-end está correto e se é um domínio público. Em seguida, tente resolvê-lo a partir do computador local.
2. Se conseguir resolver o endereço IP, poderá haver algo de errado com a configuração do DNS na rede virtual.
3. Verifique se a rede virtual está configurada com um servidor DNS personalizado. Se for o caso, verifique o servidor DNS sobre o motivo pelo qual não consegue resolver para o endereço IP do FQDN especificado.
4. Se você estiver usando o DNS padrão do Azure, verifique com seu registrador de nomes de domínio se o registro A adequado ou o mapeamento de registro CNAME está completo.
5. Se o domínio for privado ou interno, tente resolvê-lo a partir de uma VM na mesma rede virtual. Se conseguir resolvê-lo, reinicie o Gateway de Aplicação e verifique novamente. Para reiniciar o Gateway de Aplicação, tem de parar e iniciar com os comandos do PowerShell descritos nestes recursos ligados.

Erro de conexão TCP

Mensagem: O Gateway de Aplicação não conseguiu ligar-se ao back-end. Check that the backend responds on the port used for the probe. Verifique também se algum NSG/UDR/Firewall está a bloquear o acesso ao IP e à porta deste back-end.

Causa: Após a fase de resolução de DNS, o Application Gateway tenta se conectar ao servidor back-end na porta TCP configurada nas configurações HTTP. Se o Gateway de Aplicação não conseguir estabelecer uma sessão TCP na porta especificada, a sonda será marcada como Não Saudável com a seguinte mensagem.

Solução: Se receber este erro, siga estes passos:

1. Verifique se você pode se conectar ao servidor back-end na porta mencionada nas configurações HTTP usando um navegador ou 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 de porta correto para o Application Gateway se conectar ao servidor back-end.

3. If you can't connect on the port from your local machine as well, then:

   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 as conexões de entrada com a porta configurada são permitidas. Se não estiverem, crie uma nova regra para permitir as conexões. Para saber como criar regras NSG, consulte a página de documentação.

   b. Verifique se as configurações NSG da sub-rede do Application Gateway permitem tráfego público e privado de saída, para que uma conexão possa ser feita. Verifique a página do documento 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 rotas definidas pelo usuário (UDR) do Application Gateway e da sub-rede do servidor back-end para verificar se há anomalias de roteamento. Verifique se o UDR não está direcionando o tráfego para fora da sub-rede de back-end. For example, check for routes to network virtual appliances or default routes being advertised to the Application Gateway subnet via Azure ExpressRoute and/or VPN.

   d. Para verificar as rotas e regras efetivas 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 nenhum problema com NSG ou UDR, verifique seu servidor back-end para problemas relacionados ao aplicativo que estão impedindo os clientes de estabelecer uma sessão TCP nas portas configuradas. Algumas coisas a verificar:

   a. Abra um prompt de comando (Win+R -> cmd), digite 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: ligações de site no IIS, bloco de servidor no NGINX e host virtual no Apache.

   d. Verifique as definições da firewall do SO para se certificar de que o tráfego de entrada para a porta é permitido.

HTTP status code mismatch

Mensagem: O código de status da resposta HTTP do back-end não correspondeu à configuração do teste. Esperado:{HTTPStatusCode0} Recebido:{HTTPStatusCode1}.

Causa: Depois que a conexão TCP é estabelecida e um handshake TLS é feito (se o TLS estiver habilitado), o Application Gateway envia o teste como uma solicitação HTTP GET para o servidor back-end. As described earlier, the default probe is set to <protocol>://127.0.0.1:<port>/, and it considers response status codes in the range 200 through 399 as Healthy. Se o servidor retornar qualquer outro código de status, ele será marcado como Não saudável com esta mensagem.

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

Erro	Ações
Probe status code mismatch: Received 401	Verifique se o servidor back-end requer autenticação. As sondas do Application Gateway não podem passar credenciais para autenticação. Either allow "HTTP 401" in a probe status code match or probe to a path where the server doesn't require authentication.
Probe status code mismatch: Received 403	Acesso proibido. Verifique se o acesso ao caminho é permitido no servidor back-end.
Probe status code mismatch: Received 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 path para um valor acessível.
Probe status code mismatch: Received 405	As solicitações de teste para o Application Gateway usam o método HTTP GET. Verifique se o servidor permite esse método.
Probe status code mismatch: Received 500	Erro de servidor interno. Verifique o estado de funcionamento do servidor de back-end e se os serviços estão em execução.
Probe status code mismatch: Received 503	Serviço indisponível. Verifique o estado de funcionamento do servidor de back-end e se os serviços estão em execução.

Ou, se achares que a resposta é legítima e quiseres que o Application Gateway aceite outros códigos de estado como Saudável, podes criar uma sonda personalizada. Essa abordagem é útil em situações em que o site de back-end precisa de autenticação. Como as solicitações de teste não possuem credenciais de usuário, elas falharão e um código de status HTTP 401 será retornado pelo servidor de back-end.

Para criar uma sonda personalizada, siga estas etapas.

HTTP response body mismatch

Mensagem: O corpo da resposta HTTP do back-end não correspondeu à configuração do teste. O corpo da resposta recebida não contém {string}.

Cause: When you create a custom probe, you can mark a backend server as Healthy by matching a string from the response body. For example, you can configure Application Gateway to accept "unauthorized" as a string to match. Se a resposta do servidor de back-end para a solicitação de teste contiver a cadeia de caracteres unauthorized, a resposta será marcada como Saudável. Otherwise, it is marked as Unhealthy with the given message.

Solução: Para resolver este problema, siga estes passos:

1. Aceda ao servidor back-end localmente ou a partir de uma máquina cliente no percurso de sondagem e verifique o conteúdo da resposta.
2. Verify that the response body in the Application Gateway custom probe configuration matches what's configured.
3. Se não corresponderem, altere a configuração da sonda para que tenha o valor de cadeia de caracteres correto a aceitar.

Saiba mais sobre a correspondência de sondas no Application Gateway.

Nota

Para todas as mensagens de erro relacionadas ao TLS, para saber mais sobre o comportamento do SNI e as diferenças entre o SKU v1 e v2, verifique a página de visão geral do TLS.

Common Name (CN) doesn't match

Message: (For V2) The Common Name of the leaf certificate presented by the backend server does not match the Probe or Backend Setting hostname of the application gateway.
(Para V1) O nome comum (CN) do certificado de backend não é compatível.

Causa: (Para V2) Isso ocorre quando você seleciona o protocolo HTTPS na configuração de back-end e nem o nome de host da Sonda Personalizada nem da Configuração de Back-end (nessa ordem) corresponde ao Nome Comum (CN) do certificado do servidor de back-end.
(Para V1) O FQDN do destino do pool de back-end não corresponde ao Nome Comum (CN) do certificado do servidor de back-end.

Solução: As informações de nome de host são críticas para a conexão HTTPS de back-end, pois esse valor é usado para definir a Indicação de Nome do Servidor (SNI) durante o handshake TLS. Você pode corrigir esse problema das seguintes maneiras com base na configuração do gateway.

Para V2,

• If you’re using a Default Probe – You can specify a hostname in the associated Backend setting of your application gateway. You can select “Override with specific hostname” or “Pick hostname from backend target” in the backend setting.
• Se estiver a usar uma Sonda Personalizada – Para a Sonda Personalizada, pode usar o campo "host" para especificar o Nome Comum do certificado do servidor de back-end. Como alternativa, se a configuração de back-end já estiver configurada com o mesmo nome de host, você pode selecionar "Selecionar nome de host da configuração de back-end" nas configurações de sonda.

For V1, verify the backend pool target's FQDN is same the Common Name (CN).

Dicas: Para determinar o nome comum (CN) do certificado do servidor back-end, você pode usar qualquer um desses métodos. Observe também que, de acordo com a RFC 6125 , se existir uma SAN, a verificação SNI será feita apenas em relação a esse campo. The common name field is matched if there's no SAN in the certificate.

• Usando o navegador ou qualquer cliente: Acesse o servidor back-end diretamente (não através do Application Gateway) e clique no cadeado do certificado na barra de endereço para visualizar os detalhes do certificado. You can find it under the “Issued To” section.

• Ao fazer login no servidor back-end (Windows):

  1. Entre na máquina onde 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. Digite certlm.msc e selecione Enter. Você também pode procurar o Gerenciador de Certificados no menu Iniciar.
  4. Localize o certificado (normalmente em Certificados - Computador Local\Pessoal\Certificados) e abra o certificado.
  5. Na guia Detalhes, verifique o Assunto do certificado.

• Ao fazer login no servidor back-end (Linux): Execute este comando OpenSSL especificando o nome do arquivo de 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, por conseguinte, o gateway de aplicação marca o servidor de back-end com um certificado expirado como em mau estado de funcionamento.

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

For V2 SKU,

• Expired Leaf (also known as Domain or Server) certificate – Renew the server certificate with certificate provider and install the new certificate on the backend server. Certifique-se de instalar a cadeia completa de certificados composta por Leaf (topmost) > Intermediate(s) > Root. Com base no tipo de Autoridade de Certificação (CA), você pode executar as seguintes ações no gateway.

  • CA conhecida publicamente: se o emissor do certificado for uma autoridade de certificação conhecida, você não precisará executar nenhuma ação no gateway de aplicativo.
  • Private CA: If the leaf certificate is issued by a private CA, you need to check if the signing Root CA certificate has changed. In such cases, you must upload the new Root CA certificate (.CER) to the associated Backend setting of your gateway.

• Certificado Intermediário ou Raiz expirado – Normalmente, esses certificados têm períodos de validade relativamente longos (uma década ou duas). Quando o certificado Root/Intermediate expirar, recomendamos que você verifique com seu provedor de certificados os arquivos de certificado renovados. Ensure you install this updated and complete certificate chain comprising Leaf (topmost) > Intermediate(s) > Root on the backend server.

  • Se o certificado raiz permanecer inalterado ou se o emissor for uma autoridade de certificação conhecida, você NÃO precisará executar nenhuma ação no gateway de aplicativo.
  • When using a Private CA, if the Root CA certificate itself or the root of the renewed Intermediate certificate has changed, you must upload the new Root certificate to the application gateway’s Backend Setting.

For V1 SKU,

• Renew the expired Leaf (also known as Domain or Server) certificate with your CA and upload the same leaf certificate (.CER) to the associated Backend setting of your application gateway.

O certificado intermédio 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: o(s) certificado(s) intermediário(s) não está(ão) instalado(s) na cadeia de certificados no servidor back-end.

Solução: Um certificado intermediário é usado para assinar o certificado Leaf e, portanto, é necessário para completar a cadeia. Verifique junto da Autoridade de Certificação (AC) os Certificados intermédios necessários e instale-os no servidor de back-end. This chain must start with the Leaf Certificate, then the Intermediate certificate(s), and finally, the Root CA certificate. We recommend installing the complete chain on the backend server, including the Root CA certificate. For reference, look at the certificate chain example under Leaf must be topmost in chain.

Nota

Um certificado autoassinado que NÃO é uma Autoridade de Certificação também resulta no mesmo erro. This is because application gateway considers such self-signed certificate as "Leaf" certificate and looks for its signing Intermediate certificate. Você pode seguir este artigo para gerar corretamente um certificado autoassinado.

Estas imagens mostram a diferença entre os certificados autoassinados.

The leaf or server certificate was not found

Mensagem: O certificado Leaf 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 Leaf (também conhecido como Domínio ou Servidor) está em falta na cadeia de certificação do servidor de back-end.

Solution: You can get the leaf certificate from your Certificate Authority (CA). Install this leaf certificate and all its signing certificates (Intermediate and Root CA certificates) on the backend server. This chain must start with the Leaf Certificate, then the Intermediate certificate(s), and finally, the Root CA certificate. We recommend installing the complete chain on the backend server, including the Root CA certificate. For reference, look at the certificate chain example under Leaf must be topmost in chain.

O certificado do servidor não é emitido por uma autoridade de certificação conhecida publicamente

Mensagem: O certificado do servidor back-end não é assinado por uma autoridade de certificação (CA) conhecida. Para usar certificados de CA desconhecidos, o respetivo certificado raiz deve ser carregado na configuração do backend do gateway de aplicação.

Causa: você escolheu "certificado de uma autoridade de certificação conhecida" na configuração do servidor de backend, mas o certificado raiz apresentado pelo servidor de backend não é conhecido publicamente.

Solution: When a Leaf certificate is issued by a private Certificate Authority (CA), the signing Root CA’s certificate must be uploaded to the application gateway’s associated Backend Setting. Isto permite que o seu gateway de aplicação estabeleça uma ligação fidedigna com esse servidor de back-end. Para corrigir esta situação, aceda à configuração do backend associada, selecione "não é uma CA bem conhecida" e carregue o certificado da Autoridade Certificadora Raiz (.CER). To identify and download the root certificate, you can follow the same steps as described under Trusted root certificate mismatch.

O certificado intermediário NÃO é assinado por uma autoridade de certificação conhecida publicamente.

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

Cause: You have chosen “well-known CA certificate” in the backend setting, but the Intermediate certificate presented by the backend server isn't signed by any publicly known CA.

Solution: When a certificate is issued by a private Certificate Authority (CA), the signing Root CA’s certificate must be uploaded to the application gateway’s associated Backend Setting. Isto permite que o seu gateway de aplicação estabeleça uma ligação fidedigna com esse servidor de back-end. To fix this, contact your private CA to get the appropriate Root CA certificate (.CER) and upload that .CER file to the Backend Setting of your application gateway by selecting “not a well-known CA”. We also recommend installing the complete chain on the backend server, including the Root CA certificate, for easy verification.

Trusted root certificate mismatch (no Root certificate on the backend server)

Mensagem: O certificado intermédio não foi assinado por nenhum certificado raiz carregado no gateway de aplicativos. Verifique se a cadeia de certificados está completa e ordenada corretamente no servidor back-end.

Causa: nenhum dos certificados de CA Raiz carregados para a Configuração de Back-end associada assinou o certificado Intermédio instalado no servidor backend. O servidor de back-end tem apenas certificados Leaf e Intermédios instalados.

Solution: A Leaf certificate is signed by an Intermediate certificate, which is signed by a Root CA certificate. When using a certificate from Private Certificate Authority (CA), you must upload the corresponding Root CA certificate to the application gateway. Contacte a sua CA privada para obter o certificado CA Raiz (.CER) adequado e carregue esse ficheiro CER na configuração de back-end do gateway da aplicação.

Trusted root certificate mismatch (Root certificate is available on the backend server)

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. Ensure that you add the correct root certificate to allowlist the backend.

Cause: This error occurs when none of the Root certificates uploaded to your application gateway’s backend setting matches the Root certificate present on the backend server.

Solução: Isso se aplica a um certificado de servidor back-end emitido por uma Autoridade de Certificação (CA) privada ou autoassinado. Identify and upload the right Root CA certificate to the associated backend setting.

Dicas: Para identificar e baixar o certificado raiz, você pode usar qualquer um desses métodos.

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

  1. Escolha o certificado raiz na cadeia e clique em Exportar. Por padrão, este é um ficheiro .CRT.
  2. Abra esse arquivo .CRT.
  3. Vá para a guia Detalhes e clique em "Copiar para arquivo",
  4. Na página Assistente para Exportação de Certificados, clique em Avançar,
  5. Select “Base-64 encoded X.509 (.CER) and click Next,
  6. Dê um novo nome de arquivo e clique em Avançar,
  7. Clique no botão Concluir para obter um ficheiro .CER.
  8. Upload this Root certificate (.CER) of your private CA to the application gateway’s backend setting.

• Efetuando login no servidor back-end (Windows)

  1. Entre na máquina onde seu aplicativo está hospedado.
  2. Selecione Win + R ou clique com o botão direito do mouse no botão Iniciar e, em seguida, selecione Executar.
  3. Digite certlm.msc e selecione Enter. Você também pode procurar o Gerenciador de Certificados no menu Iniciar.
  4. Localize o certificado, normalmente 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. Select “Base-64 encoded X.509 (.CER) and click Next,
  9. Dê um novo nome de arquivo e clique em Avançar,
  10. Clique no botão Concluir para obter um ficheiro .CER.
  11. Upload this Root certificate (.CER) of your private CA to the application gateway’s backend setting.

Leaf must be topmost in chain.

Mensagem: O certificado Leaf 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 Leaf (também conhecido como Domínio ou Servidor) não está instalado na ordem correta no servidor back-end.

Solução: A instalação do certificado no servidor back-end deve incluir uma lista ordenada de certificados que inclui o certificado folha e todos os seus certificados de assinatura (certificados de CA intermediários e raiz). This chain must start with the leaf certificate, then the Intermediate certificate(s), and finally, the Root CA certificate. We recommend installing the complete chain on the backend server, including the Root CA certificate.

A seguir está um exemplo de uma instalação de certificado de servidor juntamente com os certificados CA intermediários e raiz, indicados como níveis (0, 1, 2 e assim por diante) no OpenSSL. Você pode verificar o mesmo para o certificado do seu servidor back-end usando os seguintes comandos OpenSSL.
s_client -connect <FQDN>:443 -showcerts
OU
s_client -connect <IPaddress>:443 -servername <TLS SNI hostname> -showcerts

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 OpenSSL para a mensagem associada ao código de erro {errorCode}

Causa: este erro ocorre quando Gateway de Aplicação não consegue verificar a validade do certificado.

Solução: Para resolver esse problema, verifique se o certificado no servidor foi criado corretamente. Por exemplo, pode utilizar o OpenSSL para verificar o certificado e as propriedades e, em seguida, tentar recarregar o certificado nas definições de HTTP do Gateway de Aplicação.

Backend health status: Unknown

Updates to the DNS entries of the backend pool

Mensagem: Não foi possível recuperar o status de integridade do back-end. Isso acontece quando um NSG/UDR/Firewall na sub-rede do gateway de aplicativo está bloqueando o tráfego nas portas 65503-65534 no caso de SKU v1 e nas portas 65200-65535 no caso do 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 visite - https://aka.ms/UnknownBackendHealth.

Cause: For FQDN (Fully Qualified Domain Name)-based backend targets, the Application Gateway caches and uses the last-known-good IP address if it fails to get a response for the subsequent DNS lookup. Uma operação PUT em um gateway nesse estado limparia completamente seu cache DNS. Como resultado, não haverá nenhum endereço de destino ao qual o gateway possa chegar.

Resolution: Check and fix the DNS servers to ensure it's serving a response for the given FDQN's DNS lookup. Você também deve verificar se os servidores DNS estão acessíveis por meio da Rede Virtual do gateway de aplicativos.

Outras razões

If the backend health is shown as Unknown, the portal view resembles the following screenshot:

Este comportamento pode ocorrer por um ou mais dos seguintes motivos:

1. O NSG na sub-rede do Application Gateway 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 Application Gateway é definido como a rota padrão (0.0.0.0/0) e o próximo salto não é especificado como "Internet".
3. A rota predefinida é anunciada por uma ligação ExpressRoute/VPN a uma rede virtual por BGP.
4. O servidor DNS personalizado está configurado numa rede virtual que não consegue resolver os nomes de domínio públicos.
5. Application Gateway is in an Unhealthy state.

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 onde o Application Gateway está 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 secção Regras de Entrada, adicione uma regra de entrada para permitir o intervalo de portas de destino 65503-65534 para SKU v1 ou 65200-65535 para SKU v2 com a Origem definida como a etiqueta de serviço GatewayManager. f. Selecione Guardar e verifique se consegue ver o back-end como Saudável. 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 um UDR está configurado. Se houver, procure o recurso na barra de pesquisa ou em Todos os recursos. c. Verifique se há rotas padrão (0.0.0.0/0) com o próximo salto não definido como Internet. Se a configuração for Dispositivo Virtual ou Gateway de Rede Virtual, verifique se o dispositivo virtual ou o dispositivo local pode rotear corretamente o pacote de volta para o destino da Internet sem modificá-lo. Se as sondas forem encaminhadas através de um dispositivo virtual e modificadas, o recurso de back-end apresenta um código de status 200 e o status de integridade do Application Gateway pode ser exibido como Desconhecido. Isso não indica um erro. O tráfego ainda deve ser roteado através do Application Gateway 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 para a rede virtual através de BGP (Border Gateway Protocol):

   a. Se você tiver uma conexão ExpressRoute/VPN com a rede virtual por BGP e estiver anunciando uma rota padrão, verifique se o pacote é roteado de volta 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 Application Gateway. b. Escolha o destino manualmente como qualquer endereço IP roteável pela Internet, como 1.1.1.1. Defina a porta de destino como qualquer coisa e verifique a conectividade. c. Se o próximo salto for um gateway de rede virtual, pode haver uma rota padrão anunciada pelo ExpressRoute ou pela VPN.

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

5. Para verificar se o Application Gateway está saudável e em execução, vá para a opção Integridade do recurso no portal e verifique se o estado está Saudável. If you see an Unhealthy or Degraded state, contact support.

6. Se a Internet e o tráfego privado estiverem passando por um Firewall do Azure hospedado em um hub virtual seguro (usando o Hub 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 WAN Virtual, configure a seguinte rota definida pelo usuário:

   Address Prefix: Backend pool subnet
   Próximo salto: Endereço IP privado do Firewall do Azure

Nota

If the application gateway is not able to access the CRL endpoints, it might mark the backend health status as "unknown". Para evitar esses problemas, verifique se a sub-rede do gateway de aplicativo é capaz de acessar crl.microsoft.com e crl3.digicert.com. Isso pode ser feito configurando os seus Grupos de Segurança de Rede para enviar tráfego para os endereços da CRL.

Próximos passos

Saiba mais sobre o diagnóstico e o registro em log do Application Gateway.