Laboratório de Troubleshooting: Configure certificates and Transport Layer Security (TLS) for an App Service
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma aplicação web hospedada em um App Service no plano Standard S1 foi recentemente migrada para um novo domínio personalizado portal.contoso.com. A equipe de operações configurou um binding TLS do tipo SNI SSL e carregou um certificado .pfx adquirido de uma autoridade certificadora externa. O certificado cobre exatamente o domínio portal.contoso.com e tem validade até 2026.
Após a configuração, os usuários relatam que o navegador exibe o seguinte aviso:
NET::ERR_CERT_COMMON_NAME_INVALID
O certificado apresentado é válido para: shop.contoso.com
Informações coletadas pela equipe:
- O App Service responde corretamente em
https://portal.contoso.compara o time interno - O registro DNS do tipo
CNAMEaponta corretamente paracontoso-app.azurewebsites.net - O plano Standard está ativo e sem alertas no portal
- O upload do certificado foi feito com senha correta e o portal confirmou o thumbprint
Qual é a causa raiz do problema observado?
A) O tipo de binding SNI SSL é incompatível com o plano Standard S1
B) O certificado carregado cobre um domínio diferente do domínio personalizado configurado no binding
C) O registro DNS CNAME ainda está em propagação e alguns usuários estão sendo roteados para o endpoint antigo
D) O App Service está com cache de TLS habilitado, entregando o certificado anterior da configuração antiga
Cenário 2 — Decisão de Ação
A equipe de segurança identificou que um App Service em produção está aceitando conexões TLS 1.0. A causa foi confirmada: o campo Minimum TLS Version em Configuration > General settings está definido como 1.0. A aplicação processa dados financeiros e a política corporativa exige TLS 1.2 como mínimo.
O App Service está em produção contínua, atendendo aproximadamente 4.000 usuários simultâneos. A mudança da versão mínima de TLS não requer reinicialização da aplicação e entra em vigor imediatamente. A equipe sabe que um subconjunto de usuários opera em dispositivos corporativos legados que suportam apenas TLS 1.0, e que esses dispositivos estão em processo de substituição com previsão de conclusão em 30 dias.
Qual é a ação correta a tomar neste momento?
A) Alterar imediatamente o Minimum TLS Version para 1.2, pois a política de segurança tem precedência sobre compatibilidade com dispositivos legados
B) Aguardar 30 dias até a conclusão da substituição dos dispositivos legados e então alterar a versão mínima
C) Alterar o Minimum TLS Version para 1.1 como medida intermediária, eliminando TLS 1.0 sem afetar os dispositivos legados
D) Criar um segundo App Service com TLS 1.2 obrigatório e redirecionar gradualmente o tráfego via Traffic Manager
Cenário 3 — Causa Raiz
Um App Service no plano Basic B2 tem um domínio personalizado api.fabrikam.io configurado corretamente. A equipe carregou um certificado .pfx válido e tentou criar um binding do tipo IP Based SSL. O portal do Azure exibiu a seguinte mensagem de erro ao salvar o binding:
The pricing tier 'Basic' does not support IP-based SSL.
Please upgrade your App Service plan to use this feature.
Após ver o erro, um administrador júnior tomou as seguintes ações sem consultar a equipe:
- Removeu o binding com erro
- Recriou o binding como SNI SSL
- Testou o acesso via navegador moderno e confirmou HTTPS funcionando
- Fechou o incidente como resolvido
No dia seguinte, o time de integrações reporta que um parceiro externo não consegue mais se conectar ao endpoint api.fabrikam.io. O parceiro usa um sistema legado que não suporta SNI.
Qual é a causa raiz da falha relatada pelo parceiro?
A) O certificado .pfx foi corrompido durante a remoção e recriação do binding
B) O binding SNI SSL não é suportado no plano Basic B2 e o certificado está sendo entregue sem criptografia
C) A troca do tipo de binding de IP Based SSL para SNI SSL tornou o endpoint inacessível para clientes sem suporte a SNI
D) O domínio personalizado api.fabrikam.io perdeu a verificação de propriedade após a remoção do binding original
Cenário 4 — Sequência de Diagnóstico
Um App Service apresenta o seguinte comportamento: ao acessar https://crm.wingtip.com, o navegador exibe aviso de certificado expirado. O domínio usa um certificado carregado manualmente (não um certificado gerenciado). A equipe precisa diagnosticar e resolver o problema.
Os seguintes passos de investigação estão disponíveis, fora de ordem:
- Passo P: Carregar um novo certificado
.pfxválido no App Service viaCertificates > Bring your own certificates - Passo Q: Verificar a data de expiração do certificado atual em
Certificatesno portal do Azure - Passo R: Atualizar o binding em
Custom domains > TLS/SSL bindingspara apontar para o novo certificado pelo thumbprint - Passo S: Confirmar que o novo certificado cobre o domínio
crm.wingtip.come que o arquivo.pfxinclui a chave privada - Passo T: Validar o acesso em
https://crm.wingtip.come confirmar que o navegador não exibe mais o aviso
Qual é a sequência correta de investigação e resolução?
A) Q, P, S, R, T
B) S, Q, P, R, T
C) Q, S, P, R, T
D) P, S, R, Q, T
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A mensagem NET::ERR_CERT_COMMON_NAME_INVALID com a indicação de que o certificado é válido para shop.contoso.com revela diretamente que o certificado carregado não corresponde ao domínio configurado no binding. O certificado cobre um domínio diferente (shop.contoso.com), e por isso o navegador rejeita a conexão.
A pista decisiva no enunciado é a própria mensagem de erro do navegador, que exibe o domínio coberto pelo certificado. Essa informação elimina todas as outras hipóteses sem necessidade de investigação adicional.
A informação irrelevante no enunciado é o fato de o time interno conseguir acessar o endpoint corretamente. Isso pode ocorrer por variações de cache de DNS, mas não altera a causa do aviso de certificado, que é independente de roteamento DNS.
O distrator C é o mais perigoso: em cenários de migração, a propagação de DNS é uma suspeita comum e legítima, mas o aviso exibido não é de erro de resolução de nome, e sim de incompatibilidade de certificado. Agir com base nessa hipótese levaria a equipe a aguardar uma propagação que já ocorreu, enquanto o certificado errado permanece no binding.
Gabarito — Cenário 2
Resposta: A
O enunciado deixa explícito que a política corporativa exige TLS 1.2 como mínimo e que a mudança não causa interrupção de serviço. Dado que a restrição de segurança é definida por política organizacional e não por escolha técnica opcional, a ação correta é aplicar imediatamente a configuração exigida.
A alternativa B ignora a política de segurança e prioriza compatibilidade com dispositivos em processo de descomissionamento. Esse raciocínio é uma restrição autoimposta que não existe no enunciado: a política não prevê exceção por prazo.
A alternativa C representa uma ação tecnicamente possível, mas que não atende à política corporativa. TLS 1.1 também é considerado inseguro e não satisfaz o requisito de versão mínima 1.2.
A alternativa D é uma solução de arquitetura correta para outros cenários, mas introduz complexidade operacional desnecessária quando a solução é uma mudança de configuração pontual sem impacto de disponibilidade. Criar uma infraestrutura paralela para contornar uma configuração de uma linha é um erro de proporcionalidade de resposta.
Gabarito — Cenário 3
Resposta: C
O parceiro usa um sistema legado sem suporte a SNI. O binding SNI SSL depende da extensão SNI do protocolo TLS para que o servidor identifique qual certificado apresentar durante o handshake. Clientes que não enviam o campo SNI no handshake não conseguem estabelecer conexão TLS corretamente com bindings desse tipo quando há múltiplos certificados no mesmo endereço IP.
A causa raiz não é o binding ter sido recriado em si, e sim o tipo de binding escolhido ser incompatível com o cliente legado do parceiro.
A informação relevante que confirma o diagnóstico é a combinação de dois fatos: o parceiro usa sistema legado sem suporte a SNI, e o binding foi alterado de IP Based SSL para SNI SSL. A falha ocorreu exatamente após essa mudança.
A alternativa D é o distrator mais perigoso. Em cenários de remoção e recriação de domínios personalizados, a verificação de propriedade pode de fato ser afetada. No entanto, se o domínio tivesse perdido a verificação, o sintoma seria um erro de resolução ou redirecionamento para o hostname padrão do App Service, não uma falha de conexão TLS seletiva afetando apenas o sistema do parceiro.
Gabarito — Cenário 4
Resposta: C
A sequência correta é Q, S, P, R, T.
O raciocínio diagnóstico progressivo exige:
- Q — Confirmar o problema no certificado atual verificando a expiração, o que valida o sintoma antes de qualquer ação
- S — Antes de carregar qualquer arquivo, validar que o novo certificado cobre o domínio correto e contém a chave privada, evitando retrabalho
- P — Somente após validar o novo certificado, realizar o upload
- R — Após o upload, atualizar o binding para referenciar o novo thumbprint
- T — Validar o resultado final no navegador para confirmar a resolução
A alternativa A (Q, P, S, R, T) inverte a ordem de S e P: o arquivo seria carregado antes de ser validado, o que pode resultar em upload de um certificado que não cobre o domínio ou que não contém a chave privada, forçando um novo ciclo de remoção e recarregamento.
A alternativa D começa pelo upload antes de qualquer diagnóstico ou validação, o que representa o erro mais grave: agir antes de entender o problema e antes de verificar a adequação do material que será usado na correção.
Árvore de Troubleshooting: Configure certificates and Transport Layer Security (TLS) for an App Service
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Verificação ou validação intermediária |
Para usar esta árvore diante de um problema real, comece pelo nó raiz descrevendo o sintoma geral e siga as ramificações respondendo a cada pergunta com base no que você observa no ambiente. Perguntas fechadas como "o domínio do certificado bate com o binding?" ou "o cliente é um sistema legado?" eliminam hipóteses rapidamente. Quando você chegar a um nó vermelho, a causa está identificada. O nó verde imediatamente acessível a partir dele indica a ação correta. Nunca execute uma ação verde antes de confirmar que chegou ao nó vermelho correspondente pelo caminho correto.