Gerar um certificado autoassinado do Gateway de Aplicativo do Azure com uma AC raiz personalizada
A SKU do Application Gateway v2 introduz o uso de Certificados Raiz Confiáveis para permitir conexões TLS com os servidores back-end. Essa disposição remove o uso de certificados de autenticação (certificados Leaf individuais) que eram necessários na SKU v1. O certificado raiz tem um formato de codificação Base 64 X.509(.CER) do servidor de certificados back-end. Ele identifica a AC (autoridade de certificação) raiz que emitiu o certificado do servidor, e esse certificado é usado para a comunicação TLS/SSL.
O Gateway de Aplicativo confiará no certificado do site por padrão se ele estiver assinado por uma AC conhecida (por exemplo, GoDaddy ou DigiCert). Neste caso, você não precisa carregar explicitamente o certificado raiz. Para saber mais, confira Visão geral da terminação de TLS e TLS de ponta a ponta com um Gateway de Aplicativo. No entanto, se você tiver um ambiente de desenvolvimento/teste e não quiser comprar um certificado assinado pela CA verificada, poderá criar sua própria CA Raiz personalizada e um certificado folha assinado por essa CA Raiz.
Observação
Os certificados gerados automaticamente não são confiáveis por padrão e podem ser difíceis de manter. Além disso, eles podem usar códigos hash e conjuntos de criptografia desatualizados que podem não ser fortes. Para obter mais segurança, adquira um certificado assinado por uma autoridade de certificação conhecida.
Você pode usar as opções a seguir para gerar seu certificado privado para conexões TLS de back-end.
Use a ferramenta geradora de certificados privados com um clique. Usando o nome de domínio (Nome comum) fornecido, essa ferramenta executa as mesmas etapas documentadas neste artigo para gerar certificados raiz e de servidor. Com os arquivos de certificado gerados, você pode carregar imediatamente o certificado raiz (. CER) para a Configuração de back-end do gateway e a cadeia de certificados correspondente (. PFX) para o servidor de back-end. A senha para o arquivo PFX também é fornecida no arquivo ZIP baixado.
Use comandos OpenSSL para personalizar e gerar certificados de acordo com suas necessidades. Continue a seguir as instruções neste artigo se você deseja fazer isso inteiramente por conta própria.
Neste artigo, você aprenderá a:
- Criar sua própria autoridade de certificação personalizada
- Criar um certificado autoassinado assinado por sua AC personalizada
- Carregar um certificado raiz autoassinado em um Gateway de Aplicativo para autenticar o servidor back-end
Pré-requisitos
OpenSSL em um computador executando Windows ou Linux
Embora possa haver outras ferramentas disponíveis para o gerenciamento de certificados, este tutorial usa OpenSSL. Você encontra o OpenSSL agrupado com várias distribuições do Linux, como o Ubuntu.
Um servidor Web
Por exemplo, Apache, IIS ou NGINX para testar os certificados.
SKU do Gateway de Aplicativo v2
Se você não tiver um gateway de aplicativo existente, consulte Início Rápido: direcionar o tráfego da Web com o Gateway de Aplicativo do Azure – portal do Azure.
Criar um certificado de AC raiz
Crie seu certificado de autoridade de certificação (AC) raiz usando o OpenSSL.
Criar a chave raiz
Conecte-se ao computador em que o OpenSSL está instalado e execute o comando a seguir. Isso cria uma chave criptografada.
openssl ecparam -out contoso.key -name prime256v1 -genkey
Criar um certificado raiz e assiná-lo automaticamente
Use o comando a seguir para gerar a CSR (solicitação de assinatura de certificado).
openssl req -new -sha256 -key contoso.key -out contoso.csr
Quando solicitado, digite a senha da chave raiz e as informações organizacionais da AC personalizada, como país/região, estado, org, UO e o nome de domínio totalmente qualificado (é o domínio do emissor).
Use o comando a seguir 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. Você o usará para assinar o certificado do servidor.
Criar um certificado do servidor
Em seguida, você criará um certificado de servidor usando o OpenSSL.
Criar a chave do certificado
Use o comando a seguir para gerar a chave do certificado do servidor.
openssl ecparam -out fabrikam.key -name prime256v1 -genkey
Criar a CSR (solicitação de assinatura de certificado)
A CSR é uma chave pública fornecida a uma AC na solicitação de um certificado. A AC emite o certificado para essa solicitação específica.
Observação
O CN (nome comum) do certificado do servidor deve ser diferente do domínio do emissor. Por exemplo, neste caso, o CN do emissor é www.contoso.com
e o CN do certificado do servidor é www.fabrikam.com
.
Use o comando a seguir para gerar a CSR:
openssl req -new -sha256 -key fabrikam.key -out fabrikam.csr
Quando solicitado, digite a senha da chave raiz e as informações organizacionais da AC personalizada: País/Região, Estado, Organização, UO e o nome de domínio totalmente qualificado. É o domínio do site e deve ser diferente do emissor.
Gerar o certificado com a CSR e a chave e assiná-lo com a chave raiz da AC
Use o comando a seguir 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
Use o comando a seguir para imprimir a saída do arquivo CRT e verificar seu conteúdo:
openssl x509 -in fabrikam.crt -text -noout
No seu diretório, verifique se você tem os seguintes arquivos:
- contoso.crt
- contoso.key
- fabrikam.crt
- fabrikam.key
Configurar o certificado nas configurações de TLS do servidor Web
No servidor Web, configure o TLS usando os arquivos fabrikam.crt e fabrikam.key. Se o servidor Web não puder usar dois arquivos, combine-os em um único arquivo .pem ou. pfx usando comandos do 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 de TLS, confira 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 bloqueios de servidor NGINX com a configuração de TLS:
Acessar o servidor para verificar a configuração
Adicione o certificado raiz ao repositório de raiz confiável do computador. Ao acessar o site, verifique se toda a cadeia de certificados é vista no navegador.
Observação
Supõe-se que o DNS foi configurado para apontar o nome do servidor Web (neste exemplo,
www.fabrikam.com
) para o endereço de IP do servidor Web. Caso contrário, edite o arquivo de host para resolver o nome.Navegue até seu site e clique no ícone de cadeado, na caixa de endereço do navegador, para verificar as informações do site e do certificado.
Verificar a configuração com OpenSSL
Você também pode usar OpenSSL para verificar o certificado.
openssl s_client -connect localhost:443 -servername www.fabrikam.com -showcerts
Carregar o certificado raiz nas configurações de HTTP do Gateway de Aplicativo
Para carregar o certificado no Gateway de Aplicativo, você deve exportar o certificado .crt para um formato .cer de codificação Base 64. Como o .cert já contém a chave pública no formato de codificação Base 64, basta renomear a extensão de arquivo de .crt para .cer.
Portal do Azure
Para carregar o certificado raiz confiável do portal, selecione Configurações de back-end e escolha HTTPS no Protocolo de back-end.
PowerShell do Azure
Você também pode usar o CLI do Azure ou o Azure PowerShell para carregar o certificado raiz. O código a seguir é um exemplo do Azure PowerShell.
Observação
O exemplo a seguir adiciona um certificado raiz confiável ao Gateway de Aplicativo, cria uma nova configuração de HTTP e adiciona uma nova regra, supondo que o pool do back-end e o ouvinte já existam.
## 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
## Get the listener, backend pool and probe
$listener = Get-AzApplicationGatewayHttpListener `
-Name basichttps `
-ApplicationGateway $gw
$bepool = Get-AzApplicationGatewayBackendAddressPool `
-Name testbackendpool `
-ApplicationGateway $gw
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
## 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
## Get the configuration and update the Application Gateway
$backendhttp = Get-AzApplicationGatewayBackendHttpSettings `
-Name testbackend `
-ApplicationGateway $gw
Add-AzApplicationGatewayRequestRoutingRule `
-ApplicationGateway $gw `
-Name testrule `
-RuleType Basic `
-BackendHttpSettings $backendhttp `
-HttpListener $listener `
-BackendAddressPool $bepool
Set-AzApplicationGateway -ApplicationGateway $gw
Verificar a integridade do back-end do Gateway de Aplicativo
- Clique na exibição Integridade de back-end do seu gateway de aplicativo para verificar se a investigação está íntegra.
- O Status da investigação HTTPS deve ser Healthy.
Próximas etapas
Para saber mais sobre SSL\TLS no Gateway de Aplicativo, confira Visão geral do término de TLS e TLS de ponta a ponta com o Gateway de Aplicativo.