Azure Firewall Premium-certificaten

  • Artikel
  • 7 minuten om te lezen

Als u Azure Firewall Premium TLS-inspectie correct wilt configureren, moet u een geldig tussenliggend CA-certificaat opgeven en dit in Azure Key Vault deponeren.

Certificaten die door Azure Firewall Premium worden gebruikt

Er worden drie typen certificaten gebruikt in een typische implementatie:

  • Tussenliggend CA-certificaat (CA-certificaat)

    Een certificeringsinstantie (CA) is een organisatie die wordt vertrouwd met het ondertekenen van digitale certificaten. Een CA verifieert de identiteit en de legitimiteit van een bedrijf of persoon die een certificaat aanvraagt. Als de verificatie is geslaagd, geeft de CA een ondertekend certificaat uit. Wanneer de server het certificaat aan de client (bijvoorbeeld uw webbrowser) presenteert tijdens een SSL/TLS-handshake, probeert de client de handtekening te verifiëren aan de hand van een lijst met bekende goede ondertekenaars. Webbrowsers worden normaal gesproken geleverd met lijsten met CA's die ze impliciet vertrouwen om hosts te identificeren. Als de instantie niet in de lijst voorkomt, zoals bij sommige sites die hun eigen certificaten ondertekenen, waarschuwt de browser de gebruiker dat het certificaat niet is ondertekend door een erkende instantie en vraagt de gebruiker of deze de communicatie met niet-geverifieerde site wil voortzetten.

  • Servercertificaat (websitecertificaat)

    Een certificaat dat is gekoppeld aan een specifieke domeinnaam. Als een website een geldig certificaat heeft, betekent dit dat een certificeringsinstantie stappen heeft ondernomen om te controleren of het webadres daadwerkelijk bij die organisatie hoort. Wanneer u een URL typt of een koppeling naar een beveiligde website volgt, controleert uw browser het certificaat op de volgende kenmerken:

    • Het websiteadres komt overeen met het adres op het certificaat.
    • Het certificaat is ondertekend door een certificeringsinstantie die door de browser wordt herkend als een vertrouwde instantie.

    Soms kunnen gebruikers verbinding maken met een server met een niet-vertrouwd certificaat. Azure Firewall wordt de verbinding verbroken alsof de server de verbinding heeft beëindigd.

  • Basis-CA-certificaat (basiscertificaat)

    Een certificeringsinstantie kan meerdere certificaten uitgeven in de vorm van een structuurstructuur. Een basiscertificaat is het hoogste certificaat van de structuur.

Azure Firewall Premium kan uitgaand HTTP/S-verkeer onderscheppen en automatisch een servercertificaat genereren voor www.website.com. Dit certificaat wordt gegenereerd met behulp van het tussenliggende CA-certificaat dat u opgeeft. Browser- en clienttoepassingen van eindgebruikers (IaaS, PaaS en andere workloads) moeten het basis-CA-certificaat of het tussenliggende CA-certificaat van uw organisatie vertrouwen om deze procedure te laten werken.

Certificaatproces

Vereisten voor tussenliggende CA-certificaten

Zorg ervoor dat uw CA-certificaat voldoet aan de volgende vereisten:

  • Wanneer deze is geïmplementeerd als een Key Vault geheim, moet u PFX (Pkcs12) zonder wachtwoord gebruiken met een certificaat en een persoonlijke sleutel.

  • Het moet één certificaat zijn en mag niet de hele keten van certificaten bevatten.

  • Deze moet één jaar vooruit geldig zijn.

  • Het moet een persoonlijke RSA-sleutel zijn met een minimale grootte van 4096 bytes.

  • De extensie moet zijn KeyUsage gemarkeerd als Kritiek met de KeyCertSign vlag (RFC 5280; 4.2.1.3 Sleutelgebruik).

  • De extensie moet zijn BasicContraints gemarkeerd als Kritiek (RFC 5280; 4.2.1.9 Basic Constraints).

  • De CA vlag moet worden ingesteld op TRUE.

  • De padlengte moet groter zijn dan of gelijk zijn aan één.

Azure Key Vault

Azure Key Vault is een door het platform beheerd geheimarchief dat u kunt gebruiken om geheimen, sleutels en TLS/SSL-certificaten te beveiligen. Azure Firewall Premium ondersteunt integratie met Key Vault voor servercertificaten die zijn gekoppeld aan een firewallbeleid.

Uw sleutelkluis configureren:

  • U moet een bestaand certificaat met het bijbehorende sleutelpaar importeren in uw sleutelkluis.
  • U kunt ook een sleutelkluisgeheim gebruiken dat is opgeslagen als een pfx-bestand zonder wachtwoord, met base 64 gecodeerd. Een PFX-bestand is een digitaal certificaat dat zowel een persoonlijke als een openbare sleutel bevat.
  • Het is raadzaam om een CA-certificaatimport te gebruiken, omdat u hiermee een waarschuwing kunt configureren op basis van de vervaldatum van het certificaat.
  • Nadat u een certificaat of geheim hebt geïmporteerd, moet u toegangsbeleid definiëren in de sleutelkluis om toe te staan dat de identiteit toegang krijgt tot het certificaat/geheim.
  • Het opgegeven CA-certificaat moet worden vertrouwd door uw Azure-workload. Zorg ervoor dat ze correct zijn geïmplementeerd.
  • Aangezien Azure Firewall Premium wordt vermeld als Key Vault vertrouwde service, kunt u Key Vault interne firewall omzeilen en eventuele blootstelling van uw Key Vault aan internet elimineren.

U kunt een bestaande door de gebruiker toegewezen beheerde identiteit maken of opnieuw gebruiken, die Azure Firewall gebruikt om namens u certificaten op te halen uit Key Vault. Zie Wat zijn beheerde identiteiten voor Azure-resources? voor meer informatie.

Een certificaat configureren in uw beleid

Als u een CA-certificaat wilt configureren in uw Firewall Premium-beleid, selecteert u uw beleid en selecteert u vervolgens TLS-inspectie. Selecteer Ingeschakeld op de pagina TLS-inspectie . Selecteer vervolgens uw CA-certificaat in Azure Key Vault, zoals wordt weergegeven in de volgende afbeelding:

overzichtsdiagram van Azure Firewall Premium

Belangrijk

Als u een certificaat van de Azure Portal wilt zien en configureren, moet u uw Azure-gebruikersaccount toevoegen aan het Key Vault-toegangsbeleid. Geef uw gebruikersaccount Ophalen en vermelden onder Geheime machtigingen. Azure Key Vault-toegangsbeleid

Uw eigen zelfondertekende CA-certificaat maken

Als u uw eigen certificaten wilt maken om TLS-inspectie te testen en te verifiëren, kunt u de volgende scripts gebruiken om uw eigen zelfondertekende basis-CA en tussenliggende CA te maken.

Belangrijk

Voor productie moet u uw zakelijke PKI gebruiken om een tussenliggend CA-certificaat te maken. Een zakelijke PKI maakt gebruik van de bestaande infrastructuur en verwerkt de basis-CA-distributie naar alle eindpuntcomputers. Zie CA-certificaten voor ondernemingen implementeren en configureren voor Azure Firewall voor meer informatie.

Er zijn twee versies van dit script:

  • een bash-script cert.sh
  • een PowerShell-script cert.ps1

Beide scripts gebruiken ook het openssl.cnf configuratiebestand. Als u de scripts wilt gebruiken, kopieert u de inhoud van openssl.cnf, en cert.sh of cert.ps1 naar uw lokale computer.

De scripts genereren de volgende bestanden:

  • rootCA.crt/rootCA.key: openbaar basis-CA-certificaat en persoonlijke sleutel.
  • interCA.crt/interCA.key - Openbaar ca-certificaat en persoonlijke sleutel tussenliggende CA
  • interCA.pfx - Tussenliggend CA pkcs12-pakket dat door de firewall wordt gebruikt

Belangrijk

rootCA.key moet worden opgeslagen op een veilige offlinelocatie. De scripts genereren een certificaat met een geldigheidsduur van 1024 dagen. Voor de scripts moeten binaire openssl-bestanden zijn geïnstalleerd op uw lokale computer. Zie voor meer informatie https://www.openssl.org/

Nadat de certificaten zijn gemaakt, implementeert u ze op de volgende locaties:

  • rootCA.crt: implementeren op eindpuntcomputers (alleen openbaar certificaat).
  • interCA.pfx: importeren als certificaat op een Key Vault en toewijzen aan firewallbeleid.

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

Bash-script - 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 "================"

Automatisch genereren van certificaten

Voor niet-productie-implementaties kunt u het mechanisme Azure Firewall Premium-certificering automatisch genereren gebruiken, waarmee automatisch de volgende drie resources voor u worden gemaakt:

  • Beheerde identiteit
  • Key Vault
  • Zelfondertekend basis-CA-certificaat

Kies de nieuwe beheerde identiteit. Deze verbindt de drie resources in uw Premium-beleid en stelt TLS-inspectie in.

Schermopname van automatisch gegenereerde certificaten.

Problemen oplossen

Als uw CA-certificaat geldig is, maar u geen toegang hebt tot FQDN's of URL's onder TLS-inspectie, controleert u de volgende items:

  • Zorg ervoor dat het webservercertificaat geldig is.

  • Zorg ervoor dat het basis-CA-certificaat is geïnstalleerd op het clientbesturingssysteem.

  • Zorg ervoor dat de browser of HTTPS-client een geldig basiscertificaat bevat. Firefox en sommige andere browsers hebben mogelijk een speciaal certificeringsbeleid.

  • Zorg ervoor dat het URL-doeltype in uw toepassingsregel het juiste pad dekt en eventuele andere hyperlinks die zijn ingesloten in de HTML-doelpagina. U kunt jokertekens gebruiken voor eenvoudige dekking van het volledige vereiste URL-pad.

Volgende stappen