Azure Firewall Premium-certificaten
Als u Azure Firewall Premium TLS-inspectie goed wilt configureren, moet u een geldig tussenliggend CA-certificaat opgeven en dit in Azure Key Vault storten.
Certificaten die worden gebruikt door Azure Firewall Premium
Er zijn drie typen certificaten die worden gebruikt in een typische implementatie:
Tussenliggend CA-certificaat (CA-certificaat)
Een certificeringsinstantie (CA) is een organisatie die wordt vertrouwd om digitale certificaten te ondertekenen. Een CA controleert de identiteit en geldigheid 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 controleren op basis 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 staat, 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 hij of zij 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 adres van de website komt overeen met het adres op het certificaat.
- Het certificaat wordt 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. Met 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 meest recente 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 uw organisatie-basis-CA-certificaat of tussenliggend CA-certificaat vertrouwen om deze procedure te laten werken.
Vereisten voor tussenliggende CA-certificaten
Zorg ervoor dat uw CA-certificaat voldoet aan de volgende vereisten:
Wanneer deze wordt geïmplementeerd als key vault-geheim, moet u PFX (PKCS12) zonder wachtwoord gebruiken met een certificaat en een persoonlijke sleutel. PEM-certificaten worden niet ondersteund.
Het moet één certificaat zijn en mag niet de volledige keten van certificaten bevatten.
Het moet één jaar vooruit geldig zijn.
Het moet een persoonlijke RSA-sleutel zijn met minimale grootte van 4096 bytes.
De extensie moet als
KeyUsage
kritiek zijn gemarkeerd met deKeyCertSign
vlag (RFC 5280; 4.2.1.3-sleutelgebruik).De extensie moet zijn
BasicConstraints
gemarkeerd als kritiek (RFC 5280; 4.2.1.9 Basisbeperkingen).De
CA
vlag moet worden ingesteld op TRUE.De padlengte moet groter dan of gelijk aan één zijn.
Het moet exporteerbaar zijn.
Azure Key Vault
Azure Key Vault is een door het platform beheerd geheim archief 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 sleutelpaar importeren in uw sleutelkluis.
- U kunt ook een sleutelkluisgeheim gebruiken dat is opgeslagen als een met een wachtwoord minder gecodeerd PFX-bestand met base 64. Een PFX-bestand is een digitaal certificaat met zowel een persoonlijke sleutel als een openbare sleutel.
- 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 de identiteit toegang te geven tot het certificaat/geheim.
- Het opgegeven CA-certificaat moet worden vertrouwd door uw Azure-workload. Zorg ervoor dat ze correct zijn geïmplementeerd.
- Omdat Azure Firewall Premium wordt vermeld als vertrouwde Key Vault-service, kunt u de interne firewall van Key Vault omzeilen en eventuele blootstelling van uw Key Vault aan internet elimineren.
Notitie
Wanneer u een nieuw CA-certificaat voor de firewall importeert in Azure Key Vault (voor het eerst of een verlopen CA-certificering vervangt), moet u de TLS-instelling voor Azure Firewall Policy expliciet bijwerken met het nieuwe certificaat.
U kunt een bestaande door de gebruiker toegewezen beheerde identiteit maken of opnieuw gebruiken, die door Azure Firewall wordt gebruikt om namens u certificaten op te halen uit Key Vault. Zie Wat zijn beheerde identiteiten voor Azure-resources voor meer informatie ?
Notitie
Op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC) wordt momenteel niet ondersteund voor autorisatie. Gebruik in plaats daarvan het toegangsbeleidsmodel. Zie op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC) versus toegangsbeleid voor meer informatie.
Een certificaat in uw beleid configureren
Als u een CA-certificaat in uw Firewall Premium-beleid wilt configureren, 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:
Belangrijk
Als u een certificaat wilt bekijken en configureren vanuit Azure Portal, moet u uw Azure-gebruikersaccount toevoegen aan het Key Vault-toegangsbeleid. Geef uw gebruikersaccount Ophalen en weergeven onder Geheime machtigingen.
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 Enterprise CA-certificaten 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 maken ook gebruik van 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 - Tussenliggend openbaar CA-certificaat en persoonlijke sleutel
- interCA.pfx - Tussenliggend CA pkcs12-pakket dat wordt gebruikt door firewall
Belangrijk
rootCA.key moet worden opgeslagen op een veilige offlinelocatie. De scripts genereren een certificaat met een geldigheid van 1024 dagen. Voor de scripts zijn geopende binaire bestanden vereist die op uw lokale computer zijn geïnstalleerd. Zie voor meer informatie https://www.openssl.org/
Nadat de certificaten zijn gemaakt, implementeert u deze op de volgende locaties:
- rootCA.crt - Implementeren op eindpuntcomputers (alleen openbaar certificaat).
- interCA.pfx : importeren als certificaat in een Sleutelkluis 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 voor automatische generatie van Azure Firewall Premium-certificering gebruiken, waarmee automatisch de volgende drie resources voor u worden gemaakt:
- Beheerde identiteit
- Key Vault
- Zelfondertekend basis-CA-certificaat
Kies gewoon de nieuwe beheerde identiteit en koppelt de drie resources aan elkaar in uw Premium-beleid en stelt TLS-inspectie in.
Probleemoplossing
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:
Controleer of 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 speciale certificeringsbeleidsregels.
Zorg ervoor dat het URL-doeltype in uw toepassingsregel het juiste pad bevat en alle andere hyperlinks die zijn ingesloten in de HTML-doelpagina. U kunt jokertekens gebruiken voor een eenvoudige dekking van het volledige vereiste URL-pad.