Delen via

Overzicht van wederzijdse verificatie met Application Gateway

Met wederzijdse verificatie, of clientverificatie, kan de Application Gateway de client die verzoeken verstuurt, verifiëren. Normaal gesproken wordt alleen de client geverifieerd bij application gateway; met wederzijdse verificatie kunnen zowel de client als de Application Gateway elkaar verifiëren.

Note

We raden u aan TLS 1.2 te gebruiken met wederzijdse verificatie, omdat TLS 1.2 in de toekomst wordt verplicht.

Wederzijdse verificatie

Application Gateway ondersteunt wederzijdse verificatie op basis van certificaten, waar u een of meer vertrouwde ca-certificaten voor clients kunt uploaden naar de Application Gateway en de gateway dat certificaat gebruikt om de client te verifiëren die een aanvraag naar de gateway verzendt. Dankzij de toename van IoT-gebruiksvoorbeelden en verhoogde beveiligingsvereisten in verschillende branches biedt wederzijdse verificatie een manier om te beheren en te bepalen welke clients met uw Application Gateway kunnen communiceren.

Application Gateway biedt de volgende twee opties voor het valideren van clientcertificaten:

Wederzijdse TLS-passthrough-modus

In de wederzijdse TLS-passthroughmodus vraagt Application Gateway een clientcertificaat aan tijdens de TLS-handshake, maar beëindigt de verbinding niet als het certificaat ontbreekt of ongeldig is. De verbinding met de back-end wordt voortgezet, ongeacht de aanwezigheid of geldigheid van het certificaat. Als er een certificaat is opgegeven, kan Application Gateway het doorsturen naar de back-end, indien nodig door de toepassing. De back-endservice is verantwoordelijk voor het valideren van het clientcertificaat. Raadpleeg servervariabelen als u het doorsturen van certificaten wilt configureren. U hoeft geen CA-certificaat te uploaden wanneer het zich in de passthrough-modus bevindt. Als u passthrough wilt instellen, volgt u de stappen in Application Gateway configureren met wederzijdse verificatie met behulp van ARM-sjabloon.

Note

Deze functie wordt momenteel alleen ondersteund via azure Resource Manager-implementatie met API-versie 2025-03-01.

Wederzijdse TLS-strikte modus

In de wederzijdse strikte TLS-modus dwingt Application Gateway verificatie van clientcertificaten af tijdens de TLS-handshake door een geldig clientcertificaat te vereisen. Om dit in te schakelen, moet een vertrouwd client-CA-certificaat met een basis-CA en eventueel tussenliggende CA's worden geüpload als onderdeel van het SSL-profiel. Dit SSL-profiel wordt vervolgens gekoppeld aan een listener om wederzijdse verificatie af te dwingen.

Details over configureren van de strikte modus van wederzijdse TLS

Als u de strikte modus voor wederzijdse verificatie wilt configureren, moet een vertrouwd client-CA-certificaat worden geüpload als onderdeel van het clientverificatiegedeelte van een SSL-profiel. Het SSL-profiel moet vervolgens aan een listener worden gekoppeld om de configuratie van wederzijdse verificatie te voltooien. Er moet altijd een basis-CA-certificaat aanwezig zijn in het clientcertificaat dat u uploadt. U kunt ook een certificaatketen uploaden, maar de keten moet een basis-CA-certificaat bevatten naast zoveel tussenliggende CA-certificaten als u wilt. De maximale grootte van elk geüpload bestand moet 25 kB of minder zijn.

Als uw clientcertificaat bijvoorbeeld een basis-CA-certificaat, meerdere tussenliggende CA-certificaten en een basiscertificaat bevat, moet u ervoor zorgen dat het basis-CA-certificaat en alle tussenliggende CA-certificaten in één bestand naar Application Gateway worden geüpload. Zie voor meer informatie over het extraheren van een vertrouwd client-CA-certificaat hoe u vertrouwde client-CA-certificaten kunt extraheren.

Als u een certificaatketen uploadt met basis-CA- en tussenliggende CA-certificaten, moet de certificaatketen worden geüpload als een PEM- of CER-bestand naar de gateway.

Important

Zorg ervoor dat u de volledige ca-certificaatketen van de vertrouwde client uploadt naar de Application Gateway wanneer u wederzijdse verificatie gebruikt.

Elk SSL-profiel kan maximaal 100 ca-certificaatketens van vertrouwde clients ondersteunen. Eén Application Gateway kan in totaal 200 ca-certificaatketens van vertrouwde clients ondersteunen.

Note

  • Wederzijdse verificatie is alleen beschikbaar voor Standard_v2 en WAF_v2 SKU's.
  • De configuratie van wederzijdse verificatie voor TLS-protocollisteners (preview) is momenteel beschikbaar via REST API, PowerShell en CLI.

Certificaten die worden ondersteund voor wederzijdse verificatie met strikte TLS-modus

Application Gateway ondersteunt certificaten die zijn uitgegeven door zowel openbare als privé gevestigde certificeringsinstanties.

  • CA-certificaten die zijn uitgegeven door bekende certificeringsinstanties: tussenliggende en basiscertificaten worden vaak gevonden in vertrouwde certificaatarchieven en maken vertrouwde verbindingen mogelijk met weinig tot geen configuratie meer op het apparaat.
  • CA-certificaten die zijn uitgegeven door gevestigde certificeringsinstanties van de organisatie: deze certificaten worden doorgaans privé uitgegeven via uw organisatie en worden niet vertrouwd door andere entiteiten. Tussenliggende en basiscertificaten moeten worden geïmporteerd in de vertrouwde certificaatarchieven voor cliënten om ketenvertrouwen tot stand te brengen.

Note

Wanneer u clientcertificaten van goed gevestigde certificeringsinstanties uitgeeft, kunt u overwegen om met de certificeringsinstantie te werken om te zien of een tussenliggend certificaat kan worden uitgegeven voor uw organisatie om onbedoelde verificatie van clientcertificaten tussen organisaties te voorkomen.

Aanvullende validatie van clientverificatie voor wederzijdse TLS-strikte modus

DN van clientcertificaat verifiëren

U hebt de mogelijkheid om de directe uitgever van het clientcertificaat te controleren en alleen de Application Gateway toe te staan die verlener te vertrouwen. Deze optie is standaard uitgeschakeld, maar u kunt dit inschakelen via portal, PowerShell of Azure CLI.

Als u ervoor kiest om application gateway in te schakelen om de onmiddellijke uitgever van het clientcertificaat te controleren, kunt u als volgt bepalen welke DN van de certificaatverlener van het clientcertificaat wordt geëxtraheerd uit de geüploade certificaten.

  • Scenario 1: Certificaatketen omvat: basiscertificaat - tussencertificaat - leaf-certificaat
    • Application Gateway zal de onderwerpnaam van het tussenliggende certificaat extraheren als de DN van de uitgever van het clientcertificaat en zal deze verifiëren.
  • Scenario 2: Certificaatketen omvat: basiscertificaat - tussenliggend1 certificaat - tussenliggend2-certificaat - leaf-certificaat
    • De onderwerpnaam van het Intermediate2-certificaat is wat als de DN van de uitgever van het cliëntcertificaat wordt geëxtraheerd en hiertegen wordt gecontroleerd.
  • Scenario 3: Certificaatketen omvat: basiscertificaat - leaf-certificaat
    • De onderwerpnaam van het basiscertificaat wordt geëxtraheerd als DN van clientcertificaatverlener.
  • Scenario 4: Meerdere certificaatketens van dezelfde lengte in hetzelfde bestand. Keten 1 omvat: basiscertificaat - tussenliggend1 certificaat - certificaat van het blad. Keten 2 omvat: basiscertificaat - tussenliggend certificaat 2 - bladcertificaat.
    • De onderwerpnaam van het Intermediate1-certificaat wordt geëxtraheerd als de DN van de uitgever van het clientcertificaat.
  • Scenario 5: Meerdere certificaatketens van verschillende lengten in hetzelfde bestand. Keten 1 omvat: basiscertificaat - tussenliggend1 certificaat - certificaat van het blad. Chain 2 bevat een rootcertificaat - tussenliggend2-certificaat - tussenliggend3-certificaat - eindcertificaat.
    • De onderwerpnaam van het Intermediate3-certificaat wordt geëxtraheerd als de uitgevende DN van het clientcertificaat.

Important

U wordt aangeraden slechts één certificaatketen per bestand te uploaden. Dit is vooral belangrijk als u het controleren van het DN van het clientcertificaat inschakelt. Door meerdere certificaatketens in één bestand te uploaden, eindigt u in scenario vier of vijf en kan er later problemen optreden wanneer het gepresenteerde clientcertificaat niet overeenkomt met de DN Application Gateway van de clientcertificaatverlener die is geëxtraheerd uit de ketens.

Zie voor meer informatie over het extraheren van ca-certificaatketens van vertrouwde clients hoe u ca-certificaatketens voor vertrouwde clients kunt extraheren.

Servervariabelen

Met wederzijdse TLS-verificatie zijn er extra servervariabelen die u kunt gebruiken om informatie over het clientcertificaat door te geven aan de back-endservers achter de Application Gateway. Bekijk servervariabelen voor meer informatie over welke servervariabelen beschikbaar zijn en hoe u deze kunt gebruiken.

Certificaatintrekking

Wanneer een client een verbinding initieert met een Toepassingsgateway die is geconfigureerd met wederzijdse TLS-verificatie, kan niet alleen de certificaatketen en de DN-naam van de verlener worden gevalideerd, maar kan de intrekkingsstatus van het clientcertificaat worden gecontroleerd met OCSP (Online Certificate Status Protocol). Tijdens de validatie wordt het certificaat dat door de client wordt gepresenteerd, opgezoekd via de gedefinieerde OCSP-responder die is gedefinieerd in de AIA-extensie (Authority Information Access). Als het clientcertificaat is ingetrokken, reageert de toepassingsgateway met een HTTP 400-statuscode en -reden op de client. Als het certificaat geldig is, wordt de aanvraag nog steeds verwerkt door de toepassingsgateway en doorgestuurd naar de gedefinieerde back-endpool.

Het intrekken van clientcertificaten kan worden ingeschakeld via REST API, ARM-sjabloon, Bicep, CLI of PowerShell.

Als u clientintrekkingscontrole wilt configureren voor een bestaande toepassingsgateway via Azure PowerShell, kunt u naar de volgende opdrachten verwijzen:

# Get Application Gateway configuration
$AppGw = Get-AzApplicationGateway -Name "ApplicationGateway01" -ResourceGroupName "ResourceGroup01"

# Create new SSL Profile
$profile  = Get-AzApplicationGatewaySslProfile -Name "SslProfile01" -ApplicationGateway $AppGw

# Verify Client Cert Issuer DN and enable Client Revocation Check
Set-AzApplicationGatewayClientAuthConfiguration -SslProfile $profile -VerifyClientCertIssuerDN -VerifyClientRevocation OCSP

# Update Application Gateway
Set-AzApplicationGateway -ApplicationGateway $AppGw

Hier vindt u een lijst met alle Azure PowerShell-verwijzingen voor clientverificatieconfiguratie in Application Gateway:

Om te controleren of de ocsp-intrekkingsstatus is geëvalueerd voor de clientaanvraag, bevatten toegangslogboeken een eigenschap met de naam sslClientVerify, met de status van het OCSP-antwoord.

Het is van cruciaal belang dat de OCSP-responder maximaal beschikbaar is en dat de netwerkverbinding tussen Application Gateway en de responder mogelijk is. In het geval dat Application Gateway niet in staat is de FQDN (Fully Qualified Domain Name) van de gedefinieerde responder op te lossen of als de netwerkverbinding naar/van de responder wordt geblokkeerd, faalt de controle van de certificaatintrekkingsstatus en retourneert Application Gateway een HTTP-antwoord van 400 naar de aanvragende client.

Note

OCSP-controles worden gevalideerd via lokale cache op basis van de volgendeUpdate-tijd die is gedefinieerd door een eerder OCSP-antwoord. Als de OCSP-cache niet is ingevuld vanuit een vorige aanvraag, kan het eerste antwoord mislukken. Wanneer de client opnieuw wordt geprobeerd, moet het antwoord worden gevonden in de cache en wordt de aanvraag verwerkt zoals verwacht.

Notes

  • Intrekkingscontrole via CRL wordt niet ondersteund
  • Clientintrekkingscontrole is geïntroduceerd in API-versie 2022-05-01

Volgende stappen

Nadat u meer hebt geleerd over wederzijdse verificatie, gaat u naar Application Gateway configureren met wederzijdse verificatie in PowerShell om een Application Gateway te maken met behulp van wederzijdse verificatie.

  • Last updated on