Laboratório de Troubleshooting: Configure Transport Layer Security (TLS)
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de operações recebe chamados de usuários relatando que o site corporativo, publicado via Azure Application Gateway (SKU v2), apresenta erro de certificado no navegador apenas para um subconjunto de usuários. A investigação inicial revela que os usuários afetados estão em filiais que utilizam clientes mais antigos. Usuários em escritórios centrais, com navegadores atualizados, não relatam nenhum problema.
O engenheiro responsável verifica o portal e confirma que o certificado SSL instalado no listener HTTPS é válido, emitido por uma CA pública reconhecida, e está dentro do prazo de validade. O certificado usa uma chave RSA de 2048 bits. A equipe também confirma que o DNS está resolvendo corretamente para o IP público do gateway.
A política SSL aplicada ao Application Gateway está configurada da seguinte forma:
{
"sslPolicy": {
"policyType": "Custom",
"minProtocolVersion": "TLSv1_2",
"cipherSuites": [
"TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"
]
}
}
Qual é a causa raiz do erro observado nos clientes das filiais?
A) O certificado RSA de 2048 bits não é suportado pelos cipher suites ECDHE configurados, gerando falha de handshake.
B) A política SSL personalizada define TLS 1.2 como versão mínima e cipher suites exclusivamente com ECDHE, excluindo clientes antigos que suportam apenas TLS 1.0 ou 1.1 com cipher suites RSA legados.
C) O Application Gateway SKU v2 não suporta políticas SSL personalizadas; é necessário usar uma política predefinida para que o handshake seja completado corretamente.
D) O certificado instalado no listener não inclui o nome alternativo de sujeito (SAN) necessário para os clientes das filiais, fazendo com que a validação falhe nesses ambientes.
Cenário 2 — Sequência de Diagnóstico
Um engenheiro recebe o seguinte alerta de uma aplicação publicada via Azure Front Door Premium:
Error: SSL handshake failed for origin 'api-backend-eastus.azurewebsites.net'
Code: OriginTlsError
Details: The origin presented a certificate that could not be validated.
Timestamp: 2025-10-14T03:22:11Z
O Front Door está configurado com TLS de ponta a ponta. O backend é um Azure App Service com certificado gerenciado pela própria plataforma. O domínio personalizado no Front Door foi configurado há seis meses sem problemas. Não houve mudanças de configuração no Front Door nos últimos 30 dias.
Os passos de investigação disponíveis são:
- Verificar se o certificado do App Service foi renovado corretamente e se o Common Name corresponde ao hostname do origin configurado no Front Door.
- Confirmar que a opção de verificação de nome de certificado do origin está habilitada na configuração do origin group.
- Verificar o histórico de renovação do certificado gerenciado pelo App Service no portal Azure.
- Testar a conectividade HTTPS diretamente ao endpoint do App Service a partir de um cliente externo para confirmar que o certificado é apresentado corretamente.
- Revisar os logs de acesso do App Service para identificar se requisições do Front Door estão chegando ao backend.
Qual é a sequência correta de investigação para esse sintoma?
A) 5 → 2 → 1 → 3 → 4
B) 2 → 5 → 3 → 1 → 4
C) 4 → 1 → 3 → 2 → 5
D) 1 → 3 → 4 → 2 → 5
Cenário 3 — Causa Raiz
Uma organização expõe APIs internas via Azure API Management (APIM) integrado a uma rede virtual em modo externo. O time de segurança habilitou autenticação mútua TLS (mTLS) e configurou a política abaixo para validar o certificado de cliente apresentado:
<inbound>
<validate-client-certificate
validate-revocation="true"
validate-trust="true"
validate-not-before="true"
validate-not-after="true"
certificate-ids="valid-client-cert" />
</inbound>
Após a implantação, parceiros externos reportam que suas requisições estão sendo rejeitadas com HTTP 403, mesmo apresentando certificados válidos emitidos pela CA corporativa. O time confirma que:
- A opção Negotiate client certificate está habilitada no APIM.
- Os certificados dos parceiros foram adicionados ao portal do APIM como certificados de cliente confiáveis.
- O APIM está em execução no SKU Premium e a integração de rede virtual está ativa e saudável.
- O firewall de rede virtual permite tráfego na porta 443 de entrada.
Qual é a causa raiz das rejeições?
A) O SKU Premium do APIM não suporta validação de revogação em tempo real via validate-revocation="true" em modo de rede virtual externo, causando falha na política.
B) Os certificados dos parceiros foram adicionados ao APIM como certificados de cliente, mas a política faz referência a um certificate-ids específico que não corresponde ao identificador usado no portal ao cadastrar esses certificados.
C) A validação de revogação (validate-revocation="true") requer que o APIM consiga acessar os endpoints CRL ou OCSP da CA corporativa, e a configuração de rede virtual está bloqueando esse tráfego de saída.
D) A integração de rede virtual em modo externo impede que o APIM processe políticas validate-client-certificate; esse recurso é exclusivo do modo interno.
Cenário 4 — Decisão de Ação
A causa foi identificada: um Application Gateway em produção está apresentando handshake failures porque o certificado SSL no listener expirou há duas horas. O certificado era autogerenciado e não havia alerta de renovação configurado. O ambiente afetado processa transações financeiras e o impacto atual é total para os usuários finais.
O time tem as seguintes informações disponíveis:
- Um novo certificado válido, emitido pela CA corporativa, já foi gerado e está disponível em formato PFX com senha conhecida.
- O processo normal de atualização de certificado no Application Gateway via portal leva aproximadamente 3 minutos e não requer reinicialização do gateway.
- A equipe cogita também migrar o gerenciamento do certificado para o Azure Key Vault com renovação automática, para evitar recorrência.
- Existe uma janela de manutenção programada para o próximo sábado às 2h.
Qual é a ação correta a tomar neste momento?
A) Aguardar a janela de manutenção do próximo sábado para substituir o certificado e, simultaneamente, configurar a integração com o Key Vault para renovação automática, realizando ambas as mudanças em conjunto.
B) Substituir imediatamente o certificado expirado no listener do Application Gateway com o novo certificado PFX disponível, restaurando o serviço, e planejar a migração para Key Vault em momento posterior.
C) Configurar primeiro a integração com o Key Vault e apontar o listener para o novo certificado gerenciado pelo vault, pois essa abordagem resolve o problema imediato e previne recorrência em uma única ação.
D) Redirecionar temporariamente o tráfego para HTTP enquanto a integração com o Key Vault é configurada, garantindo continuidade do serviço durante a correção definitiva.
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista decisiva está na combinação de dois elementos: a política define TLS 1.2 como versão mínima e restringe os cipher suites exclusivamente a algoritmos ECDHE. Clientes antigos, tipicamente encontrados em ambientes corporativos de filiais com menor frequência de atualização, frequentemente suportam apenas TLS 1.0 ou 1.1, além de dependerem de cipher suites RSA legados como TLS_RSA_WITH_AES_256_CBC_SHA. Como nenhuma dessas combinações é aceita pela política configurada, o handshake falha antes mesmo de o certificado ser apresentado.
A informação sobre o DNS resolvendo corretamente e o certificado dentro da validade é deliberadamente irrelevante neste cenário. O problema não é o certificado em si, mas a negociação do protocolo.
A alternativa A representa um equívoco técnico comum: certificados RSA são completamente compatíveis com cipher suites ECDHE, pois o RSA é usado para autenticação, enquanto o ECDHE é o mecanismo de troca de chaves. A alternativa C é falsa: o SKU v2 suporta plenamente políticas personalizadas. A alternativa D descreve um problema real em outros contextos, mas sem nenhum indício no enunciado de que o SAN está ausente ou incorreto.
O distrator mais perigoso é D, pois pode levar o engenheiro a substituir um certificado válido sem resolver o problema real, desperdiçando tempo em produção.
Gabarito — Cenário 2
Resposta: C
A sequência correta é 4 → 1 → 3 → 2 → 5, e segue a lógica diagnóstica de validar o mais próximo da falha antes de aprofundar.
O erro indica que o Front Door não consegue validar o certificado do origin. O primeiro passo é confirmar diretamente (passo 4) se o App Service está apresentando um certificado válido e acessível externamente, isolando se o problema está no certificado em si ou na configuração do Front Door. Em seguida, verifica-se (passo 1) se o Common Name do certificado corresponde ao hostname configurado como origin, pois uma divergência aqui causaria exatamente esse erro. O passo 3 então aprofunda a investigação no histórico de renovação, uma vez que o certificado é gerenciado pela plataforma e pode ter sido renovado com um novo Common Name. O passo 2 verifica a configuração de validação no origin group do Front Door. O passo 5 verifica os logs do App Service e é o último, pois só é necessário se os passos anteriores não revelarem a causa.
A alternativa A começa verificando logs de acesso, o que não é útil antes de confirmar se o certificado é válido. A alternativa B começa pela configuração do Front Door, ignorando que o erro está explicitamente relacionado ao certificado do origin. A alternativa D é a correta: começa no ponto de falha declarado e progride da causa mais provável para a menos provável.
O detalhe de que não houve mudanças no Front Door nos últimos 30 dias é a informação irrelevante do cenário, inserida para induzir o leitor a descartar o Front Door como fonte do problema. A causa mais provável é a renovação automática do certificado do App Service com um Common Name diferente do hostname configurado.
Gabarito — Cenário 3
Resposta: C
A causa raiz está no caminho de saída de rede do APIM. A validação de revogação (validate-revocation="true") exige que o APIM consulte ativamente os endpoints CRL (Certificate Revocation List) ou OCSP (Online Certificate Status Protocol) da CA corporativa no momento da validação. Em ambientes com integração de rede virtual, esse tráfego de saída para os endpoints da CA precisa estar explicitamente permitido. Se o grupo de segurança de rede ou a tabela de rotas bloquear esse tráfego, a validação de revogação falha, e a política rejeita o certificado mesmo que ele seja tecnicamente válido.
O enunciado menciona que o firewall permite tráfego de entrada na porta 443, mas nada diz sobre o tráfego de saída para os endpoints CRL/OCSP. Esse é o detalhe relevante que distingue a causa real das alternativas.
A alternativa B é um distrator plausível, mas o enunciado confirma que os certificados foram adicionados ao APIM. A alternativa A é falsa: o SKU Premium suporta validação de revogação independentemente do modo de rede virtual. A alternativa D é tecnicamente incorreta: a política validate-client-certificate funciona em ambos os modos.
O distrator mais perigoso é B, pois levaria o engenheiro a reconfigurar os certificate-ids repetidamente sem resolver o problema real, mantendo o serviço degradado por mais tempo.
Gabarito — Cenário 4
Resposta: B
O contexto define claramente a restrição crítica: o impacto é total e imediato em um ambiente de produção financeiro. A ação correta é a que resolve o problema no menor tempo possível sem introduzir riscos adicionais. A substituição do certificado PFX no listener do Application Gateway é uma operação de aproximadamente 3 minutos, sem reinicialização, com o novo certificado já disponível. Isso restaura o serviço imediatamente.
A migração para Key Vault é uma melhoria relevante, mas é uma mudança de arquitetura que não deve ser realizada sob pressão de incidente ativo. Misturar a correção emergencial com uma mudança estrutural aumenta o risco de erro e prolonga o impacto.
A alternativa A ignora a urgência: aguardar a janela de manutenção do sábado com impacto total em produção é inaceitável. A alternativa C parece eficiente, mas configurar a integração com Key Vault durante um incidente ativo é uma operação mais complexa e sujeita a erros, podendo prolongar o downtime. A alternativa D é a mais perigosa: redirecionar transações financeiras para HTTP, mesmo que temporariamente, viola requisitos de segurança e compliance, e provavelmente está bloqueado por políticas organizacionais.
Árvore de Troubleshooting: Configure Transport Layer Security (TLS)
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica |
| Laranja | Verificação ou validação intermediária |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
Para usar esta árvore diante de um problema real, comece pelo nó raiz com o sintoma observado e responda objetivamente cada pergunta de diagnóstico. As ramificações com "Sim" e "Não" conduzem progressivamente à causa, eliminando hipóteses a cada nível. Quando um nó laranja de verificação intermediária for atingido, colete os dados indicados antes de avançar. Ao chegar em um nó vermelho de causa identificada, a ação recomendada correspondente em verde indica a correção precisa para aquele caminho diagnóstico.