Share via

Übersicht über die gegenseitige Authentifizierung in Application Gateway

  • Artikel

Gegenseitige Authentifizierung oder Clientauthentifizierung ermöglicht es dem Application Gateway, die vom Client gesendeten Anforderungen zu authentifizieren. In der Regel authentifiziert nur der Client das Application Gateway. Bei der gegenseitigen Authentifizierung können sowohl der Client als auch das Application Gateway einander authentifizieren.

Hinweis

Wir empfehlen Ihnen die Nutzung von TLS 1.2 mit gegenseitiger Authentifizierung, da TLS 1.2 in Zukunft vorgeschrieben sein wird.

Gegenseitige Authentifizierung

Application Gateway unterstützt die zertifikatbasierte gegenseitige Authentifizierung, bei der Sie ein oder mehrere vertrauenswürdige Client-ZS-Zertifikate in das Application Gateway hochladen können. Das Gateway verwendet dieses Zertifikat zum Authentifizieren des Clients, der eine Anforderung an das Gateway sendet. Angesichts des vermehrten Einsatz des IoT und erweiterter Sicherheitsanforderungen in allen Branchen bietet die gegenseitige Authentifizierung Ihnen die Möglichkeit, zu verwalten und zu steuern, welche Clients mit ihrer Application Gateway kommunizieren können.

Zum Konfigurieren der gegenseitigen Authentifizierung muss ein vertrauenswürdiges Client-ZS-Zertifikat als Teil der Clientauthentifizierung eines SSL-Profils hochgeladen werden. Das SSL-Profil muss dann einem Listener zugeordnet werden, um die Konfiguration der gegenseitigen Authentifizierung abzuschließen. Das Clientzertifikat, das Sie hochladen, muss immer ein Stammzertifikat einer Zertifizierungsstelle (ZS) enthalten. Sie können auch eine Zertifikatkette hochladen, die beliebig viele ZS-Zwischenzertifikate enthalten kann. Sie muss aber auch ein ZS-Stammzertifikat enthalten. Die maximale Größe jeder hochgeladenen Datei darf maximal 25 KB betragen.

Wenn das Clientzertifikat beispielsweise ein ZS-Stammzertifikat, mehrere ZS-Zwischenzertifikate und ein Blattzertifikat enthält, sollten Sie darauf achten, dass das ZS-Stammzertifikat und das ZS-Zwischenzertifikat in einer Datei in Application Gateway hochgeladen werden. Weitere Informationen zum Extrahieren von vertrauenswürdigen ZS-Clientzertifikaten finden Sie unter Extrahieren von vertrauenswürdigen ZS-Clientzertifikaten.

Wenn Sie eine Zertifikatkette mit ZS-Stamm- und ZS-Zwischenzertifikaten hochladen, muss die Zertifikatkette als PEM- oder CER-Datei in das Gateway hochgeladen werden.

Wichtig

Stellen Sie sicher, dass Sie bei der gegenseitigen Authentifizierung die gesamte vertrauenswürdige ZS-Clientzertifikatkette in die Application Gateway hochladen.

Jedes SSL-Profil kann bis zu 100 Zertifikatketten für vertrauenswürdige Clientzertifizierungsstellen unterstützen. Ein einzelnes Application Gateway kann insgesamt 200 vertrauenswürdige Client-Zertifizierungsstellen-Zertifikatketten unterstützen.

Hinweis

  • Die gegenseitige Authentifizierung ist nur für Standard_v2-und WAF_v2-SKUs verfügbar.
  • Die Konfiguration der gegenseitigen Authentifizierung für TLS-Protokolllistener (Vorschau) ist derzeit über REST-API, PowerShell und CLI verfügbar. Der Azure Portal-Support wird in Kürze verfügbar sein.

Für die gegenseitige Authentifizierung unterstützte Zertifikate

Application Gateway unterstützt sowohl von öffentlichen als auch von privaten Zertifizierungsstellen ausgestellte Zertifikate.

  • Von bekannten Zertifizierungsstellen ausgestellte ZS-Zertifikate: Zwischen- und Stammzertifikate befinden sich häufig in vertrauenswürdigen Zertifikatspeichern und ermöglichen vertrauenswürdige Verbindungen, bei denen auf dem Gerät wenige oder keine Konfigurationen vorgenommen werden müssen.
  • Von Zertifizierungsstellen der Organisation ausgestellte ZS-Zertifikate: Diese Zertifikate werden in der Regel privat über Ihre Organisation ausgestellt und von anderen Entitäten nicht als vertrauenswürdig eingestuft. Zwischen- und Stammzertifikate müssen in vertrauenswürdige Zertifikatspeicher importiert werden, damit Clients eine Vertrauenskette einrichten können.

Hinweis

Wenn Sie Clientzertifikate von etablierten Zertifizierungsstellen ausstellen, sollten Sie mit der Zertifizierungsstelle abstimmen, ob ein Zwischenzertifikat für Ihre Organisation ausgestellt werden kann, um eine unbeabsichtigte organisationsübergreifende Clientzertifikatauthentifizierung zu verhindern.

Zusätzliche Überprüfung der Clientauthentifizierung

Clientzertifikat-DN überprüfen

Sie können den unmittelbaren Aussteller des Clientzertifikats überprüfen und nur dem Application Gateway gestatten, diesem Aussteller zu vertrauen. Diese Option ist standardmäßig deaktiviert, aber Sie können sie über das Portal, PowerShell oder die Azure CLI aktivieren.

Wenn Sie die Application Gateway den sofortigen Aussteller des Clientzertifikats überprüfen lassen möchten, können Sie anhand dieser Anleitung ermitteln, wie der Aussteller-DN des Clientzertifikats aus den hochgeladenen Zertifikaten extrahiert wird.

  • Szenario 1: Die Zertifikatkette umfasst: Stammzertifikat - Zwischenzertifikat - Blattzertifikat
    • Application Gateway wird den Namen des Antragstellers desZwischenzertifikats als Aussteller-DN des Clientzertifikats extrahieren und dahingehend überprüfen.
  • Szenario 2: Die Zertifikatkette umfasst: Stammzertifikat - Zwischenzertifikat1 - Zwischenzertifikat2 - Blattzertifikat
    • Der Name des Antragstellers desZwischenzertifikat2s wird als Aussteller-DN des Clientzertifikats extrahiert und dahingehend überprüft.
  • Szenario 3: Die Zertifikatkette umfasst: Stammzertifikat - Blattzertifikat
    • Der Antragstellername des Stammzertifikats wird extrahiert und als Aussteller-DN des Client Zertifikats verwendet.
  • Szenario 4: Mehrere Zertifikatketten derselben Länge in derselben Datei. Kette 1 umfasst: Stammzertifikat - Zwischenzertifikat1 - Blattzertifikat Kette 2 umfasst: Stammzertifikat - Zwischenzertifikat2 - Blattzertifikat.
    • Der Antragstellername des Zwischenzertifikats1 wird als Aussteller-DN des Client Zertifikats extrahiert.
  • Szenario 5: Mehrere Zertifikatketten mit unterschiedlichen Längen in derselben Datei. Kette 1 umfasst: Stammzertifikat - Zwischenzertifikat1 - Blattzertifikat Kette 2 umfasst: Stammzertifikat - Zwischenzertifikat2 - Zwischenzertifikat3 - Blattzertifikat
    • Der Antragstellername des Zwischenzertifikats3 wird extrahiert und als Aussteller-DN des Client Zertifikats verwendet.

Wichtig

Es wird empfohlen, nur eine Zertifikatkette pro Datei hochzuladen. Dies ist besonders wichtig, wenn Sie das Überprüfen von Client Zertifikat-DN aktivieren. Wenn Sie mehrere Zertifikatketten in einer Datei hochladen, werden Sie auf Szenario 4 oder 5 treffen und haben möglicherweise später Probleme, wenn das Clientzertifikat nicht mit der Aussteller-DN des Clientzertifikats übereinstimmt, das von Application Gateway aus den Ketten extrahiert wurde.

Weitere Informationen zum Extrahieren von vertrauenswürdigen ZS-Client-Zertifikatketten für die Nutzung finden Sie unter Exportieren von vertrauenswürdigen ZS-Client-Zertifikatketten.

Servervariablen

Bei der gegenseitigen TLS-Authentifizierung gibt es zusätzliche Servervariablen, mit denen Sie Informationen über das Clientzertifikat an die Back-End-Server hinter dem Application Gateway übergeben können. Weitere Informationen darüber, welche Servervariablen verfügbar sind und wie sie verwendet werden, finden Sie unter Servervariablen.

Zertifikatsperrung

Wenn ein Client eine Verbindung mit einem Application Gateway initiiert, das mit gegenseitiger TLS-Authentifizierung konfiguriert ist, können nicht nur die Zertifikatkette und der Distinguished Name (DN) des Ausstellers überprüft werden, sondern auch der Sperrstatus des Clientzertifikats kann mit OCSP (Online Certificate Status Protocol) überprüft werden. Während der Überprüfung wird das vom Client vorgelegte Zertifikat über den definierten OCSP-Antwortdienst nachgeschlagen, der in der AIA-Erweiterung (Authority Information Access) definiert ist. Wenn das Clientzertifikat widerrufen wurde, antwortet das Anwendungsgateway dem Client mit einem HTTP 400-Statuscode und einem Grund. Wenn das Zertifikat gültig ist, wird die Anforderung weiterhin vom Anwendungsgateway verarbeitet und an den definierten Back-End-Pool weitergeleitet.

Die Sperrung von Clientzertifikaten kann über die REST-API sowie mittels ARM, Bicep, CLI oder PowerShell aktiviert werden.

Um die Überprüfung des Clientwiderrufs für ein vorhandenes Application Gateway über Azure PowerShell zu konfigurieren, kann auf die folgenden Befehle verwiesen werden:

# 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

Eine Liste aller Azure PowerShell-Referenzen für die Clientauthentifizierungskonfiguration auf Application Gateway finden Sie hier:

Um zu überprüfen, ob der OCSP-Sperrstatus für die Clientanforderung ausgewertet wurde, enthalten Zugriffsprotokolle eine Eigenschaft namens „sslClientVerify“ mit dem Status der OCSP-Antwort.

Es ist von kritischer Bedeutung, dass der OCSP-Antwortdienst hochverfügbar ist und dass Netzwerkkonnektivität zwischen Application Gateway und dem Antwortdienst möglich ist. Falls Application Gateway nicht in der Lage ist, den vollqualifizierten Domänennamen (FQDN) des definierten Antwortdiensts aufzulösen, oder wenn die Netzwerkkonnektivität vom/zum Antwortdienst blockiert ist, schlägt der Zertifikatsperrstatus fehl, und Application Gateway gibt eine HTTP 400-Antwort an den anfordernden Client zurück.

Hinweis: OCSP-Überprüfungen werden über den lokalen Cache auf Grundlage der von einer vorherigen OCSP-Antwort definierten nextUpdate-Zeit überprüft. Wenn der OCSP-Cache nicht aus einer vorherigen Anforderung aufgefüllt wurde, schlägt die erste Antwort möglicherweise fehl. Beim Wiederholungsversuch des Clients sollte die Antwort im Cache gefunden werden, worauf die Anforderung wie erwartet verarbeitet wird.

Hinweise

  • Die Überprüfung des Widerrufs über eine Zertifikatssperrliste wird nicht unterstützt.
  • Die Überprüfung des Clientwiderrufs wurde in API-Version 2022-05-01 eingeführt.

Nächste Schritte

Nachdem Sie sich mit der gegenseitigen Authentifizierung vertraut gemacht haben, wechseln Sie zuKonfigurieren der Anwendungs-Gateway mit gegenseitiger Authentifizierung in PowerShell, um eine Anwendungs-Gateway mithilfe der gegenseitigen Authentifizierung zu erstellen.