Overzicht van wederzijdse verificatie met Application Gateway

Met wederzijdse verificatie of clientverificatie kan Application Gateway de verzendende aanvragen van de client verifiëren. Normaal gesproken verifieert alleen de client de Application Gateway. Met wederzijdse verificatie kunnen zowel de client als Application Gateway elkaar verifiëren.

Opmerking

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

Wederzijdse verificatie

Application Gateway ondersteunt wederzijdse verificatie op basis van certificaten. U kunt vertrouwde client-CA-certificaten uploaden naar Application Gateway en de gateway gebruikt deze certificaten om clients te verifiëren die aanvragen verzenden. Met 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 passthroughmodus voor wederzijdse TLS (mTLS) 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.

Voordelen van de mTLS-passthrough-modus

de mTLS-passthrough-modus biedt de volgende voordelen:

  • Vereenvoudigde gatewayconfiguratie: er is geen upload van CA-certificaten vereist op gatewayniveau.
  • Flexibele verificatie: ondersteunt scenario's voor gemengd verkeer waarbij sommige clients certificaten gebruiken en andere gebruikmaken van verificatie op basis van tokens.
  • Afdwingen van backendbeleid: Hiermee kan uw backendtoepassing aangepaste logica voor certificaatvalidatie en beleidsregels implementeren.
  • Verminderde overhead van de gateway: hiermee wordt certificaatvalidatie naar de back-end offload, waardoor de verwerking op de gateway wordt verminderd.
  • Geleidelijke migratieondersteuning: maakt gefaseerde implementatie van mTLS mogelijk zonder bestaande verkeerspatronen te verstoren.

Als u clientcertificaten naar de back-end wilt doorsturen, configureert u servervariabelen. Zie Servervariabelen voor meer informatie.

Configureren van de mTLS-passthroughmodus

U kunt de mTLS-passthroughmodus configureren met behulp van de Azure-portal of ARM-sjablonen.

De mTLS-passthrough-modus configureren in de Azure-portal:

  1. Navigeer naar uw Application Gateway-resource.

  2. Selecteer onder InstellingenSSL-profielen.

  3. Selecteer + Toevoegen om een nieuw SSL-profiel te maken.

  4. Voer een naam in voor uw SSL-profiel.

  5. Selecteer Passthrough op het tabblad Clientverificatie.

    In de Passthrough-modus is het clientcertificaat optioneel. De back-endserver is verantwoordelijk voor clientverificatie.

    Schermafbeelding met het dialoogvenster SSL-profiel maken in Azure portal met Passthrough geselecteerd voor clientverificatiemethode.

  6. Configureer indien nodig SSL-beleidsinstellingen.

  7. Selecteer Toevoegen om het SSL-profiel te maken.

  8. Koppel het SSL-profiel aan uw HTTPS-listener.

Opmerking

PowerShell- en CLI-ondersteuning voor passthrough-configuratie zijn momenteel niet beschikbaar.

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. Als u de strikte modus wilt inschakelen, uploadt u een vertrouwd client-CA-certificaat met een basis-CA en eventueel tussenliggende CA's als onderdeel van het SSL-profiel. Koppel dit SSL-profiel aan een listener om wederzijdse verificatie af te dwingen.

Wederzijdse TLS-strikte modus configureren

Als u de strikte modus voor wederzijdse verificatie wilt configureren, uploadt u een vertrouwd client-CA-certificaat als onderdeel van het clientverificatiegedeelte van een SSL-profiel. Koppel vervolgens het SSL-profiel aan een listener om de configuratie te voltooien. Het clientcertificaat dat u uploadt, moet altijd een basis-CA-certificaat bevatten. U kunt een certificaatketen uploaden, maar de keten moet naast tussenliggende CA-certificaten een basis-CA-certificaat bevatten. 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, uploadt u het basis-CA-certificaat en alle tussenliggende CA-certificaten in één bestand naar Application Gateway. Zie Vertrouwde client-CA-certificaten extraheren voor meer informatie over het extraheren van een vertrouwd client-CA-certificaat.

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

Belangrijk

Upload de volledige ca-certificaatketen van de vertrouwde client naar 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.

Opmerking

  • Wederzijdse verificatie is alleen beschikbaar voor Standard_v2 en WAF_v2 SKU's.
  • Configuratie van wederzijdse verificatie voor TLS-protocollisteners 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 extra configuratie op het apparaat.
  • CA-certificaten die zijn uitgegeven door door de organisatie gevestigde certificeringsinstanties: deze certificaten worden doorgaans privé uitgegeven via uw organisatie en worden niet vertrouwd door andere entiteiten. Importeer tussenliggende en basiscertificaten in vertrouwde certificaatarchieven voor clients om ketenvertrouwen tot stand te brengen.

Opmerking

Wanneer u clientcertificaten van gevestigde certificeringsinstanties uitgeeft, kunt u samenwerken met de certificeringsinstantie om te zien of er een tussencertificaat kan worden uitgegeven voor uw organisatie. Met deze methode voorkomt u onbedoeld verificatie van clientcertificaten tussen organisaties.

Validatie van clientverificatie voor wederzijdse TLS-strikte modus

DN van clientcertificaat verifiëren

U kunt de directe uitgever van het clientcertificaat controleren en alleen toestaan dat Application Gateway die verlener vertrouwt. Deze optie is standaard uitgeschakeld, maar u kunt deze inschakelen via de portal, PowerShell of Azure CLI.

Als u Application Gateway inschakelt om de onmiddellijke uitgever van het clientcertificaat te controleren, beschrijven de volgende scenario's hoe de DN van de certificaatverlener van het clientcertificaat wordt geëxtraheerd uit de geüploade certificaten:

  • Scenario 1: Certificaatketen omvat basiscertificaat, tussenliggend certificaat en leaf-certificaat.
    • De onderwerpnaam van het tussenliggende certificaat wordt geëxtraheerd als de DN van de uitgever van het clientcertificaat.
  • Scenario 2: Certificaatketen omvat rootcertificaat, tussenliggend1 certificaat, tussenliggend2 certificaat en eindcertificaat.
    • De onderwerpnaam van het tussenliggende2-certificaat wordt geëxtraheerd als de DN van de certificaatverlener van het clientcertificaat.
  • Scenario 3: Certificaatketen omvat basiscertificaat en bladcertificaat.
    • De onderwerpnaam van het basiscertificaat wordt geëxtraheerd als de DN van de certificaatverlener van het clientcertificaat.
  • Scenario 4: Meerdere certificaatketens van dezelfde lengte in hetzelfde bestand. Chain 1 bevat een rootcertificaat, een tussenliggende certificaat en een eindcertificaat. Chain 2 omvat basiscertificaat, tussenliggend2-certificaat en leafcertificaat.
    • De onderwerpnaam van het tussenliggende1-certificaat wordt geëxtraheerd als de DN van de certificaatverlener van het clientcertificaat.
  • Scenario 5: Meerdere certificaatketens van verschillende lengten in hetzelfde bestand. Chain 1 bevat een rootcertificaat, een intermediair1-certificaat en een eindcertificaat. Chain 2 omvat basiscertificaat, tussenliggend2-certificaat, tussenliggend3-certificaat en leafcertificaat.
    • De onderwerpnaam van het intermediate3-certificaat wordt geëxtraheerd als de DN van de uitgevende instantie van het clientcertificaat.

Belangrijk

U wordt aangeraden slechts één certificaatketen per bestand te uploaden. Deze aanbeveling is vooral belangrijk als u de DN-optie voor het controleren van het clientcertificaat inschakelt. Het uploaden van meerdere certificaatketens in één bestand resulteert in scenario vier of vijf, wat later problemen kan veroorzaken wanneer het gepresenteerde clientcertificaat niet overeenkomt met de DN van de clientcertificaatverlener die Application Gateway uit de ketens heeft geëxtraheerd.

Voor meer informatie over het extraheren van certificaatketens van vertrouwde client-CA's, zie Certificaatketens van vertrouwde client-CA's extraheren.

Servervariabelen

Met wederzijdse TLS-verificatie kunt u aanvullende servervariabelen gebruiken om informatie over het clientcertificaat door te geven aan de back-endservers achter Application Gateway. Zie 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, kunnen de certificaatketen en de onderscheiden naam van de uitgever worden gevalideerd. Daarnaast 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 in de extensie Authority Information Access (AIA). Als het clientcertificaat is ingetrokken, reageert Application Gateway met een HTTP 400-statuscode en -reden op de client. Als het certificaat geldig is, wordt de aanvraag nog steeds verwerkt door Application Gateway en doorgestuurd naar de gedefinieerde back-endpool.

U kunt het intrekken van clientcertificaten inschakelen via REST API, ARM-sjabloon, Bicep, CLI of PowerShell.

Gebruik de volgende opdrachten om clientintrekkingscontrole op een bestaande Application Gateway te configureren met behulp van Azure PowerShell:

# 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

Zie de volgende artikelen voor 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 die de status van het OCSP-antwoord weergeeft.

Het is van cruciaal belang dat de OCSP-responder maximaal beschikbaar is en dat de netwerkverbinding tussen Application Gateway en de responder mogelijk is. Als Application Gateway de FQDN (Fully Qualified Domain Name) van de gedefinieerde responder niet kan omzetten of als de netwerkverbinding met of van de responder is geblokkeerd, mislukt de certificaatintrekkingsstatus en retourneert Application Gateway een HTTP-antwoord van 400 naar de aanvragende client.

Opmerking

OCSP-controles worden gevalideerd via lokale cache op basis van de nextUpdate 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

  • Controle op intrekking via CRL wordt niet ondersteund.
  • Clientintrekkingscontrole is geïntroduceerd in API-versie 2022-05-01.

Verwante inhoud

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

  • Last updated on