Partilhar via

Certificados e o Ambiente do Serviço de Aplicativo v2

  • Artigo

Importante

Este artigo é sobre o Ambiente do Serviço de Aplicativo v2, que é usado com os planos do Serviço de Aplicativo Isolado. O Ambiente do Serviço de Aplicativo v1 e v2 foi desativado a partir de 31 de agosto de 2024. Há uma nova versão do Ambiente do Serviço de Aplicativo que é mais fácil de usar e é executada em uma infraestrutura mais poderosa. Para saber mais sobre a nova versão, comece com a 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.

A partir de 31 de agosto de 2024, o Contrato de Nível de Serviço (SLA) e os Créditos de Serviço não se aplicam mais às cargas de trabalho do Ambiente do Serviço de Aplicativo v1 e v2 que continuam em produção, pois são produtos desativados. A desativação do hardware do Ambiente do Serviço de Aplicativo v1 e v2 começou, e isso pode afetar a disponibilidade e o desempenho de seus aplicativos e dados.

Você deve concluir a migração para o Ambiente do Serviço de Aplicativo v3 imediatamente ou seus aplicativos e recursos podem ser excluídos. Tentaremos migrar automaticamente qualquer Ambiente do Serviço de Aplicativo restante v1 e v2 com base no melhor esforço usando o recurso de migração in-loco, mas a Microsoft não faz nenhuma reivindicação ou garantia sobre a disponibilidade do aplicativo após a migração automática. Talvez seja necessário executar 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, seus recursos e dados de aplicativos associados serão excluídos. Exortamo-lo vivamente a agir agora para evitar qualquer um destes cenários extremos.

Se você precisar de tempo adicional, podemos oferecer um período de carência único de 30 dias para que você conclua sua migração. Para obter mais informações e solicitar esse período de carência, revise a visão geral do período de carência e vá para o portal do Azure e visite a folha Migração para cada um dos seus 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 Ambiente do Serviço de Aplicativo (ASE) é uma implantação do Serviço de Aplicativo do Azure que é executado em sua Rede Virtual do Azure (VNet). Ele pode ser implantado com um ponto de extremidade de aplicativo acessível pela Internet ou um ponto de extremidade de aplicativo que está em sua rede virtual. Se você implantar o ASE com um ponto de extremidade acessível pela Internet, essa implantação será chamada de ASE externo. Se você implantar o ASE com um ponto de extremidade em sua rede virtual, essa implantação será chamada de ILB ASE. Você pode saber mais sobre o ILB ASE em Criar e usar um documento ILB ASE .

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

Certificados ILB ASE

Se você estiver usando um ASE externo, seus aplicativos serão acessados em <appname>.<asename.p.azurewebsites.net>. Por padrão, todos os ASEs, mesmo os ILB ASEs, são criados com certificados que seguem esse formato. Quando você tem um ILB ASE, os aplicativos são alcançados com base no nome de domínio especificado ao criar o ILB ASE. Para que os aplicativos suportem TLS, você precisa carregar certificados. Obtenha um certificado TLS/SSL válido usando autoridades de certificação internas, comprando um certificado de um emissor externo ou usando um certificado autoassinado.

Há duas opções para configurar certificados com seu 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 escolha feita, os seguintes atributos de certificado devem ser configurados corretamente:

  • Assunto: Este atributo deve ser definido como *.[ your-root-domain-here] para um certificado ILB ASE curinga. Se estiver criando o certificado para seu aplicativo, ele deve ser [appname]. [seu-domínio-raiz-aqui]
  • Nome Alternativo do Assunto: Este atributo deve incluir ambos .[ seu-domínio-raiz-aqui] e.scm.[ your-root-domain-here] para o certificado ILB ASE curinga. Se estiver criando o certificado para seu aplicativo, ele deve ser [appname]. [seu-domínio-raiz-aqui] e [appname].scm. [seu-domínio-raiz-aqui].

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

Carregar certificado para 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á um banner informando que o certificado não foi definido.

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

Não é possível criar o ASE e carregar o certificado como uma ação no portal ou mesmo em um modelo. Como uma ação separada, você pode carregar o certificado usando um modelo, conforme descrito em Criar um ASE a partir de um documento de modelo .

Se quiser criar um certificado autoassinado rapidamente para teste, você pode usar a seguinte parte do 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, você precisará garantir que o nome da entidade tenha o formato CN={ASE_NAME_HERE}_InternalLoadBalancingASE.

Certificados de candidatura

Os aplicativos hospedados em um ASE podem usar os recursos de certificado centrados no aplicativo disponíveis no Serviço de Aplicativo multilocatário. Esses recursos incluem:

  • Certificados SNI
  • SSL baseado em IP, que só é suportado com um ASE externo. Um ILB ASE não suporta SSL baseado em IP.
  • Certificados hospedados pelo KeyVault

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 para corresponder a 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 ILB ASE com o nome de domínio padrão, especifique o site scm na SAN do certificado, conforme observado anteriormente.

Definições do TLS

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

Certificado de cliente privado

Um caso de uso comum é configurar seu aplicativo como um cliente em um modelo cliente-servidor. Se você proteger seu servidor com um certificado de autoridade de certificação privada, precisará carregar o certificado do cliente para seu aplicativo. As instruções a seguir carregarão certificados no armazenamento confiável dos trabalhadores 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 carregar o certificado novamente.

Para carregar o certificado para a sua aplicação no ASE:

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

84EC242A4EC7957817B8E48913E50953552DAFA6,6A5C65DC9247F762FE17BF8D4906E04FE6B31819

O certificado estará disponível por todos os aplicativos no mesmo plano de serviço de aplicativo que o aplicativo, que definiu essa configuração. Se você precisar que ele esteja disponível para aplicativos em um plano diferente do Serviço de Aplicativo, precisará repetir a operação Configuração do Aplicativo em um aplicativo desse plano do Serviço de Aplicativo. Para verificar se o certificado está definido, vá para o console do Kudu e emita o seguinte 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 seguinte 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.cer"
export-certificate -Cert $certThumbprint -FilePath $fileName -Type CERT