Übersicht über die gegenseitige Authentifizierung in Application Gateway

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.

Gegenseitige Authentifizierung

Das Anwendungsgateway unterstützt die zertifikatbasierte gegenseitige Authentifizierung, bei der Sie ein vertrauenswürdiges Client-Zertifizierungsstellenzertifikat(n) in das Anwendungsgateway hochladen können, und das Gateway verwendet dieses Zertifikat, um den Client zu authentifizieren, 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.

Das Anwendungsgateway bietet die folgenden beiden Optionen zum Überprüfen von Clientzertifikaten:

Wechselseitiger TLS-Passthroughmodus

Im wechselseitigen TLS-Passthroughmodus fordert Anwendungsgateway ein Clientzertifikat während des TLS-Handshake an, beendet die Verbindung jedoch nicht, wenn das Zertifikat fehlt oder ungültig ist. Die Verbindung mit dem Back-End wird unabhängig von der Anwesenheit oder Gültigkeit des Zertifikats fortgesetzt. Wenn ein Zertifikat bereitgestellt wird, kann es vom Anwendungsgateway bei Bedarf an das Back-End weitergeleitet werden. Der Back-End-Dienst ist für die Überprüfung des Clientzertifikats verantwortlich. Verweisen Sie auf Servervariablen, wenn Sie die Zertifikatweiterleitung konfigurieren möchten. Es ist nicht erforderlich, ein Zertifizierungsstellenzertifikat hochzuladen, wenn es sich im Passthrough-Modus befindet. Führen Sie zum Einrichten der Passthrough die Schritte unter Konfigurieren des Anwendungsgateways mit gegenseitiger Authentifizierung mithilfe der ARM-Vorlage aus.

Strenger Modus für wechselseitiges TLS

Im gegenseitigen TLS-strikten Modus erzwingt das Anwendungsgateway die Clientzertifikatauthentifizierung, indem während des TLS-Handshakes ein gültiges Clientzertifikat erforderlich ist. Um dies zu aktivieren, muss ein Zertifikat der vertrauenswürdigen Client-CA, das eine Stamm-CA und optional Zwischen-CAs enthält, als Teil des SSL-Profils hochgeladen werden. Dieses SSL-Profil wird dann einem Listener zugeordnet, um die gegenseitige Authentifizierung zu erzwingen.

Details zur Konfiguration des strikten Mutual-TLS-Modus

Um den strikten Modus für die gegenseitige Authentifizierung zu konfigurieren, muss ein zertifikat der vertrauenswürdigen Clientzertifizierungsstelle als Teil des Clientauthentifizierungsteils 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.

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.

Zertifikate, die für die gegenseitige TLS Strict Mode-Authentifizierung unterstützt werden

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

• CA-Zertifikate, die von vertrauenswürdigen Zertifizierungsstellen ausgestellt wurden: Zwischen- und Stammzertifikate werden häufig in vertrauenswürdigen Zertifikatspeichern gefunden und ermöglichen sichere Verbindungen ohne oder mit minimaler weiterer Konfiguration auf dem Gerät.
• 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.

Zusätzliche Clientauthentifizierungsüberprüfung für den strikten Mutual-TLS-Modus

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 ist als Aussteller-DN des Clientzertifikats extrahiert und dahingehend überprüft.
• Szenario 3: Die Zertifikatkette umfasst: Stammzertifikat - Blattzertifikat
  • Der Subjektname des Stammzertifikats wird als DN des Clientzertifikatausstellers extrahiert.
• 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 ist 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 ist extrahiert und als Aussteller-DN des Client Zertifikats verwendet.

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.

Zertifikatswiderruf

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. Falls das Clientzertifikat widerrufen wurde, antwortet das Anwendungsgateway dem Client mit einem HTTP 400-Statuscode und gibt einen Grund an. Wenn das Zertifikat gültig ist, wird die Anforderung weiterhin vom Anwendungsgateway verarbeitet und an den definierten Back-End-Pool weitergeleitet.

Clientzertifikatsperrung kann über REST-API, ARM-Vorlage, Bicep, CLI oder PowerShell aktiviert 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

# Update existing gateway's SSL Profile
az network application-gateway update -n ApplicationGateway01 -g ResourceGroup01 --ssl-profiles [0].client-auth-configuration.verify-client-revocation=OCSP

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 wichtig, dass der OCSP-Responder hoch verfügbar ist und die Netzwerkkonnektivität zwischen Dem Anwendungsgateway und dem Responder 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.

Notizen

• Die Sperrüberprüfung über CRL 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.