Laboratório de Troubleshooting: Configure TLS Termination and End-to-End TLS Encryption
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de operações relata que uma aplicação publicada via Azure Application Gateway v2 começou a retornar erro HTTP 502 para todos os clientes externos após uma janela de manutenção realizada na madrugada anterior. Antes da manutenção, a aplicação funcionava normalmente.
O engenheiro responsável confirma que durante a manutenção foram feitas duas alterações: renovação do certificado TLS instalado nos servidores de backend e atualização do sistema operacional das VMs do pool de backend. Os servidores de backend estão respondendo normalmente a testes internos via HTTP na porta 80.
Os logs do Application Gateway mostram o seguinte:
[ERROR] Backend connect error: SSL handshake failed
[ERROR] Backend: 10.0.1.10:443
[ERROR] Certificate chain validation failed: unable to get local issuer certificate
[INFO] Frontend listener: HTTPS/443 - OK
[INFO] Health probe: HTTP/80 - Healthy
O health probe do backend está configurado para HTTP na porta 80 e retorna status Healthy para todas as instâncias do pool.
Qual é a causa raiz do erro 502 observado?
A) O certificado TLS do listener frontend foi corrompido durante a manutenção, impedindo o estabelecimento de novas conexões TLS com os clientes
B) O certificado renovado nos backends foi emitido por uma CA diferente da anterior, e o novo certificado raiz não foi atualizado como Trusted Root Certificate nas configurações HTTP do backend do Application Gateway
C) A atualização do sistema operacional das VMs alterou a configuração de porta, fazendo os backends pararem de escutar na porta 443
D) O health probe está configurado para HTTP e por isso não detecta a falha TLS, o que causa o erro 502 indiretamente
Cenário 2 — Decisão de Ação
A causa do problema foi identificada: o certificado de domínio customizado associado ao Azure Front Door expirou há 18 horas. O Front Door está usando um certificado BYOC (Bring Your Own Certificate) armazenado no Azure Key Vault. O certificado no Key Vault já foi substituído pela equipe de PKI com uma nova versão válida, mas o Front Door continua retornando erros TLS para os clientes.
O ambiente possui as seguintes restrições:
- A aplicação está em produção com SLA ativo de 99,9%
- O domínio customizado não pode ser removido e recriado sem aprovação do Change Advisory Board, processo que leva no mínimo 4 horas
- A equipe tem acesso completo ao portal do Azure e à CLI
- Já se passaram 20 minutos desde a substituição do certificado no Key Vault sem que o Front Door detectasse a atualização automaticamente
Qual é a ação correta a tomar neste momento?
A) Aguardar mais 40 minutos, pois o Front Door pode levar até 1 hora para sincronizar automaticamente a nova versão do certificado a partir do Key Vault
B) Remover o domínio customizado do Front Door e recriá-lo apontando para o novo certificado
C) Acessar as configurações do domínio customizado no Front Door e acionar manualmente a atualização do certificado, apontando para a nova versão no Key Vault
D) Substituir o certificado BYOC por um certificado gerenciado pelo Front Door para eliminar a dependência do Key Vault
Cenário 3 — Causa Raiz
Uma aplicação web corporativa é publicada via Azure Application Gateway v2 com end-to-end TLS configurado. Os backends utilizam certificados emitidos pela CA interna da empresa, e o certificado raiz da CA está corretamente registrado como Trusted Root Certificate nas configurações HTTP do backend.
Na última semana, três dos oito servidores do backend pool começaram a apresentar falhas intermitentes. Os logs coletados mostram:
[WARN] Backend: 10.0.2.14:443 - Connection established
[WARN] Backend: 10.0.2.14:443 - SSL handshake timeout after 10000ms
[WARN] Backend: 10.0.2.15:443 - Connection established
[WARN] Backend: 10.0.2.15:443 - SSL handshake timeout after 10000ms
[INFO] Backend: 10.0.2.10:443 - Handshake OK
[INFO] Backend: 10.0.2.11:443 - Handshake OK
[INFO] Backend: 10.0.2.12:443 - Handshake OK
A equipe de infraestrutura informa que os três servidores afetados receberam uma atualização de configuração de segurança que restringiu os cipher suites aceitos para um conjunto mais restritivo, alinhado a uma política interna de hardening. Os outros cinco servidores ainda não foram atualizados.
O health probe está configurado para HTTPS e marca os três servidores como Unhealthy de forma intermitente.
Qual é a causa raiz das falhas de handshake observadas?
A) O certificado raiz da CA interna está expirado, fazendo o Application Gateway rejeitar a cadeia de confiança nos três servidores
B) O health probe HTTPS está sobrecarregando os três servidores com verificações simultâneas, causando timeout por esgotamento de conexões
C) Os cipher suites habilitados nos três servidores após o hardening são incompatíveis com os cipher suites permitidos pela SSL Policy configurada no Application Gateway
D) O certificado individual de dois dos três servidores afetados foi revogado pela CA interna durante o processo de hardening
Cenário 4 — Sequência de Diagnóstico
Um engenheiro recebe um chamado relatando que uma nova rota publicada no Azure Application Gateway retorna erro SSL_ERROR_HANDSHAKE_FAILURE nos browsers dos usuários ao tentar acessar https://app.contoso.com/api/v2. Outras rotas do mesmo gateway funcionam normalmente.
O engenheiro tem acesso ao portal do Azure, ao Key Vault e aos logs do gateway. Ele identifica os seguintes passos que precisam ser executados, mas precisa ordená-los corretamente:
[P] Verificar se o listener HTTPS associado à rota /api/v2 possui um certificado TLS válido e não expirado
[Q] Analisar os logs de acesso do Application Gateway para identificar o código de erro retornado no backend
[R] Confirmar que a Backend HTTP Setting da rota /api/v2 aponta para protocolo HTTPS e porta correta
[S] Testar diretamente o endpoint do backend via curl com verbose TLS para isolar se o problema ocorre antes ou depois do gateway
[T] Verificar se a SSL Policy aplicada ao gateway é compatível com os clientes que estão falhando
Qual sequência representa a ordem correta de diagnóstico, do mais externo para o mais interno?
A) T, P, Q, S, R
B) P, T, Q, R, S
C) Q, P, T, R, S
D) P, Q, R, S, T
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista determinante está na combinação de dois fatos: o certificado foi renovado (não apenas reemitido com a mesma CA) e o log indica explicitamente unable to get local issuer certificate, que é a mensagem de falha de validação de cadeia de confiança do lado do Application Gateway ao tentar verificar o certificado apresentado pelo backend.
Quando o novo certificado foi emitido por uma CA diferente da original, o Application Gateway não consegue mais construir a cadeia de confiança a partir do Trusted Root Certificate anteriormente registrado. O resultado é a falha de handshake e o consequente erro 502 para os clientes.
A informação sobre a atualização do SO das VMs é o elemento irrelevante do cenário: os backends respondem normalmente na porta 80 (confirmado pelo health probe) e os logs mostram que o gateway consegue abrir a conexão TCP com a porta 443, mas o handshake TLS falha, o que descarta qualquer problema de porta ou conectividade.
A opção A é um distrator que direciona o raciocínio para o lado errado do fluxo: o log confirma que o listener frontend está OK. A opção D representa um erro de raciocínio clássico: o health probe funcionando em HTTP indica apenas que os servidores estão vivos na camada de aplicação; ele é completamente cego a falhas TLS na porta 443. Agir com base nesse distrator levaria o engenheiro a concluir erroneamente que os backends estão saudáveis e investigar o gateway na direção errada.
Gabarito — Cenário 2
Resposta: C
Quando o Azure Front Door usa um certificado BYOC armazenado no Key Vault, ele mantém uma referência à versão do certificado. A simples substituição do segredo no Key Vault não aciona uma sincronização automática imediata no Front Door. O mecanismo correto para forçar a adoção do novo certificado sem recriação do domínio é atualizar manualmente a referência do certificado nas configurações do domínio customizado no Front Door, apontando para a nova versão disponível no Key Vault.
A opção A apresenta uma restrição de tempo que não corresponde ao comportamento real: embora o Front Door possa demorar alguns minutos para propagar configurações, aguardar indefinidamente sem acionar a atualização não é a ação correta em um ambiente com SLA ativo. A opção B viola explicitamente a restrição mais crítica do cenário: remover e recriar o domínio requer aprovação que leva no mínimo 4 horas, tempo inaceitável dada a situação. A opção D é tecnicamente válida como solução permanente, mas neste momento ela não resolve o problema imediato: migrar para certificado gerenciado envolve um processo de provisionamento que pode levar minutos a horas, além de não ser necessário quando o certificado já está disponível no Key Vault.
Gabarito — Cenário 3
Resposta: C
A causa raiz está na incompatibilidade de cipher suites entre os backends endurecidos e a SSL Policy do Application Gateway. O diagrama de eliminação é direto: os cinco servidores não afetados usam os mesmos certificados da mesma CA interna e funcionam normalmente, o que descarta qualquer problema com o Trusted Root Certificate. A única variável que diferencia os três servidores afetados dos demais é a atualização dos cipher suites aceitos.
O Application Gateway, ao tentar negociar o handshake TLS de saída com esses backends, não encontra nenhum cipher suite em comum entre o que sua SSL Policy permite e o que os servidores agora aceitam. A negociação falha na fase de ClientHello/ServerHello, resultando em timeout ou rejeição, exatamente como descrito nos logs.
O elemento irrelevante propositalmente incluído é o comportamento intermitente do health probe: ele segue o mesmo padrão das falhas TLS porque o probe HTTPS também tenta negociar TLS com o backend, mas isso descreve o sintoma do health probe, não a causa das falhas.
A opção D é o distrator mais perigoso: um engenheiro que se apresse em verificar revogação de certificados perderia tempo em um caminho completamente errado, pois certificados revogados produzem mensagens de erro diferentes (relacionadas a CRL ou OCSP), não timeouts de handshake.
Gabarito — Cenário 4
Resposta: B
A sequência correta de diagnóstico para uma falha de handshake TLS que afeta apenas uma rota específica segue a lógica de investigação do ponto mais próximo do cliente para o mais próximo do backend, validando cada camada antes de avançar.
P vem primeiro porque o erro SSL_ERROR_HANDSHAKE_FAILURE é reportado pelo browser do cliente, e a primeira hipótese a eliminar é um problema no próprio certificado do listener: se o certificado estiver expirado ou ausente no listener associado à rota /api/v2, o handshake falha antes de qualquer outra camada.
T vem em seguida porque, se o certificado do listener está válido, o próximo candidato é uma incompatibilidade de SSL Policy entre o gateway e os browsers dos clientes que falham.
Q vem depois de validar o lado do cliente porque, com o listener e a policy confirmados como corretos, os logs do gateway revelarão se o problema está na comunicação com o backend ou se o gateway está rejeitando a requisição por outro motivo.
R entra para verificar se a Backend HTTP Setting está configurada corretamente para a rota afetada, já que as outras rotas funcionam, sugerindo que pode haver uma configuração específica desta rota que difere das demais.
S fecha a sequência com um teste direto no backend, que só faz sentido após confirmar que todos os componentes do gateway estão configurados corretamente e o problema está além do gateway.
A sequência D parece intuitiva porque começa pelos logs, mas analisar logs antes de confirmar a configuração básica do listener gera ruído: os logs mostrariam o erro sem que o engenheiro soubesse ainda se o listener sequer tem um certificado válido associado.
Árvore de Troubleshooting: Configure TLS Termination and End-to-End TLS Encryption
Legenda de cores:
| Cor | Significado |
|---|---|
| Azul escuro | Sintoma inicial (nó raiz) |
| Azul | Pergunta diagnóstica (decisão) |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Nó de validação ou verificação intermediária |
Para usar esta árvore diante de um problema real, comece pelo nó raiz descrevendo o sintoma geral de falha TLS. A primeira bifurcação separa erros que se manifestam no lado do cliente (handshake com o listener do gateway) dos erros que ocorrem na comunicação com o backend (502). A partir dessa separação, cada ramificação faz uma pergunta objetiva e verificável no portal do Azure, nos logs do gateway ou diretamente nos servidores. Siga as respostas sem pular etapas: cada nó laranja representa um ponto de verificação intermediária antes de declarar uma causa. Ao alcançar um nó vermelho, a causa está identificada e o nó verde seguinte indica a ação corretiva correspondente.