Condividi tramite

Certificati di Firewall di Azure Premium

  • Articolo

Per configurare correttamente Firewall di Azure ispezione TLS Premium, è necessario fornire un certificato CA intermedio valido e depositarlo in Azure Key Vault.

Certificati usati da Firewall di Azure Premium

Esistono tre tipi di certificati usati in una distribuzione tipica:

  • Certificato CA intermedio (certificato CA)

    Un'autorità di certificazione (CA) è un'organizzazione attendibile per firmare certificati digitali. Una CA verifica l'identità e la legittimità di una società o di una persona che richiede un certificato. Se la verifica ha esito positivo, la CA rilascia un certificato firmato. Quando il server presenta il certificato al client (ad esempio, il Web browser) durante un handshake SSL/TLS, il client tenta di verificare la firma rispetto a un elenco di firmatari validi noti . I Web browser in genere sono dotati di elenchi di ca che considerano attendibili in modo implicito per identificare gli host. Se l'autorità non è presente nell'elenco, come con alcuni siti che firmano i propri certificati, il browser avvisa l'utente che il certificato non è firmato da un'autorità riconosciuta e chiede all'utente se desidera continuare le comunicazioni con un sito non verificato.

  • Certificato server (certificato del sito Web)

    Certificato associato a un nome di dominio specifico. Se un sito Web ha un certificato valido, significa che un'autorità di certificazione ha eseguito i passaggi per verificare che l'indirizzo Web appartenga effettivamente a tale organizzazione. Quando si digita un URL o si segue un collegamento a un sito Web sicuro, il browser controlla il certificato per verificare le caratteristiche seguenti:

    • L'indirizzo del sito Web corrisponde all'indirizzo del certificato.
    • Il certificato viene firmato da un'autorità di certificazione riconosciuta dal browser come autorità attendibile .

    In alcuni casi gli utenti possono connettersi a un server con un certificato non attendibile. Firewall di Azure la connessione verrà interrotta come se il server terminasse la connessione.

  • Certificato CA radice (certificato radice)

    Un'autorità di certificazione può rilasciare più certificati sotto forma di struttura ad albero. Un certificato radice è il certificato più alto dell'albero.

Firewall di Azure Premium può intercettare il traffico HTTP/S in uscita e generare automaticamente un certificato server per www.website.com. Questo certificato viene generato usando il certificato CA intermedio fornito. Le applicazioni client e il browser dell'utente finale (IaaS, PaaS e altri carichi di lavoro) devono considerare attendibile il certificato CA radice dell'organizzazione o il certificato ca intermedio per il funzionamento di questa procedura.

Processo del certificato

Requisiti del certificato CA intermedio

Verificare che il certificato della CA sia conforme ai requisiti seguenti:

  • Quando viene distribuito come segreto di Key Vault, è necessario usare PFX senza password (PKCS12) con un certificato e una chiave privata. I certificati PEM non sono supportati.

  • Deve essere un singolo certificato e non deve includere l'intera catena di certificati.

  • Deve essere valido per un anno in avanti.

  • Deve essere una chiave privata RSA con dimensioni minime di 4096 byte.

  • Deve avere l'estensione KeyUsage contrassegnata come Critical con il KeyCertSign flag (RFC 5280; 4.2.1.3 Key Usage).

  • Deve avere l'estensione BasicConstraints contrassegnata come Critical (RFC 5280; 4.2.1.9 Basic Constraints).

  • Il CA flag deve essere impostato su TRUE.

  • La lunghezza del percorso deve essere maggiore o uguale a una.

  • Deve essere esportabile.

Azure Key Vault

Azure Key Vault è un archivio segreto gestito da piattaforma che è possibile usare per proteggere segreti, chiavi e certificati TLS/SSL. Firewall di Azure Premium supporta l'integrazione con Key Vault per i certificati server collegati a criteri firewall.

Per configurare l'insieme di credenziali delle chiavi:

  • È necessario importare un certificato esistente con la relativa coppia di chiavi nell'insieme di credenziali delle chiavi.
  • In alternativa, è anche possibile usare un segreto dell'insieme di credenziali delle chiavi archiviato come file PFX con codifica base 64 senza password. Un file PFX è un certificato digitale contenente sia chiave privata che chiave pubblica.
  • È consigliabile usare un'importazione di certificati CA perché consente di configurare un avviso in base alla data di scadenza del certificato.
  • Dopo aver importato un certificato o un segreto, è necessario definire i criteri di accesso nell'insieme di credenziali delle chiavi per consentire all'identità di ottenere l'accesso al certificato/segreto.
  • Il certificato della CA fornito deve essere considerato attendibile dal carico di lavoro di Azure. Assicurarsi che siano distribuiti correttamente.
  • Poiché Firewall di Azure Premium è elencato come servizio attendibile dell'insieme di credenziali delle chiavi, consente di ignorare il firewall interno dell'insieme di credenziali delle chiavi ed eliminare qualsiasi esposizione dell'insieme di credenziali delle chiavi a Internet.

Nota

Ogni volta che si importa un nuovo certificato ca del firewall in Azure Key Vault (per la prima volta o sostituendo una certificazione CA scaduta), è necessario aggiornare in modo esplicito l'impostazione TLS dei criteri di Firewall di Azure con il nuovo certificato.

È possibile creare o riutilizzare un'identità gestita assegnata dall'utente esistente, che Firewall di Azure usa per recuperare i certificati da Key Vault per conto dell'utente. Per altre informazioni, vedere Informazioni sulle identità gestite per le risorse di Azure?

Nota

Il controllo degli accessi in base al ruolo di Azure non è attualmente supportato per l'autorizzazione. Usare invece il modello dei criteri di accesso. Per altre informazioni, vedere Controllo degli accessi in base al ruolo di Azure e criteri di accesso.

Configurare un certificato nei criteri

Per configurare un certificato DELLA CA nei criteri Firewall Premium, selezionare i criteri e quindi selezionare Ispezione TLS. Selezionare Abilitato nella pagina Ispezione TLS. Selezionare quindi il certificato della CA in Azure Key Vault, come illustrato nella figura seguente:

Diagramma di panoramica di Firewall di Azure Premium

Importante

Per visualizzare e configurare un certificato dal portale di Azure, è necessario aggiungere l'account utente di Azure ai criteri di accesso di Key Vault. Assegnare all'account utente Get and List in Secret Permissions (Autorizzazioni segrete). Criteri di accesso di Azure Key Vault

Creare un certificato della CA autofirmato

Se si vogliono creare certificati personalizzati per testare e verificare l'ispezione TLS, è possibile usare gli script seguenti per creare una CA radice autofirmato e una CA intermedia.

Importante

Per la produzione, è consigliabile usare l'infrastruttura a chiave pubblica aziendale per creare un certificato ca intermedio. Un'infrastruttura PKI aziendale sfrutta l'infrastruttura esistente e gestisce la distribuzione della CA radice in tutti i computer endpoint. Per altre informazioni, vedere Distribuire e configurare i certificati dell'autorità di certificazione enterprise per Firewall di Azure.

Esistono due versioni di questo script:

  • uno script bash cert.sh
  • uno script di PowerShell cert.ps1

Inoltre, entrambi gli script usano il openssl.cnf file di configurazione. Per usare gli script, copiare il contenuto di openssl.cnfe cert.sh o cert.ps1 nel computer locale.

Gli script generano i file seguenti:

  • rootCA.crt/rootCA.key - Certificato pubblico ca radice e chiave privata.
  • interCA.crt/interCA.key - Certificato pubblico ca intermedio e chiave privata
  • interCA.pfx - Pacchetto pkcs12 ca intermedio che verrà usato dal firewall

Importante

rootCA.key deve essere archiviato in una posizione offline sicura. Gli script generano un certificato con validità di 1024 giorni. Gli script richiedono file binari openssl installati nel computer locale. Per altre informazioni,https://www.openssl.org/ vedere

Dopo aver creato i certificati, distribuirli nei percorsi seguenti:

  • rootCA.crt: eseguire la distribuzione nei computer endpoint (solo certificato pubblico).
  • interCA.pfx: importare come certificato in un insieme di credenziali delle chiavi e assegnare ai criteri del firewall.

openssl.cnf

[ req ]
default_bits        = 4096
distinguished_name  = req_distinguished_name
string_mask         = utf8only
default_md          = sha512

[ req_distinguished_name ]
countryName                     = Country Name (2 letter code)
stateOrProvinceName             = State or Province Name
localityName                    = Locality Name
0.organizationName              = Organization Name
organizationalUnitName          = Organizational Unit Name
commonName                      = Common Name
emailAddress                    = Email Address

[ rootCA_ext ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ interCA_ext ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:1
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ server_ext ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:false
keyUsage = critical, digitalSignature
extendedKeyUsage = serverAuth

Script Bash - cert.sh

#!/bin/bash

# Create root CA
openssl req -x509 -new -nodes -newkey rsa:4096 -keyout rootCA.key -sha256 -days 1024 -out rootCA.crt -subj "/C=US/ST=US/O=Self Signed/CN=Self Signed Root CA" -config openssl.cnf -extensions rootCA_ext

# Create intermediate CA request
openssl req -new -nodes -newkey rsa:4096 -keyout interCA.key -sha256 -out interCA.csr -subj "/C=US/ST=US/O=Self Signed/CN=Self Signed Intermediate CA"

# Sign on the intermediate CA
openssl x509 -req -in interCA.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out interCA.crt -days 1024 -sha256 -extfile openssl.cnf -extensions interCA_ext

# Export the intermediate CA into PFX
openssl pkcs12 -export -out interCA.pfx -inkey interCA.key -in interCA.crt -password "pass:"

echo ""
echo "================"
echo "Successfully generated root and intermediate CA certificates"
echo "   - rootCA.crt/rootCA.key - Root CA public certificate and private key"
echo "   - interCA.crt/interCA.key - Intermediate CA public certificate and private key"
echo "   - interCA.pfx - Intermediate CA pkcs12 package which could be uploaded to Key Vault"
echo "================"

PowerShell - cert.ps1

# Create root CA
openssl req -x509 -new -nodes -newkey rsa:4096 -keyout rootCA.key -sha256 -days 3650 -out rootCA.crt -subj '/C=US/ST=US/O=Self Signed/CN=Self Signed Root CA' -config openssl.cnf -extensions rootCA_ext

# Create intermediate CA request
openssl req -new -nodes -newkey rsa:4096 -keyout interCA.key -sha256 -out interCA.csr -subj '/C=US/ST=US/O=Self Signed/CN=Self Signed Intermediate CA'

# Sign on the intermediate CA
openssl x509 -req -in interCA.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out interCA.crt -days 3650 -sha256 -extfile openssl.cnf -extensions interCA_ext

# Export the intermediate CA into PFX
openssl pkcs12 -export -out interCA.pfx -inkey interCA.key -in interCA.crt -password 'pass:'

Write-Host ""
Write-Host "================"
Write-Host "Successfully generated root and intermediate CA certificates"
Write-Host "   - rootCA.crt/rootCA.key - Root CA public certificate and private key"
Write-Host "   - interCA.crt/interCA.key - Intermediate CA public certificate and private key"
Write-Host "   - interCA.pfx - Intermediate CA pkcs12 package which could be uploaded to Key Vault"
Write-Host "================"

Generazione automatica dei certificati

Per le distribuzioni non di produzione, è possibile usare il meccanismo di generazione automatica della certificazione Premium Firewall di Azure, che crea automaticamente le tre risorse seguenti:

  • Identità gestita
  • Key Vault
  • Certificato CA radice autofirmato

È sufficiente scegliere la nuova identità gestita e collegare le tre risorse nei criteri Premium e configurare l'ispezione TLS.

Screenshot che mostra i certificati generati automaticamente.

Risoluzione dei problemi

Se il certificato della CA è valido, ma non è possibile accedere agli FQDN o agli URL in ispezione TLS, controllare gli elementi seguenti:

  • Verificare che il certificato del server Web sia valido.

  • Verificare che il certificato CA radice sia installato nel sistema operativo client.

  • Verificare che il browser o il client HTTPS contenga un certificato radice valido. Firefox e altri browser potrebbero avere criteri di certificazione speciali.

  • Verificare che il tipo di destinazione URL nella regola dell'applicazione includa il percorso corretto e tutti gli altri collegamenti ipertestuali incorporati nella pagina HTML di destinazione. È possibile usare i caratteri jolly per semplificare la copertura dell'intero percorso URL richiesto.

Passaggi successivi