Generare un certificato autofirmato di gateway applicazione Azure con una CA radice personalizzata

Lo SKU v2 del gateway applicazione introduce l'uso di certificato radice trusted per consentire le connessioni TLS con i server back-end. Questa funzionalità rimuove l'uso dei certificati di autenticazione (certificati Leaf individuali) necessari nel v1 SKU. Il certificato radice è un certificato radice nel formato X.509 (.CER) con codifica Base-64 proveniente dal server di certificati backend. Identifica l'autorità di certificazione radice (CA) che ha emesso il certificato del server e il certificato del server viene quindi usato per la comunicazione TLS/SSL.

Il gateway applicativo considera attendibile il certificato del sito Web se una CA nota (ad esempio, GoDaddy o DigiCert) lo firma, per impostazione predefinita. Il caricamento esplicito del certificato radice non è necessario in tal caso. Per altre informazioni, vedere Panoramica della terminazione TLS e di TLS end-to-end con il gateway applicazione. Tuttavia, se si dispone di un ambiente di sviluppo/test e non si vuole acquistare un certificato firmato dalla CA verificata, è possibile creare una CA radice personalizzata e un certificato foglia firmato da tale CA radice.

Usare le opzioni seguenti per generare il certificato privato per le connessioni TLS back-end.

1. Usare lo strumento generatore di certificati privato. Usando il nome di dominio (Nome comune) specificato, questo strumento esegue gli stessi passaggi descritti in questo articolo per generare certificati radice e server. Con i file di certificati generati, è possibile caricare immediatamente il certificato radice (.CER) nelle impostazioni del backend del gateway e la corrispondente catena di certificazione (.PFX) nel server backend. La password per il file PFX viene fornita anche nel file ZIP scaricato.

2. Usare i comandi OpenSSL per personalizzare e generare certificati in base alle esigenze. Continuare a seguire le istruzioni in questo articolo se si vuole eseguire questo processo interamente autonomamente.

In questo articolo vengono illustrate le operazioni seguenti:

• Creare un'autorità di certificazione personalizzata
• Creare un certificato firmato dalla tua CA personalizzata
• Caricare un certificato radice autofirmato su un gateway di applicazione per autenticare il server back-end

Prerequisites

• OpenSSL in un computer che esegue Windows o Linux

  Anche se altri strumenti potrebbero essere disponibili per la gestione dei certificati, questa esercitazione usa OpenSSL. È possibile trovare OpenSSL in bundle con molte distribuzioni Linux, ad esempio Ubuntu.

• Un server Web

  Ad esempio, Apache, IIS o NGINX per testare i certificati.

• SKU v2 del gateway applicazione

  Se non hai un gateway applicativo esistente, consulta Avvio rapido: Indirizzare il traffico Web con il gateway applicativo di Azure - Portale di Azure.

Creare un certificato CA radice

Creare il certificato CA principale usando OpenSSL.

Creare la chiave radice

1. Accedere al computer in cui è installato OpenSSL ed eseguire il comando seguente. Questo comando crea la chiave privata root. La chiave non è criptata e non è protetta da una password, quindi conserva il file contoso.key in modo sicuro.

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

Creare un certificato radice e firmarlo automaticamente

1. Usare il comando seguente per generare la richiesta di firma del certificato (CSR).

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

2. Quando richiesto, digita le informazioni organizzative per la CA personalizzata come paese/regione, stato, org, OU e il nome di dominio completamente qualificato (questo dominio è l'emittente). Poiché la chiave root non è protetta da password, OpenSSL non ti chiede una password.

   

3. Usare il comando seguente per generare il certificato radice.

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

   I comandi precedenti creano il certificato radice. Questo certificato viene usato per firmare il certificato del server.

Creare un certificato del server

Successivamente, si crea un certificato server usando OpenSSL.

Creare la chiave del certificato

Usare il comando seguente per generare la chiave per il certificato del server.

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

Creare la CSR (richiesta di firma del certificato)

La CSR (richiesta di firma del certificato) è un documento che contiene una chiave pubblica che si fornisce a una CA quando si richiede un certificato. La CA rilascia il certificato per questa richiesta specifica.

1. Usare il comando seguente per generare il file con estensione csr:

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

2. Quando richiesto, digita le informazioni organizzative per la CA personalizzata: Paese/Regione, Stato, Org, OU e il nome di dominio completamente qualificato. Questo dominio è il dominio del sito Web e deve essere diverso dall'emittente. Come la chiave root, la chiave server non è protetta da password, quindi OpenSSL non ti chiede una password.

   

Generare il certificato con csr e la chiave e firmarlo con la chiave radice della CA

1. Usare il comando seguente per creare il certificato:

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

Verificare il certificato appena creato

1. Usare il comando seguente per stampare l'output del file CRT e verificarne il contenuto:

   openssl x509 -in fabrikam.crt -text -noout
   

   

2. Verificare i file nella directory e assicurarsi di disporre dei file seguenti:

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

Configurare il certificato nelle impostazioni TLS del server Web

Nel server Web configurare TLS usando i file fabrikam.crt e fabrikam.key. Se il server Web non può accettare due file, è possibile combinarli in un singolo file con estensione pem o pfx usando i comandi OpenSSL.

IIS

Per istruzioni su come importare il certificato e caricarli come certificato server in IIS, vedere PROCEDURA: Installare certificati importati in un server Web in Windows Server 2003.

Per istruzioni sull'associazione TLS, vedere Come configurare SSL in IIS 7.

Apache

La configurazione seguente è un host virtuale di esempio configurato per SSL in 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

La configurazione seguente è un esempio di blocco di server NGINX con configurazione TLS:

Accedere al server con il certificato autofirmato

1. Aggiungere il certificato root all'archivio root attendibile della macchina. Quando si accede al sito Web, verificare che nel browser sia visualizzata l'intera catena di certificati.

   

   Note

   Il DNS deve essere configurato per puntare il nome del server Web (in questo esempio , www.fabrikam.com) all'indirizzo IP del server Web. In caso contrario, è possibile modificare il file hosts per risolvere il nome.

2. Passare al sito Web e fare clic sull'icona di blocco nella casella indirizzo del browser per verificare il sito e le informazioni sul certificato.

Verificare la configurazione con OpenSSL

In alternativa, è possibile usare OpenSSL per verificare il certificato.

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

Carica il certificato root nelle impostazioni backend di Application Gateway

Application Gateway accetta un certificato radice attendibile solo sotto forma di certificato X.509 con codifica Base-64 che usa l'estensione del nome file .cer. X.509 con codifica Base-64 è una codifica di testo ed è la codifica che il comando openssl x509 ha già prodotto per il file contoso.crt in precedenza in questo articolo.

Poiché contoso.crt contiene già la chiave pubblica in formato codificato Base-64, rinomina l'estensione del nome file da .crt a .cer. Questo rinome modifica solo l'estensione del nome del file. Non converte la codifica del certificato, e qui non è necessaria alcuna conversione. Un certificato che non è già codificato Base-64 richiede una vera conversione di codifica invece di un cambio di nome.

Azure portal

Per caricare il certificato radice attendibile dal portale, selezionare impostazioni back-end e selezionare HTTPS nel protocollo back-end.

Azure PowerShell

In alternativa, usare l'interfaccia della riga di comando di Azure o Azure PowerShell per caricare il certificato radice. I seguenti passaggi di Azure PowerShell aggiungono un certificato root affidabile al gateway applicativo, creano una sonde di salute, creano un'impostazione backend, aggiungono una regola di routing e applicano le modifiche al gateway.

Passo 1: Aggiungi il certificato root affidabile

Questo passaggio presuppone che il gateway applicativo appgwv2 esista già nel gruppo di risorse rgOne. Recupera il gateway nella $gw variabile che ogni passo successivo usa e carica il file contoso.cer che hai rinominato prima.

## 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: Crea la sonda sanitaria

Questo passaggio presuppone che tu abbia la variabile $gw del passo 1. Crea una sonda HTTPS per www.fabrikam.com e la memorizza nella variabile $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: Crea l'impostazione di backend

Questo passaggio presuppone che tu abbia le $gwvariabili , $trustedroot, e $probe dei passaggi precedenti. Crea l'impostazione backend che utilizza il certificato root affidabile e la 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: Crea la regola di routing

Questo passaggio presuppone che tu abbia la variabile $gw del passaggio 1 e la variabile $backendhttp del passaggio 3, e che il listener basichttps e il pool back-end testbackendpool esistano già nel 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: Aggiorna il gateway applicativo

I passaggi precedenti modificano l'oggetto $gw solo in memoria. Questo passaggio presuppone che tu abbia la $gw variabile del passo 1 con tutte le modifiche precedenti applicate, e invia il commit di tali modifiche al gateway in Azure.

Set-AzApplicationGateway -ApplicationGateway $gw

Verificare lo stato di integrità del back-end del gateway dell'applicazione

1. Selezionare la vista Integrità back-end dell'applicazione gateway per verificare se il probe è integro.
2. Per il probe HTTPS lo stato è Integro.

Passaggi successivi

Per altre informazioni su SSL\TLS nel gateway applicazione, vedere Panoramica della terminazione TLS e di TLS end-to-end con il gateway applicazione.