Gerar um certificado autoassinado do Gateway de Aplicativo do Azure com uma CA raiz personalizada

O Application Gateway v2 SKU introduz o uso de certificados raiz confiáveis para permitir conexões TLS com os servidores back-end. Esta funcionalidade elimina o uso de certificados de autenticação (certificados Leaf individuais) que eram exigidos no SKU v1. O certificado raiz é um certificado raiz no formato X.509(.CER) codificado em Base-64 do servidor de certificados backend. Ele identifica a autoridade de certificação (CA) raiz que emitiu o certificado do servidor e o certificado do servidor é usado para a comunicação TLS/SSL.

O Application Gateway confia no certificado do seu site por padrão se uma Autoridade de Certificação conhecida (por exemplo, GoDaddy ou DigiCert) o assinar. Nesse caso, não é necessário carregar explicitamente o certificado root. Para mais informações, consulte Resumo da terminação de TLS e TLS de ponta a ponta com Application Gateway. No entanto, se você tiver um ambiente de desenvolvimento/teste e não quiser comprar um certificado assinado pela autoridade de certificação verificada, poderá criar sua própria autoridade de certificação raiz personalizada e um certificado folha assinado por essa autoridade de certificação raiz.

Use as seguintes opções para gerar o seu certificado privado para ligações TLS de backend.

1. Usa a ferramenta de gerador de certificados privados. Ao usar o nome de domínio (Nome Comum) que fornece, esta ferramenta executa os mesmos passos documentados neste artigo para gerar certificados Root e Server. Com os arquivos de certificado gerados, você pode carregar imediatamente o certificado raiz (. CER) para a Configuração de back-end do seu gateway e a cadeia de certificados correspondente (. PFX) para o servidor back-end. A senha para o arquivo PFX também é fornecida no arquivo ZIP baixado.

2. Use comandos OpenSSL para personalizar e gerar certificados de acordo com suas necessidades. Continue a seguir as instruções deste artigo se quiser fazer este processo inteiramente sozinho.

Neste artigo, você aprenderá a:

• Crie sua própria Autoridade de Certificação personalizada
• Criar um certificado autoassinado assinado pela sua autoridade de certificação personalizada
• Carregue um certificado raiz autoassinado em um Application Gateway para autenticar o servidor back-end

Prerequisites

• OpenSSL num computador com Windows ou Linux

  Embora possam existir outras ferramentas para gestão de certificados, este tutorial utiliza OpenSSL. Você pode encontrar OpenSSL empacotado com muitas distribuições Linux, como o Ubuntu.

• Um servidor web

  Por exemplo, Apache, IIS ou NGINX para testar os certificados.

• Uma SKU do Application Gateway v2

  Se você não tiver um gateway de aplicativo existente, consulte Guia de início rápido: tráfego da Web direto com o Gateway de Aplicativo do Azure - portal do Azure.

Criar um certificado de autoridade de certificação raiz

Crie o seu certificado de CA raiz usando OpenSSL.

Criar a chave raiz

1. Inicie sessão no seu computador onde o OpenSSL está instalado e execute o seguinte comando. Este comando cria a chave privada raiz. A chave não está encriptada nem protegida por palavra-passe, por isso guarda o ficheiro contoso.key de forma segura.

   openssl ecparam -out contoso.key -name prime256v1 -genkey
   

Crie um certificado raiz e assine por si próprio

1. Use o comando a seguir para gerar a solicitação de assinatura de certificado (CSR).

   openssl req -new -sha256 -key contoso.key -out contoso.csr
   

2. Quando solicitado, digite a informação organizacional da CA personalizada, como país/região, estado, organização, OU e o domínio totalmente qualificado (este domínio é o emissor). Como a chave raiz não está protegida por palavra-passe, o OpenSSL não te pede palavra-passe.

   

3. Use o seguinte comando para gerar o certificado raiz.

   openssl x509 -req -sha256 -days 365 -in contoso.csr -signkey contoso.key -out contoso.crt
   

   Os comandos anteriores criam o certificado raiz. Usa este certificado para assinar o seu certificado de servidor.

Criar um certificado de servidor

De seguida, cria um certificado de servidor usando OpenSSL.

Criar a chave do certificado

Use o comando a seguir para gerar a chave para o certificado do servidor.

openssl ecparam -out fabrikam.key -name prime256v1 -genkey

Criar o CSR (Pedido de Assinatura de Certificado)

O CSR é uma chave pública que se entrega a uma CA quando se solicita um certificado. A autoridade de certificação emite o certificado para essa solicitação específica.

1. Use o seguinte comando para gerar o CSR:

   openssl req -new -sha256 -key fabrikam.key -out fabrikam.csr
   

2. Quando solicitado, escreva a informação organizacional da CA personalizada: País/Região, Estado, Organização, OU e o domínio totalmente qualificado. Este domínio pertence ao site e deve ser diferente do emissor. Tal como a chave raiz, a chave do servidor não está protegida por palavra-passe, por isso o OpenSSL não te pede palavra-passe.

   

Gere o certificado com o CSR e a chave e assine-o com a chave raiz da autoridade de certificação

1. Use o seguinte comando para criar o certificado:

   openssl x509 -req -in fabrikam.csr -CA  contoso.crt -CAkey contoso.key -CAcreateserial -out fabrikam.crt -days 365 -sha256
   

Verificar o certificado recém-criado

1. Use o seguinte comando para imprimir a saída do arquivo CRT e verificar seu conteúdo:

   openssl x509 -in fabrikam.crt -text -noout
   

   

2. Verifique os arquivos em seu diretório e verifique se você tem os seguintes arquivos:

   • contoso.crt
   • contoso.key
   • fabrikam.crt
   • fabrikam.key

Configure o certificado nas configurações TLS do seu servidor Web

No teu servidor web, configura o TLS usando os ficheiros fabrikam.crt e fabrikam.key. Se o teu servidor web não conseguir aceitar dois ficheiros, podes combiná-los num único ficheiro .pem ou .pfx usando comandos OpenSSL.

IIS

Para obter instruções sobre como importar certificados e carregá-los como certificado de servidor no IIS, consulte COMO: Instalar certificados importados em um servidor Web no Windows Server 2003.

Para obter instruções de vinculação TLS, consulte Como configurar SSL no IIS 7.

Apache

A configuração a seguir é um exemplo de host virtual configurado para SSL no Apache:

<VirtualHost www.fabrikam:443>
      DocumentRoot /var/www/fabrikam
      ServerName www.fabrikam.com
      SSLEngine on
      SSLCertificateFile /home/user/fabrikam.crt
      SSLCertificateKeyFile /home/user/fabrikam.key
</VirtualHost>

NGINX

A configuração a seguir é um exemplo de bloco de servidor NGINX com configuração TLS:

Acede ao servidor com o certificado auto-assinado

1. Adicione o certificado raiz ao armazenamento raiz confiável da sua máquina. Ao acessar o site, verifique se toda a cadeia de certificados é vista no navegador.

   

   Note

   O DNS deve ser configurado para apontar o nome do servidor web (neste exemplo, www.fabrikam.com) para o endereço IP do seu servidor web. Caso contrário, você pode editar o arquivo hosts para resolver o nome.

2. Navegue até o site e clique no ícone de cadeado na caixa de endereço do navegador para verificar as informações do site e do certificado.

Verifique a configuração com OpenSSL

Ou, você pode usar OpenSSL para verificar o certificado.

openssl s_client -connect localhost:443 -servername www.fabrikam.com -showcerts

Carregar o certificado raiz nas definições do backend do Application Gateway

O Application Gateway aceita um certificado raiz de confiança apenas como um certificado X.509 codificado em Base-64 que utiliza a extensão de nome de ficheiro .cer . O X.509 codificado em base-64 é uma codificação de texto, e é a codificação que o openssl x509 comando já produziu para o ficheiro contoso.crt anteriormente neste artigo.

Como o contoso.crt já contém a chave pública em formato codificado Base-64, renomeie a extensão do nome do ficheiro de .crt para .cer. Esta renomeação altera apenas a extensão do nome do ficheiro. Não converte a codificação do certificado, e não é necessária nenhuma conversão aqui. Um certificado que não esteja já codificado em Base-64 requer uma conversão real de codificação em vez de uma mudança de nome.

portal do Azure

Para carregar o certificado raiz confiável do portal, selecione as Configurações de back-end e selecione HTTPS no protocolo de back-end.

Azure PowerShell

Ou então usa CLI do Azure ou Azure PowerShell para carregar o certificado raiz. Os seguintes passos do Azure PowerShell adicionam um certificado raiz de confiança ao gateway de aplicação, criam uma sonda de saúde, criam uma configuração de backend, adicionam uma regra de encaminhamento e depois aplicam as alterações ao gateway.

Passo 1: Adicionar o certificado raiz de confiança

Este passo assume que o gateway de aplicação appgwv2 já existe no grupo de recursos rgOne. Obtém o gateway na variável $gw, que é utilizada em todos os passos seguintes, e carrega o ficheiro contoso.cer que renomeaste anteriormente.

## Add the trusted root certificate to the Application Gateway

$gw=Get-AzApplicationGateway -Name appgwv2 -ResourceGroupName rgOne

Add-AzApplicationGatewayTrustedRootCertificate `
   -ApplicationGateway $gw `
   -Name CustomCARoot `
   -CertificateFile "C:\Users\surmb\Downloads\contoso.cer"

$trustedroot = Get-AzApplicationGatewayTrustedRootCertificate `
   -Name CustomCARoot `
   -ApplicationGateway $gw

Passo 2: Criar a sonda de saúde

Este passo assume que tens a $gw variável do passo 1. Cria uma sonda HTTPS para www.fabrikam.com e armazena-a na variável $probe.

Add-AzApplicationGatewayProbeConfig `
  -ApplicationGateway $gw `
  -Name testprobe `
  -Protocol Https `
  -HostName "www.fabrikam.com" `
  -Path "/" `
  -Interval 15 `
  -Timeout 20 `
  -UnhealthyThreshold 3

$probe = Get-AzApplicationGatewayProbeConfig `
  -Name testprobe `
  -ApplicationGateway $gw

Passo 3: Criar a definição do backend

Este passo assume que tens os $gw, $trustedroot, e $probe variáveis dos passos anteriores. Cria a configuração de backend que utiliza o certificado raiz de confiança e a sonda.

## Add the configuration to the HTTP Setting and don't forget to set the "hostname" field
## to the domain name of the server certificate as this will be set as the SNI header and
## will be used to verify the backend server's certificate. Note that TLS handshake will
## fail otherwise and might lead to backend servers being deemed as Unhealthy by the probes

Add-AzApplicationGatewayBackendHttpSettings `
  -ApplicationGateway $gw `
  -Name testbackend `
  -Port 443 `
  -Protocol Https `
  -Probe $probe `
  -TrustedRootCertificate $trustedroot `
  -CookieBasedAffinity Disabled `
  -RequestTimeout 20 `
  -HostName www.fabrikam.com

$backendhttp = Get-AzApplicationGatewayBackendHttpSettings `
  -Name testbackend `
  -ApplicationGateway $gw

Passo 4: Criar a regra de roteamento

Este passo assume que tens a $gw variável do passo 1 e a $backendhttp variável do passo 3, e que o listener basichttps e o backend pool testbackendpool já existem no gateway.

$listener = Get-AzApplicationGatewayHttpListener `
   -Name basichttps `
   -ApplicationGateway $gw

$bepool = Get-AzApplicationGatewayBackendAddressPool `
  -Name testbackendpool `
  -ApplicationGateway $gw

Add-AzApplicationGatewayRequestRoutingRule `
  -ApplicationGateway $gw `
  -Name testrule `
  -RuleType Basic `
  -BackendHttpSettings $backendhttp `
  -HttpListener $listener `
  -BackendAddressPool $bepool

Passo 5: Atualizar o gateway da aplicação

Os passos anteriores alteram o $gw objeto apenas na memória. Este passo assume que tem a variável $gw do passo 1 com todas as alterações anteriores aplicadas e confirma essas alterações no gateway no Azure.

Set-AzApplicationGateway -ApplicationGateway $gw

Verificar o estado do back-end do gateway de aplicação

1. Selecione a vista de Saúde do Backend do seu gateway de aplicação para verificar se a sonda está saudável.
2. Você deve ver que o Status é Íntegro para a sonda HTTPS.

Próximos passos

Para saber mais sobre SSL\TLS no Application Gateway, consulte Visão geral da terminação TLS e TLS de ponta a ponta com o Application Gateway.