Compartilhar via

Certificados e o Ambiente do Serviço de Aplicativo v2

  • Artigo

Importante

Este artigo aborda o Ambiente do Serviço de Aplicativo v2, que é usado com planos do Serviço de Aplicativo Isolado. As versões v1 e v2 do Ambiente do Serviço de Aplicativo foram desativadas em 31 de agosto de 2024. Há uma nova versão do Ambiente de Serviço de Aplicativo que é mais fácil de usar e é executado na infraestrutura mais avançada. Para saber mais sobre a nova versão, comece com Introdução ao Ambiente do Serviço de Aplicativo. Se você estiver usando o Ambiente do Serviço de Aplicativo v1, siga as etapas neste artigo para migrar para a nova versão.

Desde 31 de agosto de 2024, o SLA (Contrato de Nível de Serviço) e os Créditos de Serviço deixaram de se aplicar às cargas de trabalho do Ambiente do Serviço de Aplicativo v1 e v2 que continuam em produção, já que são produtos desativados. A desativação do hardware do Ambiente do Serviço de Aplicativo v1 e v2 foi iniciada, o que poderá afetar a disponibilidade e o desempenho de aplicativos e dados.

Você precisa executar a migração para o Ambiente do Serviço de Aplicativo v3 imediatamente. Caso contrário, aplicativos e recursos poderão ser excluídos. Tentaremos migrar automaticamente qualquer Ambiente do Serviço de Aplicativo v1 e v2 restantes com base no melhor esforço usando o recurso de migração in-loco. No enanto, a Microsoft não afirma ou garante a disponibilidade do aplicativo após a migração automática. Talvez seja necessário realizar a configuração manual para concluir a migração e otimizar a escolha de SKU do Plano do Serviço de Aplicativo para atender às suas necessidades. Se a migração automática não for viável, os recursos e dados de aplicativos associados serão excluídos. Recomendamos fortemente que você tome uma atitude agora para evitar esses cenários extremos.

Se você precisar de mais tempo, podemos oferecer um período de carência único de 30 dias para a realização da migração. Para saber mais e solicitar o período de carência, confira a visão geral do período de carência, acesse o portal do Azure e visite a lâmina Migração para cada um dos Ambientes do Serviço de Aplicativo.

Para obter as informações mais atualizadas sobre a desativação do Ambiente do Serviço de Aplicativo v1/v2, consulte a Atualização de desativação do Ambiente do Serviço de Aplicativo v1 e v2.

O ASE (Ambiente do Serviço de Aplicativo) é uma implantação do Serviço de Aplicativo do Azure que é executada na sua VNet (Rede Virtual) do Azure. Ele pode ser implantado com um ponto de extremidade do aplicativo acessível pela internet ou um ponto de extremidade do aplicativo que esteja em sua rede virtual. Se você implantar o ASE com um ponto de extremidade acessível pela Internet, a implantação será chamada de ASE externo. Se você implantar o ASE com um ponto de extremidade em sua rede virtual, a implantação será chamada de ILB ASE. Você pode aprender mais sobre o ILB ASE no documento Criar e usar um ILB ASE.

O ASE é um sistema de locatário único. Como ele é de locatário único, há alguns recursos disponíveis apenas para ASE que não esteja disponível no Serviço de Aplicativo multilocatário.

Certificados de ILB ASE

Se você estiver usando um ASE Externo, seus aplicativos serão acessados em <nomedoapp>.<nomedoase>.p.azurewebsites.net. Por padrão, todos os ASEs, até mesmo os ASEs ILB, são criados com certificados que seguem esse formato. Quando você tem um ILB ASE, os aplicativos são acessados com base no nome de domínio que você especifica ao criar o ILB ASE. Para que os aplicativos sejam compatíveis com SSL, você precisa carregar certificados. Obtenha um certificado TLS/SSL válido, usando autoridades de certificação internas, adquirindo um certificado de um emissor externo ou usando um certificado autoassinado.

Há duas opções para configurar certificados com o ILB ASE. Você pode definir um certificado padrão curinga para o ILB ASE ou definir certificados nos aplicativos Web individuais no ASE. Independentemente da sua escolha, os seguintes atributos de certificado devem ser configurados corretamente:

  • Entidade: esse atributo deve ser definido como *.[seu-domínio-raiz-aqui] para um certificado de ILB ASE curinga. Se estiver criando o certificado para seu aplicativo, então ele deverá ser [appname].[seu-domínio-raiz-aqui]
  • Nome Alternativo da Entidade: esse atributo deve incluir .[seu-domínio-raiz-aqui] e .scm.[seu-domínio-raiz-aqui] para o certificado de ILB ASE curinga. Se estiver criando o certificado para seu aplicativo, então ele deverá ser [appname].[seu-domínio-raiz-aqui] e [appname].scm.[seu-domínio-raiz-aqui].

Como uma terceira variante, você pode criar um certificado de ILB ASE que inclua todos os nomes de aplicativo individuais na SAN do certificado em vez de usar uma referência de curinga. O problema com esse método é que você precisará saber com antecedência os nomes dos aplicativos que estiver colocando no ASE ou precisará ficar atualizando o certificado ILB ASE.

Carregar certificado ao ILB ASE

Depois que um ILB ASE é criado no portal, o certificado deve ser definido para o ILB ASE. Até que o certificado seja definido, o ASE mostrará uma faixa indicando que o certificado não foi definido.

O certificado a ser carregado deverá ser um arquivo .pfx. Depois que o certificado é carregado, há um atraso de tempo de aproximadamente 20 minutos antes que o certificado seja usado.

Você não pode criar o ASE e carregar o certificado em uma única ação no portal ou mesmo em um único modelo. Como uma ação separada, você pode carregar o certificado usando um modelo, conforme descrito no documento Criar um ASE usando um modelo.

Se desejar criar um certificado autoassinado rapidamente para testar, você poderá usar o seguinte trecho de PowerShell:

$certificate = New-SelfSignedCertificate -certstorelocation cert:\localmachine\my -dnsname "*.internal.contoso.com","*.scm.internal.contoso.com"

$certThumbprint = "cert:\localMachine\my\" + $certificate.Thumbprint
$password = ConvertTo-SecureString -String "CHANGETHISPASSWORD" -Force -AsPlainText

$fileName = "exportedcert.pfx"
Export-PfxCertificate -cert $certThumbprint -FilePath $fileName -Password $password

Ao criar um certificado autoassinado, verifique se o nome da entidade tem o formato CN = {NOME_DO_ASE_AQUI} _InternalLoadBalancingASE.

Certificados de aplicativo

Aplicativos que são hospedados em um ASE podem usar os recursos de certificado centrado em aplicativos que estão disponíveis no Serviço de Aplicativo multilocatário. Esses recursos incluem:

  • Certificados SNI
  • SSL com base em IP, que só é compatível com um ASE externo. Um ILB ASE não é compatível com SSL com base em IP.
  • Certificados hospedados no Key Vault

As instruções para carregar e gerenciar esses certificados estão disponíveis em Adicionar um certificado TLS/SSL no Serviço de Aplicativo do Azure. Se você estiver simplesmente configurando certificados de acordo com um nome de domínio personalizado que você atribuiu ao seu aplicativo Web, essas instruções serão suficientes. Se você estiver carregando o certificado para um aplicativo Web de ILB ASE com o nome de domínio padrão, especifique o site SCM na SAN do certificado, conforme observado anteriormente.

Configurações de protocolo TLS

Você pode definir a configuração de TLS em um nível de aplicativo.

Certificado de cliente privado

Um caso de uso comum é configurar o aplicativo como um cliente em um modelo cliente-servidor. Se você proteger seu servidor com um Certificado de Autoridade de Certificação privado, será necessário carregar o certificado de cliente em seu aplicativo. As instruções a seguir carregarão certificados no repositório confiável das funções de trabalho em que seu aplicativo está sendo executado. Se você carregar o certificado em um aplicativo, poderá usá-lo com seus outros aplicativos no mesmo Plano do Serviço de Aplicativo sem ter que carregar o certificado novamente.

Para carregar o certificado em seu aplicativo no ASE:

  1. Gere um arquivo .cer para seu certificado.
  2. Acesse o aplicativo que precisa do certificado no portal do Azure
  3. Acesse as configurações de SSL no aplicativo. Clique em Carregar Certificado. Selecione Público. Selecione Computador Local. Forneça um nome. Procure e selecione seu arquivo .cer. Selecionar carregar.
  4. Copie a impressão digital.
  5. Acesse Configurações do Aplicativo. Crie uma Configuração de Aplicativo WEBSITE_LOAD_ROOT_CERTIFICATES com a impressão digital como o valor. Se você tiver vários certificados, poderá colocá-los na mesma configuração separada por vírgulas e sem nenhum espaço em branco, como

84EC242A4EC7957817B8E48913E50953552DAFA6,6A5C65DC9247F762FE17BF8D4906E04FE6B31819

O certificado ficará disponível para todos os aplicativos no mesmo Plano do Serviço de Aplicativo que definiu essa configuração. Se você precisar que ele fique disponível para aplicativos de outro Plano do Serviço de Aplicativo, será necessário repetir a operação de Configuração de Aplicativo em um aplicativo desse plano do Serviço de Aplicativo. Para verificar se o certificado está configurado, acesse o console do Kudu e emita o comando no console de depuração do PowerShell:

dir cert:\localmachine\root

Para executar testes, você pode criar um certificado autoassinado e gerar um arquivo .cer com o PowerShell a seguir:

$certificate = New-SelfSignedCertificate -certstorelocation cert:\localmachine\my -dnsname "*.internal.contoso.com","*.scm.internal.contoso.com"

$certThumbprint = "cert:\localMachine\my\" + $certificate.Thumbprint
$password = ConvertTo-SecureString -String "CHANGETHISPASSWORD" -Force -AsPlainText

$fileName = "exportedcert.cer"
export-certificate -Cert $certThumbprint -FilePath $fileName -Type CERT