Fundamentação Teórica: Configure Certificates and Transport Layer Security (TLS) for an App Service

1. Intuição Inicial

Imagine que você envia uma carta com informações bancárias pelo correio. Sem proteção, qualquer pessoa que intercepte a carta pode ler o conteúdo. Para proteger, você usa um envelope lacrado e codifica a mensagem. O destinatário tem a chave para decodificar.

Na web, o HTTPS com TLS funciona exatamente assim: toda comunicação entre o navegador do usuário e seu servidor é criptografada, impedindo que terceiros leiam ou modifiquem os dados em trânsito. O certificado TLS/SSL é como o "selo de autenticidade" que prova ao navegador que ele realmente está falando com o servidor legítimo, não com um impostor.

Para um App Service do Azure, configurar certificados e TLS significa garantir que sua aplicação seja acessada com segurança via HTTPS, que os usuários vejam o cadeado verde no navegador, e que ninguém possa interceptar dados sensíveis como senhas, dados de cartão ou informações pessoais.

2. Contexto

Onde certificados e TLS se encaixam na segurança do App Service

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Por que isso importa para o AZ-104

Configurar TLS e certificados é uma das tarefas mais comuns de um administrador Azure que gerencia App Services. Envolve decisões sobre qual tipo de certificado usar, como configurar custom domains com HTTPS, e como garantir que a versão de TLS seja adequada para compliance e segurança.

3. Construção dos Conceitos

3.1 O que é um certificado TLS/SSL

Um certificado TLS (anteriormente chamado SSL, mas o termo SSL é legado e tecnicamente obsoleto) tem três funções:

Identificação: prova que o servidor é quem diz ser (validado por uma CA)
Criptografia: habilita a negociação de chaves para criptografar a comunicação
Integridade: garante que os dados não foram modificados em trânsito

O certificado contém:

O domínio ao qual se aplica (Common Name / Subject Alternative Names)
O nome da entidade que possui o certificado
A autoridade certificadora (CA) que o emitiu
Data de validade
A chave pública (a chave privada fica no servidor, nunca é transmitida)

3.2 Tipos de certificado disponíveis no App Service

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

App Service Managed Certificate (gratuito):

Emitido pela DigiCert para o Azure
Válido por 180 dias, renovado automaticamente pelo Azure
Suporta apenas subdomínios (www.domain.com, api.domain.com)
Não suporta domínio raiz (domain.com) nem wildcard (*.domain.com)
Não pode ser exportado (não tem chave privada disponível)
Requer que o domínio já esteja mapeado para o App Service

Certificado Customizado (PFX/PEM):

Você adquire de qualquer CA (Let's Encrypt, DigiCert, Comodo, GlobalSign, etc.)
Suporta wildcard e EV (Extended Validation)
Suporta domínio raiz
Você é responsável pela renovação
Upload no formato PFX (Windows) ou PEM (Linux)

App Service Certificate:

Produto comprado diretamente no Azure
Armazenado automaticamente no Key Vault
Standard (domínio único) ou WildCard
Renovação pode ser configurada como automática
Integrado nativamente com App Service

Key Vault Certificate:

Certificado armazenado no Azure Key Vault
App Service acessa via Managed Identity
Centraliza gestão de certificados para múltiplos apps
Suporte a renovação automática via integração do Key Vault com CAs

3.3 Tipos de validação de certificado

Tipo	Validação	Uso típico	Tempo de emissão
DV (Domain Validation)	Apenas prova controle do domínio	Blogs, APIs, apps internos	Minutos
OV (Organization Validation)	Valida a organização também	E-commerce, portais corporativos	1-3 dias
EV (Extended Validation)	Validação extensiva da organização	Bancos, governos, alta credibilidade	1-2 semanas

3.4 Certificados Wildcard e SANs

Wildcard: um único certificado para *.domain.com cobre todos os subdomínios: www, api, admin, staging, etc. Mas não cobre o domínio raiz domain.com nem subdomínios aninhados (sub.api.domain.com).

SAN (Subject Alternative Names): um certificado que lista explicitamente múltiplos domínios. Por exemplo: www.empresa.com, api.empresa.com, empresa.com, empresa.com.br.

3.5 Configuração TLS

O App Service permite configurar:

Minimum TLS Version: a versão mais antiga de TLS que o servidor aceita.

Versão	Status	Recomendação
TLS 1.0	Obsoleto, vulnerabilidades conhecidas	Nunca use em produção
TLS 1.1	Obsoleto	Evite
TLS 1.2	Amplamente suportado, seguro	Mínimo recomendado atualmente
TLS 1.3	Mais seguro e mais rápido	Recomendado para novos sistemas

Cipher Suites: os algoritmos criptográficos que o servidor aceita para negociar a conexão TLS. O App Service usa a lista de cipher suites do Azure, que segue as melhores práticas de segurança. Para compliance específico (PCI-DSS, FIPS 140-2), pode ser necessário restringir.

3.6 Client Certificates (mTLS)

Por padrão, apenas o servidor precisa de certificado (one-way TLS). Mas em algumas aplicações de alta segurança, o cliente também precisa apresentar um certificado (mutual TLS ou mTLS).

O App Service suporta client certificate requirement onde cada requisição HTTP deve incluir um certificado do cliente. O App Service valida o certificado e o passa ao app via header X-ARR-ClientCert.

4. Visão Estrutural

Fluxo de configuração de HTTPS com custom domain

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

SNI SSL vs. IP-based SSL

SNI SSL (Server Name Indication):

Múltiplos certificados podem ser associados a um único endereço IP
Suportado por todos os navegadores modernos (>99.9% dos usuários)
Sem custo adicional no App Service
Recomendado para a esmagadora maioria dos casos

IP-based SSL:

Um endereço IP dedicado para o certificado
Compatibilidade com clientes muito antigos que não suportam SNI
Custo adicional no App Service (cobrado por binding de IP)
Raramente necessário hoje em dia

5. Funcionamento na Prática

Ciclo de vida de um certificado gerenciado

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Comportamentos não óbvios

O Managed Certificate não funciona para domínio raiz (naked domain). www.ecommerce.com.br é suportado pelo Managed Certificate. ecommerce.com.br (sem www) não é. Para o domínio raiz, você precisa de um certificado customizado ou App Service Certificate.

TLS Binding deve ser recriado se o certificado for renovado manualmente. Para certificados customizados (não gerenciados), quando você faz upload de um novo certificado (renovado), o binding antigo ainda aponta para o certificado anterior. Você precisa atualizar o binding para apontar para o novo thumbprint.

O App Service expõe o certificado ao app via header e variável de ambiente. Quando um certificado é adicionado ao App Service (mesmo que não usado para HTTPS mas para autenticação de cliente a um serviço externo), o Azure o disponibiliza ao app via variável de ambiente WEBSITE_LOAD_CERTIFICATES com o thumbprint, e o app pode acessá-lo via store de certificados do OS.

HTTPS Only redireciona mas não bloqueia. HTTPS Only envia um HTTP 301 redirect de HTTP para HTTPS. Isso significa que a primeira requisição HTTP ainda chega ao servidor antes do redirect. Para aplicações de altíssima segurança, implemente HSTS (HTTP Strict Transport Security) para que o navegador faça a requisição diretamente via HTTPS sem tentar HTTP primeiro.

Certificados para uso interno no app vs. para TLS do endpoint são conceitos diferentes. Um certificado pode ser adicionado ao App Service para dois propósitos: (1) para terminar TLS no endpoint do app (o que garante o HTTPS para os usuários), ou (2) para o app usar internamente ao se conectar a outros serviços que exigem autenticação por certificado. Ambos são gerenciados em Certificates no portal, mas têm funções diferentes.

6. Formas de Implementação

Portal do Azure

Quando usar: configuração inicial, gerenciamento visual de certificados e bindings

Para configurar HTTPS com Managed Certificate:

Portal > App Service > Custom domains > Adicionar domínio customizado
Verificar ownership do domínio (CNAME ou TXT)
Após adição do domínio: Portal > App Service > Certificates > Managed certificates
+ Add certificate > selecionar o domínio
Aguardar emissão (~alguns minutos)
Portal > App Service > Custom domains > ao lado do domínio, clicar no ícone de lock/binding
Selecionar o certificado recém-emitido
Add TLS/SSL Binding com tipo SNI SSL

Para fazer upload de certificado customizado (PFX):

Portal > App Service > Certificates > Bring your own certificates (.pfx)
+ Add certificate
Upload do arquivo .pfx + senha do certificado
Após upload, criar TLS binding associando o certificado ao domínio

Para configurar TLS mínimo:

Portal > App Service > TLS/SSL settings ou Configuration > General settings
Minimum Inbound TLS Version: selecionar 1.2

Azure CLI

# Criar custom domain (pré-requisito para qualquer certificado)
# (requer que o CNAME ou A record já esteja configurado no DNS)
az webapp config hostname add \
  --resource-group "rg-webapp" \
  --webapp-name "ecommerce-frontend" \
  --hostname "www.ecommerce.com.br"

# Listar custom domains
az webapp config hostname list \
  --resource-group "rg-webapp" \
  --webapp-name "ecommerce-frontend" \
  --output table

# Criar Managed Certificate (gratuito)
az webapp config ssl create \
  --resource-group "rg-webapp" \
  --name "ecommerce-frontend" \
  --hostname "www.ecommerce.com.br"

# Verificar estado do certificado gerenciado
az webapp config ssl list \
  --resource-group "rg-webapp" \
  --output table

# Criar TLS binding (SNI SSL) com certificado gerenciado
THUMBPRINT=$(az webapp config ssl list \
  --resource-group "rg-webapp" \
  --query "[?subjectName=='www.ecommerce.com.br'].thumbprint" \
  --output tsv)

az webapp config ssl bind \
  --resource-group "rg-webapp" \
  --name "ecommerce-frontend" \
  --certificate-thumbprint "$THUMBPRINT" \
  --ssl-type SNI

# Upload de certificado PFX customizado
az webapp config ssl upload \
  --resource-group "rg-webapp" \
  --webapp-name "ecommerce-frontend" \
  --certificate-file "./certificado-wildcard.pfx" \
  --certificate-password "<senha-do-pfx>"

# Listar certificados disponíveis (ver thumbprints)
az webapp config ssl list \
  --resource-group "rg-webapp" \
  --output table

# Criar TLS binding com certificado customizado (PFX)
az webapp config ssl bind \
  --resource-group "rg-webapp" \
  --name "ecommerce-frontend" \
  --certificate-thumbprint "<THUMBPRINT_DO_CERTIFICADO>" \
  --ssl-type SNI

# Habilitar HTTPS Only
az webapp update \
  --resource-group "rg-webapp" \
  --name "ecommerce-frontend" \
  --https-only true

# Configurar versão mínima de TLS
az webapp config set \
  --resource-group "rg-webapp" \
  --name "ecommerce-frontend" \
  --min-tls-version 1.2

# Configurar client certificates (mTLS)
az webapp update \
  --resource-group "rg-webapp" \
  --name "ecommerce-frontend" \
  --set clientCertEnabled=true \
  --set clientCertMode=Required

# Importar certificado do Azure Key Vault
az webapp config ssl import \
  --resource-group "rg-webapp" \
  --name "ecommerce-frontend" \
  --key-vault "kv-ecommerce-prod" \
  --key-vault-certificate-name "wildcard-ecommerce"

# Remover TLS binding
az webapp config ssl unbind \
  --resource-group "rg-webapp" \
  --name "ecommerce-frontend" \
  --certificate-thumbprint "<THUMBPRINT>" \
  --ssl-type SNI

# Deletar certificado
az webapp config ssl delete \
  --resource-group "rg-webapp" \
  --certificate-thumbprint "<THUMBPRINT>"

# Ver configuração TLS atual
az webapp config show \
  --resource-group "rg-webapp" \
  --name "ecommerce-frontend" \
  --query "{HTTPS_Only: httpsOnly, Min_TLS: minTlsVersion, ClientCert: clientCertEnabled}" \
  --output json

Azure PowerShell

# Upload de certificado PFX
$pfxPassword = ConvertTo-SecureString "<senha>" -AsPlainText -Force
New-AzWebAppSSLBinding `
  -ResourceGroupName "rg-webapp" `
  -WebAppName "ecommerce-frontend" `
  -Name "www.ecommerce.com.br" `
  -CertificateFilePath "./certificado.pfx" `
  -CertificatePassword $pfxPassword `
  -SslState SniEnabled

# Criar binding com certificado existente
New-AzWebAppSSLBinding `
  -ResourceGroupName "rg-webapp" `
  -WebAppName "ecommerce-frontend" `
  -Name "www.ecommerce.com.br" `
  -Thumbprint "<THUMBPRINT>" `
  -SslState SniEnabled

# Listar bindings SSL
Get-AzWebAppSSLBinding `
  -ResourceGroupName "rg-webapp" `
  -WebAppName "ecommerce-frontend"

# Configurar HTTPS Only
Set-AzWebApp `
  -ResourceGroupName "rg-webapp" `
  -Name "ecommerce-frontend" `
  -HttpsOnly $true

# Remover binding
Remove-AzWebAppSSLBinding `
  -ResourceGroupName "rg-webapp" `
  -WebAppName "ecommerce-frontend" `
  -Name "www.ecommerce.com.br" `
  -Force

Bicep

// Certificado customizado via PFX (base64 encoded)
resource certificate 'Microsoft.Web/certificates@2022-09-01' = {
  name: 'cert-ecommerce-wildcard'
  location: 'brazilsouth'
  properties: {
    pfxBlob: pfxBase64String  // PFX em base64
    password: pfxPassword
    serverFarmId: appServicePlan.id
  }
}

// Certificado do Key Vault
resource certFromKeyVault 'Microsoft.Web/certificates@2022-09-01' = {
  name: 'cert-from-kv'
  location: 'brazilsouth'
  properties: {
    keyVaultId: keyVault.id
    keyVaultSecretName: 'wildcard-cert'
    serverFarmId: appServicePlan.id
  }
}

// App Service com TLS configurado
resource webApp 'Microsoft.Web/sites@2022-09-01' = {
  name: 'ecommerce-frontend'
  location: 'brazilsouth'
  properties: {
    serverFarmId: appServicePlan.id
    httpsOnly: true  // HTTPS Only
    siteConfig: {
      minTlsVersion: '1.2'      // TLS 1.2 mínimo
      ftpsState: 'Disabled'     // Desabilitar FTP inseguro
      http20Enabled: true       // Habilitar HTTP/2
      clientCertEnabled: false  // mTLS desabilitado por padrão
    }
    // Hostname binding com SNI SSL
    hostNameSslStates: [
      {
        name: 'www.ecommerce.com.br'
        sslState: 'SniEnabled'
        thumbprint: certificate.properties.thumbprint
      }
    ]
  }
}

7. Controle e Segurança

HSTS (HTTP Strict Transport Security)

HTTPS Only do App Service redireciona HTTP para HTTPS, mas o primeiro pedido ainda vai via HTTP antes do redirect. O HSTS instrui o navegador a nunca mais tentar HTTP para aquele domínio após a primeira visita HTTPS.

HSTS é configurado como um header HTTP de resposta. No App Service, você pode configurar via:

No código da aplicação (recomendado para controle total):

// .NET 8 - Program.cs
app.UseHsts();

Via web.config (Windows):

<configuration>
  <system.webServer>
    <httpProtocol>
      <customHeaders>
        <add name="Strict-Transport-Security" 
             value="max-age=31536000; includeSubDomains; preload" />
      </customHeaders>
    </httpProtocol>
  </system.webServer>
</configuration>

Via Application Gateway ou Front Door: para apps por trás de um gateway, configure o header HSTS no gateway.

Renovação de certificados e alertas

Para certificados customizados (não gerenciados), configure alertas antes da expiração:

# Verificar data de expiração de todos os certificados
az webapp config ssl list \
  --query "[].{Nome: name, Dominio: subjectName, Expira: expirationDate, Thumbprint: thumbprint}" \
  --output table

# Via Resource Graph: certificados expirando em 30 dias
az graph query -q "
Resources
| where type == 'microsoft.web/certificates'
| extend expiryDate = todatetime(properties.expirationDate)
| where expiryDate < ago(-30d) and expiryDate > now()
| project name, resourceGroup, expiryDate, thumbprint=properties.thumbprint"

Armazenar certificados no Key Vault

A prática mais segura é nunca ter os arquivos PFX localmente nos pipelines de CI/CD. Use o Key Vault como fonte de verdade:

# Importar PFX para Key Vault
az keyvault certificate import \
  --vault-name "kv-ecommerce-prod" \
  --name "wildcard-ecommerce-cert" \
  --file "./wildcard.pfx" \
  --password "<senha-pfx>"

# Configurar renovação automática no Key Vault (para CAs suportadas como DigiCert)
az keyvault certificate create \
  --vault-name "kv-ecommerce-prod" \
  --name "api-cert" \
  --policy "$(az keyvault certificate get-default-policy)"

# App Service importar do Key Vault
az webapp config ssl import \
  --resource-group "rg-webapp" \
  --name "ecommerce-frontend" \
  --key-vault "kv-ecommerce-prod" \
  --key-vault-certificate-name "wildcard-ecommerce-cert"

8. Tomada de Decisão

Tipo de certificado a usar

Situação	Tipo de certificado	Motivo
Subdomain simples, custo zero	App Service Managed (gratuito)	Renovação automática, zero custo, zero configuração
Múltiplos subdomínios	Wildcard customizado ou App Service Certificate Wildcard	Um certificado cobre todos
Domínio raiz (naked domain)	Certificado customizado ou App Service Certificate	Managed não suporta root domain
Validação organizacional (OV/EV)	Certificado de CA paga	Managed só emite DV
Múltiplos apps com o mesmo domínio	Key Vault Certificate	Certificado centralizado, um local para renovar
API interna corporativa	Let's Encrypt via custom cert	DV gratuito, renovável via automação

SNI SSL vs. IP-based SSL

Situação	Escolha	Motivo
99% dos casos modernos	SNI SSL	Sem custo adicional, suporte universal
App com clientes muito legados (IE6, alguns IoT)	IP-based SSL	SNI não suportado nesses clientes
Requer IP fixo para o app (ex: para whitelist)	IP-based SSL	IP estático associado ao certificado

9. Boas Práticas

Use App Service Managed Certificate sempre que possível para subdomínios simples. É gratuito, renova automaticamente e não requer nenhuma gestão. Para a maioria dos subdomínios de APIs e apps internos, não há razão para usar certificado pago.

Armazene certificados customizados no Key Vault, não em repositórios ou pipelines. Um certificado PFX com sua chave privada é uma credencial sensível. Armazená-lo no Key Vault centraliza a gestão, permite acesso via Managed Identity sem senhas, e facilita auditoria de quem acessou o certificado.

Configure alerta de expiração para certificados customizados. Azure Monitor pode alertar quando um certificado está próximo da expiração. Configure alertas em 60 dias e 30 dias para ter tempo hábil de renovar.

Habilite HTTPS Only em todo app de produção. É uma configuração de um clique que garante que usuários nunca usem HTTP acidentalmente. Não há razão para não habilitar em produção.

Configure TLS 1.2 como mínimo; considere 1.3 para sistemas novos. TLS 1.0 e 1.1 têm vulnerabilidades conhecidas. Todo app de produção deve exigir mínimo TLS 1.2. Para compliance PCI-DSS 4.0, TLS 1.2 é o mínimo obrigatório.

Para wildcard, considere App Service Certificate em vez de Let's Encrypt. Let's Encrypt não emite wildcards via HTTP-01 challenge (que o App Service suporta nativamente). O proceso manual de wildcard com Let's Encrypt é complexo. App Service Certificate emite wildcard diretamente integrado.

10. Erros Comuns

Erro	Por que acontece	Como evitar
Managed Certificate não emitido	Verificação de domínio falhou (CNAME não configurado corretamente)	Verificar CNAME no DNS antes de solicitar; aguardar propagação
Certificado adicionado mas HTTPS não funciona	TLS binding não criado após upload do cert	Após upload, criar o binding associando cert ao custom domain
Certificado expirou em produção	Renovação manual esquecida	Configurar alerta 60 dias antes; usar Managed ou Key Vault com renovação auto
SNI SSL mas clientes reportam erro de cert	Clientes legados não suportam SNI	Usar IP-based SSL se clientes legados são requisito
Managed Certificate não funciona para apex domain	Limitação técnica da feature	Usar App Service Certificate ou cert customizado para root domain
TLS binding aponta para cert antigo após renovação	Thumbprint mudou, binding não atualizado	Atualizar binding após upload de certificado renovado
PFX com senha errada no upload	Senha incorreta ou formato do arquivo errado	Verificar senha e garantir formato PFX correto antes do upload

O erro mais crítico

Não configurar alertas de expiração para certificados customizados. Um certificado expirado em produção significa que todos os usuários veem um erro de segurança no navegador e a maioria abandona o site. O impacto de um certificado expirado por algumas horas em um e-commerce pode ser dezenas de milhares de reais em vendas perdidas. Alertas em 60 e 30 dias, combinados com processos de renovação documentados, são essenciais.

11. Operação e Manutenção

Verificar estado de todos os certificados

# Listar certificados com data de expiração
az webapp config ssl list \
  --query "[].{
    App: subject,
    Dominio: subjectName,
    Expira: expirationDate,
    Thumbprint: thumbprint,
    Tipo: issuer
  }" \
  --output table

# Verificar se HTTPS Only está habilitado em todos os apps de produção
az graph query -q "
Resources
| where type == 'microsoft.web/sites'
| where tags.Environment == 'Production'
| where properties.httpsOnly == false
| project name, resourceGroup, subscriptionId"

# Verificar versão TLS mínima
az graph query -q "
Resources
| where type == 'microsoft.web/sites'
| extend minTls = tostring(properties.siteConfig.minTlsVersion)
| where minTls != '1.2' and minTls != '1.3'
| project name, resourceGroup, minTls"

Configurar Azure Monitor Alert para certificados expirando

# Alerta quando certificado expira em menos de 30 dias
az monitor alert create \
  --name "cert-expirando-30dias" \
  --resource-group "rg-monitoramento" \
  --condition "count 'Microsoft.Web/certificates' where 'expirationDate' < '30d'" \
  --action-group "ag-alertas-criticos"

12. Integração e Automação

Renovação automática de certificado Let's Encrypt via Logic App ou Automation

Para organizações que preferem Let's Encrypt (gratuito) mas precisam de automação de renovação:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Pipeline de deploy com certificado do Key Vault

# GitHub Actions: deploy com certificado gerenciado via Key Vault
steps:
  - name: Login Azure
    uses: azure/login@v2

  - name: Importar certificado do Key Vault para App Service
    uses: azure/CLI@v2
    with:
      inlineScript: |
        # Importar cert do KV para o app (renova o binding automaticamente)
        az webapp config ssl import \
          --resource-group ${{ vars.RESOURCE_GROUP }} \
          --name ${{ vars.APP_NAME }} \
          --key-vault ${{ vars.KEY_VAULT_NAME }} \
          --key-vault-certificate-name ${{ vars.CERT_NAME }}

        # Atualizar o binding com o novo thumbprint
        THUMBPRINT=$(az keyvault certificate show \
          --vault-name ${{ vars.KEY_VAULT_NAME }} \
          --name ${{ vars.CERT_NAME }} \
          --query "x509ThumbprintHex" -o tsv)

        az webapp config ssl bind \
          --resource-group ${{ vars.RESOURCE_GROUP }} \
          --name ${{ vars.APP_NAME }} \
          --certificate-thumbprint $THUMBPRINT \
          --ssl-type SNI

13. Resumo Final

Pontos essenciais:

App Service Managed Certificate é gratuito, renova automaticamente, mas suporta apenas subdomínios (não apex/root domain, não wildcard)
TLS binding é o que associa um certificado a um custom domain no App Service; sem o binding, o certificado existe mas não é usado para HTTPS
SNI SSL permite múltiplos certificados no mesmo IP; IP-based SSL usa um IP dedicado por certificado (raramente necessário)
HTTPS Only redireciona HTTP para HTTPS via 301; deve ser habilitado em todo app de produção
TLS 1.2 é o mínimo recomendado; TLS 1.0 e 1.1 devem ser desabilitados
Certificados customizados devem ser armazenados no Key Vault para gestão centralizada e segura

Diferenças críticas:

Managed Certificate vs. Custom Certificate: Managed é gratuito e automático mas limitado; Custom permite wildcard, EV, root domain, mas requer gestão manual de renovação
DV vs. OV vs. EV: diferem no nível de validação da CA; DV é apenas controle de domínio, OV valida a organização, EV faz validação extensiva
TLS binding vs. Custom Domain: o custom domain mapeia o nome DNS ao app; o TLS binding associa um certificado ao nome DNS para habilitar HTTPS
SNI SSL vs. IP-based SSL: SNI é recomendado para todos os casos modernos; IP-based é necessário apenas para clientes muito legados

O que precisa ser lembrado para o AZ-104:

Managed Certificate requer tier Basic ou superior (não funciona em Free)
O Managed Certificate não suporta domínio raiz (apex) nem wildcards
Certificado uploadado como PFX precisa ter a senha fornecida durante o upload
Após upload ou renovação de certificado customizado, o TLS binding deve ser atualizado com o novo thumbprint
az webapp config ssl create para Managed Certificate, az webapp config ssl upload para PFX customizado, az webapp config ssl import para Key Vault
az webapp config ssl bind para criar o TLS binding associando cert ao domínio
mTLS (client certificates) é habilitado via clientCertEnabled: true e o certificado do cliente é passado ao app via header X-ARR-ClientCert

1. Intuição Inicial​

2. Contexto​

Onde certificados e TLS se encaixam na segurança do App Service​

Por que isso importa para o AZ-104​

3. Construção dos Conceitos​

3.1 O que é um certificado TLS/SSL​

3.2 Tipos de certificado disponíveis no App Service​

3.3 Tipos de validação de certificado​

3.4 Certificados Wildcard e SANs​

3.5 Configuração TLS​

3.6 Client Certificates (mTLS)​

4. Visão Estrutural​

Fluxo de configuração de HTTPS com custom domain​

SNI SSL vs. IP-based SSL​

5. Funcionamento na Prática​

Ciclo de vida de um certificado gerenciado​

Comportamentos não óbvios​

6. Formas de Implementação​

Portal do Azure​

Azure CLI​

Azure PowerShell​

Bicep​

7. Controle e Segurança​

HSTS (HTTP Strict Transport Security)​

Renovação de certificados e alertas​

Armazenar certificados no Key Vault​

8. Tomada de Decisão​

Tipo de certificado a usar​

SNI SSL vs. IP-based SSL​

9. Boas Práticas​

10. Erros Comuns​

O erro mais crítico​

11. Operação e Manutenção​

Verificar estado de todos os certificados​

Configurar Azure Monitor Alert para certificados expirando​

12. Integração e Automação​

Renovação automática de certificado Let's Encrypt via Logic App ou Automation​

Pipeline de deploy com certificado do Key Vault​

13. Resumo Final​

1. Intuição Inicial

2. Contexto

Onde certificados e TLS se encaixam na segurança do App Service

Por que isso importa para o AZ-104

3. Construção dos Conceitos

3.1 O que é um certificado TLS/SSL

3.2 Tipos de certificado disponíveis no App Service

3.3 Tipos de validação de certificado

3.4 Certificados Wildcard e SANs

3.5 Configuração TLS

3.6 Client Certificates (mTLS)

4. Visão Estrutural

Fluxo de configuração de HTTPS com custom domain

SNI SSL vs. IP-based SSL

5. Funcionamento na Prática

Ciclo de vida de um certificado gerenciado

Comportamentos não óbvios

6. Formas de Implementação

Portal do Azure

Azure CLI

Azure PowerShell

Bicep

7. Controle e Segurança

HSTS (HTTP Strict Transport Security)

Renovação de certificados e alertas

Armazenar certificados no Key Vault

8. Tomada de Decisão

Tipo de certificado a usar

SNI SSL vs. IP-based SSL

9. Boas Práticas

10. Erros Comuns

O erro mais crítico

11. Operação e Manutenção

Verificar estado de todos os certificados

Configurar Azure Monitor Alert para certificados expirando

12. Integração e Automação

Renovação automática de certificado Let's Encrypt via Logic App ou Automation

Pipeline de deploy com certificado do Key Vault

13. Resumo Final