Das Back-End-Serverzertifikat ist nicht in der Liste zugelassener Zertifikate für ein Anwendungsgateway unter Verwendung eines internen Lastenausgleichs mit einer App Service-Umgebung enthalten

In diesem Artikel wird die Behebung des folgenden Issues behandelt: Ein Zertifikat ist nicht in der Whitelist enthalten, wenn Sie ein Anwendungsgateway verwenden, während Sie einen internen Lastenausgleich (ILB) und eine App Service-Umgebung (ASE) am Back-End erstellen und dabei End-to-End-TLS in Azure verwenden.

Problembeschreibung

Wenn Sie ein Anwendungsgateway unter Verwendung eines ILB mit einer ASE am Back-End erstellen, kann es vorkommen, dass der Back-End-Server fehlerhaft wird. Dieses Problem tritt auf, wenn das Authentifizierungszertifikat des Anwendungsgateways nicht dem Zertifikat entspricht, das auf dem Back-End-Server konfiguriert ist. Beispielszenario:

Konfiguration des Anwendungsgateways:

  • Listener: Mehrere Standorte
  • Port: 443
  • Hostname: test.appgwtestase.com
  • SSL-Zertifikat: CN=test.appgwtestase.com
  • Back-End-Pool: -IP-Adresse oder FQDN
  • IP-Adresse: 10.1.5.11
  • HTTP-Einstellungen: HTTPS
  • Port: 443
  • Benutzerdefinierte Überprüfung: Hostname (test.appgwtestase.com)
  • Authentifizierungszertifikat: CER-Datei von „test.appgwtestase.com“
  • Back-End-Integrität: Fehlerhaft - Das Back-End-Server-Zertifikat ist in der Liste für Application Gateway nicht zugelassen.

ASE-Konfiguration:

  • ILB-IP-Adresse: 10.1.5.11
  • Domänenname: appgwtestase.com
  • App Service: test.appgwtestase.com
  • SSL-Bindung: SNI-basiertes SSL (CN=test.appgwtestase.com)

Wenn Sie auf das Anwendungsgateway zugreifen, wird die folgende Fehlermeldung angezeigt, da der Back-End-Server fehlerhaft ist:

502 - Webserver hat als Gateway oder Proxyserver eine ungültige Antwort erhalten.

Lösung

Wenn Sie für den Zugriff auf eine HTTPS-Website keinen Hostnamen verwenden, gibt der Back-End-Server das konfigurierte Zertifikat für die Standardwebsite zurück, falls SNI deaktiviert ist. Bei einem ILB mit ASE basiert das Standardzertifikat auf dem ILB-Zertifikat. Sind keine konfigurierten Zertifikate für den ILB vorhanden, basiert das Zertifikat auf dem ASE-App-Zertifikat.

Wenn Sie für den ILB-Zugriff einen vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) verwenden, gibt der Back-End-Server das richtige Zertifikat zurück, das in den HTTP-Einstellungen hochgeladen wird. Wenn dies nicht der Fall ist, haben Sie folgende Optionen:

  • Verwenden Sie den FQDN im Back-End-Pool des Anwendungsgateways, um auf die IP-Adresse des ILB zu verweisen. Diese Option funktioniert nur, wenn Sie eine private DNS-Zone oder ein benutzerdefiniertes DNS konfiguriert haben. Andernfalls müssen Sie einen A-Eintrag für ein öffentliches DNS erstellen.

  • Verwenden Sie das hochgeladene Zertifikat für den ILB oder das Standardzertifikat (ILB-Zertifikat) in den HTTP-Einstellungen. Das Anwendungsgateway ruft das Zertifikat ab, wenn es auf die ILB-IP-Adresse für den Test zugreift.

  • Verwenden Sie ein Platzhalterzertifikat für den ILB und den Back-End-Server, sodass das Zertifikat für alle Websites einheitlich ist. Diese Lösung ist jedoch nur bei Unterdomänen möglich und nicht, wenn jede der Websites unterschiedliche Hostnamen erfordert.

  • Deaktivieren Sie die Option Verwendung für den App-Dienst für das Anwendungs-Gateway, falls Sie die IP-Adresse des ILB verwenden.

Zur Vereinfachung können Sie das ILB-Zertifikat in den HTTP-Einstellungen hochladen, damit der Testpfad funktioniert. (Dieser Schritt betrifft lediglich die Aufnahme in die Positivliste. Er wird nicht für die TLS-Kommunikation verwendet.) Sie können das ILB-Zertifikat abrufen, indem Sie in Ihrem Browser über HTTPS mit der IP-Adresse des ILB auf den ILB zugreifen, das TLS/SSL-Zertifikat in ein Base64-codiertes CER-Format exportieren und das Zertifikat anschließend in den entsprechenden HTTP-Einstellungen hochladen.

Sie brauchen Hilfe? Support kontaktieren

Wenden Sie sich an den Support, falls Sie weitere Hilfe benötigen, um das Problem schnell beheben zu lassen.