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.