Behandeln von Problemen mit der Back-End-Integrität in Application Gateway

Artikel
09/30/2024

Übersicht

Standardmäßig testet Application Gateway Back-End-Server, um deren Integritätsstatus zu überprüfen und zu prüfen, ob sie bereit sind, Anforderungen zu verarbeiten. Benutzer können auch benutzerdefinierte Tests erstellen, um den Hostnamen, den zu überprüfenden Pfad und die Statuscodes, die als fehlerfrei akzeptiert werden sollen, anzugeben. Wenn der Back-End-Server nicht erfolgreich antwortet, wird der Server von Application Gateway in jedem Fall als fehlerhaft markiert, und die Anforderung wird nicht mehr an den Server weitergeleitet. Nachdem der Server erfolgreich reagiert hat, setzt Application Gateway das Weiterleiten der Anforderungen fort.

Überprüfen der Back-End-Integrität

Zum Überprüfen der Integrität des Back-End-Pools können Sie die Seite Back-End-Integrität im Azure-Portal verwenden. Sie können auch Azure PowerShell, die CLI oder die REST-API verwenden.

Der Status, der durch eine dieser Methoden abgerufen wird, kann einer der folgenden Zustände sein:

Healthy
Fehlerhaft
Unbekannt

Das Application Gateway leitet eine Anforderung an einen Server aus dem Back-End-Pool weiter, wenn dessen Status fehlerfrei ist. Wenn alle Server in einem Back-End-Pool fehlerhaft oder unbekannt sind, können die Clients beim Zugriff auf die Back-End-Anwendung Probleme haben. Lesen Sie weiter, um die verschiedenen Meldungen zur Back-End-Integrität sowie deren Ursachen und Lösung zu verstehen.

Hinweis

Wenn Ihr Benutzer nicht zum Anzeigen von Back-End-Integritätsstatuswerten berechtigt ist, wird die Ausgabe No results. angezeigt.

Back-End-Integritätsstatus: Fehlerhaft

Wenn der Back-End-Integritätsstatus Fehlerhaft ist, ähnelt die Portalansicht dem folgenden Screenshot:

Wenn Sie eine Azure PowerShell-, CLI- oder Azure REST-API-Abfrage verwenden, erhalten Sie eine Antwort, die dem folgenden Beispiel ähnelt:

PS C:\Users\testuser\> Get-AzApplicationGatewayBackendHealth -Name "appgw1" -ResourceGroupName "rgOne"
BackendAddressPools :
{Microsoft.Azure.Commands.Network.Models.PSApplicationGatewayBackendHealthPool}
BackendAddressPoolsText : [
{
                              "BackendAddressPool": {
                                "Id": "/subscriptions/aaaa0000-bb11-2222-33cc-444444dddddd/resourceGroups/rgOne/providers/Microsoft.Network/applicationGateways/appgw1/b
                          ackendAddressPools/appGatewayBackendPool"
                              },
                              "BackendHttpSettingsCollection": [
                                {
                                  "BackendHttpSettings": {
                                    "TrustedRootCertificates": [],
                                    "Id": "/subscriptions/aaaa0000-bb11-2222-33cc-444444dddddd/resourceGroups/rgOne/providers/Microsoft.Network/applicationGateways/appg
                          w1/backendHttpSettingsCollection/appGatewayBackendHttpSettings"
                                  },
                                  "Servers": [
                                    {
                                      "Address": "10.0.0.5",
                                      "Health": "Healthy"
                                    },
                                    {
                                      "Address": "10.0.0.6",
                                      "Health": "Unhealthy"
                                    }
                                  ]
                                }
                              ]
                            }
                        ]

Nachdem Sie einen fehlerhaften Back-End-Serverstatus für alle Server in einem Back-End-Pool erhalten haben, werden Anforderungen nicht an die Server weitergeleitet und Application Gateway gibt den Fehler „502 Bad Gateway“ an den anfordernden Client zurück. Um das Problem zu beheben, überprüfen Sie die Spalte Details auf der Registerkarte Back-End-Integrität.

Die in der Spalte Details angezeigte Meldung bietet detailliertere Einblicke in das Problem, und basierend auf diesen Details können Sie mit der Fehlerbehebung des Problems beginnen.

Hinweis

Die standardmäßige Prüfanforderung wird im Format <Protokoll>://127.0.0.1:<Port> gesendet. Beispielsweise http://127.0.0.1:80 für einen HTTP-Test an Port 80. Nur HTTP-Statuscodes von 200 bis 399 gelten als fehlerfrei. Das Protokoll und der Zielport werden von den HTTP-Einstellungen geerbt. Wenn Application Gateway auf ein anderes Protokoll, einen anderen Hostnamen oder einen anderen Pfad testen und einen anderen Statuscode als fehlerfrei erkennen soll, konfigurieren Sie einen benutzerdefinierten Test, und ordnen Sie ihn den HTTP-Einstellungen zu.

Fehlermeldungen

Timeout des Back-End-Servers

Nachricht: Time taken by the backend to respond to application gateways health probe is more than the time-out threshold in the probe setting. (Die Zeit, die das Back-End für die Reaktion auf den Application Gateway-Integritätstest benötigt, liegt über dem Timeoutschwellenwert in der Testeinstellung.)

Ursache: Nachdem Application Gateway eine HTTP(S)-Testanforderung an den Back-End-Server gesendet hat, wird für einen konfigurierten Zeitraum auf eine Antwort vom Back-End-Server gewartet. Wenn der Back-End-Server nicht innerhalb dieses Zeitraums (Timeoutwert) reagiert, wird er als fehlerhaft gekennzeichnet, bis er wieder innerhalb des konfigurierten Timeoutzeitraums reagiert.

Lösung: Überprüfen Sie, warum der Back-End-Server bzw. die Back-End-Anwendung nicht innerhalb des konfigurierten Timeoutzeitraums antwortet, und überprüfen Sie ebenfalls die Anwendungsabhängigkeiten. Überprüfen Sie beispielsweise, ob in der Datenbank Probleme vorliegen, die möglicherweise eine Verzögerung der Reaktion auslösen können. Wenn Sie das Verhalten der Anwendung kennen und diese nur nach dem Timeoutwert antworten sollte, erhöhen Sie den Timeoutwert in den benutzerdefinierten Testeinstellungen. Sie müssen über einen benutzerdefinierten Test verfügen, um den Wert des Timeouts zu ändern. Informationen zum Konfigurieren eines benutzerdefinierten Tests finden Sie auf der Dokumentationsseite.

Um den Wert des Timeouts zu erhöhen, führen Sie die folgenden Schritte aus:

Greifen Sie direkt auf den Back-End-Server zu, und überprüfen Sie die Zeit, die der Server benötigt, um auf diese Seite zu antworten. Sie können ein beliebiges Tool für den Zugriff auf den Back-End-Server verwenden, einschließlich eines Browsers unter Verwendung der Entwicklertools.
Nachdem Sie die Reaktionszeit der Anwendung ermittelt haben, wählen Sie die Registerkarte Integritätstests und dann den Test aus, der Ihren HTTP-Einstellungen zugeordnet ist.
Geben Sie einen Timeoutwert ein, der höher als die Antwortzeit der Anwendung in Sekunden ist.
Speichern Sie die benutzerdefinierten Testeinstellungen, und überprüfen Sie, ob die Back-End-Integrität jetzt als „Fehlerfrei“ angezeigt wird.

Fehler bei der DNS-Auflösung

Nachricht: Application gateway could not create a probe for this backend. (Application Gateway konnte keinen Test für dieses Back-End erstellen.) Dies ist normalerweise der Fall, wenn der FQDN des Back-Ends nicht ordnungsgemäß eingegeben wird.

Ursache: Wenn der Back-End-Pool vom Typ „IP-Adresse“, „FQDN“ (vollqualifizierter Domänenname) oder „App Service“ ist, löst Application Gateway die IP-Adresse des über DNS eingegebenen FQDN auf (benutzerdefiniert oder Azure-Standard). Das Anwendungs-Gateway versucht dann, eine Verbindung zum Server über den TCP-Port herzustellen, der in den HTTP-Einstellungen angegeben ist. Wenn aber diese Meldung angezeigt wird, deutet dies darauf hin, dass Application Gateway die IP-Adresse des eingegebenen FQDN nicht erfolgreich auflösen konnte.

Lösung:

Stellen Sie sicher, dass der in den Back-End-Pool eingegebene FQDN korrekt ist und dass es sich um eine öffentliche Domäne handelt, und versuchen Sie dann, ihn von Ihrem lokalen Computer aus aufzulösen.
Wenn Sie die IP-Adresse auflösen können, liegt möglicherweise ein Fehler bei der DNS-Konfiguration im virtuellen Netzwerk vor.
Überprüfen Sie, ob das virtuelle Netzwerk mit einem benutzerdefinierten DNS-Server konfiguriert ist. Wenn dies der Fall ist, überprüfen Sie auf dem DNS-Server, warum er nicht in die IP-Adresse des angegebenen FQDN auflösen kann.
Wenn Sie eine Azure-DNS-Standardadresse verwenden, vergewissern Sie sich bei Ihrer Domänennamen-Registrierungsstelle, dass eine ordnungsgemäße Zuordnung eines A-Eintrags oder CNAME-Eintrags vorgenommen wurde.
Wenn die Domäne privat oder intern ist, versuchen Sie, Sie von einem virtuellen Computer aus im selben virtuellen Netzwerk aufzulösen. Wenn Sie sie auflösen können, starten Sie Application Gateway neu, und überprüfen Sie es noch mal. Um Application Gateway neu zu starten, müssen Sie die in diesen verlinkten Ressourcen beschriebenen PowerShell-Befehle zum Beenden (stop) und Starten (start) verwenden.

TCP-Verbindungsfehler

Nachricht: Application Gateway could not connect to the backend. (Application Gateway konnte keine Verbindung mit dem Back-End herstellen.) Überprüfen Sie, ob das Back-End auf dem für den Integritätstest verwendeten Port antwortet. Überprüfen Sie auch, ob eine NSG/UDR/Firewall den Zugriff auf die IP und den Port dieses Back-Ends blockiert.

Ursache: Nach der DNS-Auflösungsphase versucht Application Gateway, eine Verbindung mit dem Back-End-Server an dem TCP-Port herzustellen, der in den HTTP-Einstellungen konfiguriert ist. Wenn Application Gateway keine TCP-Sitzung am angegebenen Port einrichten kann, wird der Test mit dieser Meldung als fehlerhaft gekennzeichnet.

Lösung: Wenn Sie diesen Fehler erhalten, gehen Sie folgendermaßen vor:

Überprüfen Sie, ob Sie mithilfe eines Browsers oder mithilfe von PowerShell eine Verbindung mit dem Back-End-Server am in den HTTP-Einstellungen genannten Port herstellen können. Führen Sie beispielsweise den folgenden Befehl aus: Test-NetConnection -ComputerName www.bing.com -Port 443.
Wenn der angegebene Port nicht der gewünschte Port ist, geben Sie die richtige Portnummer ein, damit Application Gateway eine Verbindung mit dem Back-End-Server herstellen kann.
Wenn Sie auch von Ihrem lokalen Computer aus keine Verbindung über den Port herstellen können:

a. Überprüfen Sie die Einstellungen der Netzwerksicherheitsgruppe (NSG) für den Netzwerkadapter und das Subnetz des Back-End-Servers, und ob eingehende Verbindungen an den konfigurierten Port zulässig sind. Wenn sie nicht zulässig sind, erstellen Sie eine neue Regel, um die Verbindungen zuzulassen. Informationen zum Erstellen von NSG-Regeln finden Sie auf der entsprechenden Seite der Dokumentation.

b. Überprüfen Sie, ob die NSG-Einstellungen des Application Gateway-Subnetzes ausgehenden öffentlichen und privaten Datenverkehr zulassen, damit eine Verbindung hergestellt werden kann. Überprüfen Sie die Dokumentseite, die in Schritt 3a bereitgestellt wird, um weitere Informationen zum Erstellen von NSG-Regeln zu erhalten.
```
        $vnet = Get-AzVirtualNetwork -Name "vnetName" -ResourceGroupName "rgName"
        Get-AzVirtualNetworkSubnetConfig -Name appGwSubnet -VirtualNetwork $vnet
```
c. Überprüfen Sie die UDR-Einstellungen (benutzerdefinierte Routen) des Subnetzes von Application Gateway und des Subnetzes des Back-End-Servers auf etwaige Routinganomalien. Stellen Sie sicher, dass die UDR keinen Datenverkehr vom Back-End-Subnetz wegleitet. Überprüfen Sie z. B. auf Routen zu virtuellen Netzwerkgeräten oder Standardrouten, die dem Application Gateway-Subnetz über Azure ExpressRoute und/oder VPN angekündigt werden.

d. Zum Überprüfen der effektiven Routen und Regeln für einen Netzwerkadapter können Sie die folgenden PowerShell-Befehle verwenden:
```
        Get-AzEffectiveNetworkSecurityGroup -NetworkInterfaceName "nic1" -ResourceGroupName "testrg"
        Get-AzEffectiveRouteTable -NetworkInterfaceName "nic1" -ResourceGroupName "testrg"
```
Wenn Sie keine Probleme mit der NSG oder UDR finden, überprüfen Sie Ihren Back-End-Server auf anwendungsbezogene Probleme, die Clients am Einrichten einer TCP-Sitzung an den konfigurierten Ports hindern. Folgendes sollte überprüft werden:

a. Öffnen Sie eine Eingabeaufforderung (Win+R -> cmd), geben Sie netstat ein und drücken Sie die Eingabetaste.

b. Überprüfen Sie, ob der Server am konfigurierten Port lauscht. Zum Beispiel:
```
        Proto Local Address Foreign Address State PID
        TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 4
```
c. Wenn er nicht am konfigurierten Port lauscht, überprüfen Sie Ihre Webservereinstellungen. Beispielsweise: Sitebindungen in IIS, Server Block in NGINX und virtuellen Host in Apache.

d. Überprüfen Sie die Firewalleinstellungen Ihres Betriebssystems, um sicherzustellen, dass eingehender Datenverkehr am Port zulässig ist.

HTTP-Statuscodekonflikt

Message: Status code of the backend's HTTP response did not match the probe setting. (Der Statuscode der HTTP-Antwort des Back-Ends stimmte nicht mit der Testeinstellung überein.) Expected:{HTTPStatusCode0} Received:{HTTPStatusCode1}. (Erwartet: {HTTPStatusCode0}, Empfangen: {HTTPStatusCode1}.)

Ursache: Nachdem die TCP-Verbindung hergestellt und ein TLS-Handshake ausgeführt wurde (sofern TLS aktiviert ist), sendet Application Gateway den Test als HTTP GET-Anforderung an den Back-End-Server. Wie bereits beschrieben, ist der Standardtest auf <protocol>://127.0.0.1:<port>/ festgelegt, und der Antwortstatuscodes wird im Bereich von 200 bis 399 als fehlerfrei betrachtet. Wenn der Server einen anderen Statuscode zurückgibt, wird er mit dieser Meldung als „Fehlerhaft“ gekennzeichnet.

Lösung: Abhängig vom Antwortcode des Back-End-Servers können Sie die folgenden Schritte ausführen. Einige der allgemeinen Statuscodes sind hier aufgeführt:

Fehler	Aktionen
Probe status code mismatch: (Teststatuscode-Konflikt:) Received 401 (401 empfangen)	Überprüfen Sie, ob der Back-End-Server Authentifizierung erfordert. Application Gateway-Tests können keine Anmeldeinformationen für die Authentifizierung übergeben. Lassen Sie „HTTP 401“ in einer Teststatuscode-Übereinstimmung zu, oder testen Sie einen Pfad, in dem der Server keine Authentifizierung erfordert.
Probe status code mismatch: (Teststatuscode-Konflikt:) Received 403 (403 empfangen)	Access forbidden. (Zugriff verweigert.) Überprüfen Sie, ob der Zugriff auf den Pfad auf dem Back-End-Server zulässig ist.
Probe status code mismatch: (Teststatuscode-Konflikt:) Received 404 (404 empfangen)	Page not found. (Seite nicht gefunden.) Überprüfen Sie, ob der Zugriff auf den Hostnamenpfad auf dem Back-End-Server zulässig ist. Ändern Sie den Hostnamen- oder Pfadparameter in einen Wert, auf den zugegriffen werden kann.
Probe status code mismatch: (Teststatuscode-Konflikt:) Received 405 (405 empfangen)	Die Testanforderungen für Application Gateway verwenden die HTTP GET-Methode. Überprüfen Sie, ob Ihr Server diese Methode zulässt.
Probe status code mismatch: (Teststatuscode-Konflikt:) Received 500 (500 empfangen)	Interner Serverfehler. Überprüfen Sie die Integrität des Back-End-Servers, und stellen Sie fest, ob die Dienste ausgeführt werden.
Probe status code mismatch: (Teststatuscode-Konflikt:) Received 503 (503 empfangen)	Service unavailable. (Dienst nicht verfügbar.) Überprüfen Sie die Integrität des Back-End-Servers, und stellen Sie fest, ob die Dienste ausgeführt werden.

Oder, wenn Sie der Ansicht sind, dass die Antwort legitim ist und Sie möchten, dass Application Gateway andere Statuscodes als fehlerfrei akzeptiert, können Sie einen benutzerdefinierten Test erstellen. Dieser Ansatz ist in Situationen hilfreich, in denen die Back-End-Website Authentifizierung benötigt. Da die Testanforderungen keine Benutzeranmeldeinformationen enthalten, sind sie nicht erfolgreich, und vom Back-End-Server wird ein HTTP-Statuscode vom Typ „401“ zurückgegeben.

Um einen benutzerdefinierten Test zu erstellen, führen Sie die diese Schritte aus.

Konflikt im HTTP-Antworttext

Nachricht: (Der Text der HTTP-Antwort des Back-Ends stimmte nicht mit der Testeinstellung überein.) Der empfangene Antworttext enthält nicht {Zeichenfolge}.

Ursache: Wenn Sie einen benutzerdefinierten Integritätstest erstellen, können Sie einen Back-End-Server als fehlerfrei markieren, indem Sie eine Zeichenfolge aus dem Antworttext abgleichen. Beispielsweise können Sie Application Gateway so konfigurieren, dass „unauthorized“ (nicht autorisiert) als abzugleichende Zeichenfolge angenommen wird. Wenn die Antwort des Back-End-Servers für die Testanforderung die Zeichenfolge unauthorized (nicht autorisiert) enthält, wird der Server als „Fehlerfrei“ gekennzeichnet. Andernfalls wird er mit der angegebenen Meldung als „Fehlerhaft“ gekennzeichnet.

Lösung: Gehen Sie folgendermaßen vor, um das Problem zu beheben:

Greifen Sie auf den Back-End-Server lokal oder über einen Clientcomputer im Testpfad zu, und überprüfen Sie den Antworttext.
Überprüfen Sie, ob der Antworttext in der benutzerdefinierten Testkonfiguration von Application Gateway mit den konfigurierten Einstellungen übereinstimmt.
Wenn dies nicht der Fall ist, ändern Sie die Testkonfiguration in den richtigen Zeichenfolgenwert, der akzeptiert werden soll.

Weitere Informationen zum Testabgleich von Application Gateway.

Hinweis

Bei Fehlermeldungen im Zusammenhang mit TLS finden Sie weitere Informationen zum SNI-Verhalten und zu den Unterschieden zwischen der v1-SKU und der v2-SKU auf der Seite mit der Übersicht über TLS.

Common Name (CN) stimmt nicht überein

Meldung: (Für V2) Der allgemeine Name des vom Back-End-Server vorgelegten Blattzertifikats stimmt nicht mit dem Test- oder Back-End-Einstellungs-Hostnamen des Anwendungsgateways überein.
(Für V1) Der allgemeine Name (Common Name, CN) des Back-End-Zertifikats stimmt nicht überein.

Ursache (für V2): Dieser Fehler tritt auf, wenn Sie das HTTPS-Protokoll in der Back-End-Einstellung auswählen und weder der Hostname des benutzerdefinierten Tests noch der Hostname der Back-End-Einstellung (in dieser Reihenfolge) dem Common Name (CN) des Zertifikats des Back-End-Servers entspricht.
(Für V1) Der FQDN des Back-End-Poolziels stimmt nicht mit dem allgemeinen Name (CN) des Zertifikats des Back-End-Servers überein.

Lösung: Die Hostnamen-Informationen sind für die Back-End-HTTPS-Verbindung wichtig, da dieser Wert zum Festlegen der Servernamensanzeige (Server Name Indication, SNI) während des TLS-Handshakes verwendet wird. Sie können dieses Problem auf folgende Weise basierend auf der Konfiguration Ihres Gateways beheben.

Für V2:

Wenn Sie einen Standardtest verwenden – Sie können einen Hostnamen in der zugehörigen Back-End-Einstellung Ihres Anwendungsgateways angeben. Sie können in der Back-End-Einstellung „Mit einem bestimmten Hostnamen überschreiben“ oder „Hostnamen aus Back-End-Ziel übernehmen“ auswählen.
Wenn Sie einen benutzerdefinierten Test verwenden – Für benutzerdefinierte Tests können Sie das Feld „Host“ verwenden, um den gemeinsamen Namen des Back-End-Serverzertifikats anzugeben. Wenn die Back-End-Einstellung bereits mit demselben Hostnamen konfiguriert ist, können Sie in den Testeinstellungen auch „Hostnamen aus Back-End-Einstellung übernehmen“ auswählen.

Überprüfen Sie für V1, ob der FQDN des Back-End-Pools mit dem gemeinsamen Namen (Common Name, CN) übereinstimmt.

Tipps: Um den allgemeinen Namen (Common Name, CN) des Back-End-Serverzertifikats zu ermitteln, können Sie eine dieser Methoden verwenden. Beachten Sie außerdem, dass gemäß RFC 6125 die SNI-Überprüfung ausschließlich für dieses Feld durchgeführt wird, wenn ein SAN vorhanden ist. Das Feld für den allgemeinen Namen wird abgeglichen, wenn das Zertifikat kein SAN enthält.

Mithilfe des Browsers oder eines beliebigen Clients: Greifen Sie direkt (nicht über das Anwendungsgateway) auf den Back-End-Server zu und klicken Sie auf das Zertifikatsvorhängeschloss in der Adressleiste, um die Zertifikatdetails anzuzeigen. Diese Angabe finden Sie unter dem Abschnitt „Ausgestellt für“.
Durch Anmeldung beim Back-End-Server (Windows):
1. Melden Sie sich bei dem Computer an, auf dem Ihre Anwendung gehostet wird.
2. Drücken Sie WIN+R, oder klicken Sie mit der rechten Maustaste auf die Schaltfläche Start, und wählen Sie Ausführen aus.
3. Geben Sie certlm.msc ein, und drücken Sie die EINGABETASTE. Sie können auch im Startmenü nach dem Zertifikat-Manager suchen.
4. Suchen Sie das Zertifikat (in der Regel in Zertifikaten – Lokaler Computer\Personal\Zertifikate) und öffnen Sie das Zertifikat.
5. Überprüfen Sie auf der Registerkarte Details den Antragsteller des Zertifikats.
Indem Sie sich beim Back-End-Server (Linux) anmelden: Führen Sie diesen OpenSSL-Befehl aus, indem Sie den richtigen Dateiname für das Zertifikat openssl x509 -in certificate.crt -subject -noout angeben

Back-End-Zertifikat ist abgelaufen

Nachricht: Backend certificate is invalid. (Das Back-End-Zertifikat ist ungültig.) Current date isn't within the „Valid from“ and „Valid to“ date range on the certificate. (Das aktuelle Datum entspricht nicht den Datumsbereichen „Gültig ab“ und „Gültig bis“ für das Zertifikat.)

Ursache: Ein abgelaufenes Zertifikat gilt als unsicher, und daher markiert das Anwendungsgateway den Back-End-Server mit einem abgelaufenen Zertifikat als fehlerhaft.

Lösung: Die Lösung hängt davon ab, welcher Teil der Zertifikatkette auf dem Back-End-Server abgelaufen ist.

Für V2-SKU:

Expired Leaf -Zertifikat (auch bekannt als Domäne oder Server) – Verlängern Sie das Serverzertifikat beim Zertifikatanbieter und installieren Sie das neue Zertifikat auf dem Back-End-Server. Achten Sie darauf, die vollständige Zertifikatkette (Leaf (topmost) > Intermediate(s) > Root) zu installieren. Basierend auf dem Typ der Zertifizierungsstelle können Sie die folgenden Aktionen auf Ihrem Gateway ausführen.
- Öffentlich bekannte Zertifizierungsstelle: Wenn es sich bei dem Zertifikataussteller um eine bekannte Zertifizierungsstelle handelt, müssen Sie keine Maßnahmen am Anwendungsgateway ergreifen.
- Private Zertifizierungsstelle: Wenn das Blattzertifikat von einer privaten Zertifizierungsstelle ausgestellt wird, müssen Sie überprüfen, ob das Signaturzertifikat der Stammzertifizierungsstelle geändert wurde. In solchen Fällen müssen Sie das neue Stammzertifizierungsstellenzertifikat (.CER) in die entsprechende Back-End-Einstellung Ihres Gateways hochladen.
Abgelaufene Zwischen- oder Stammzertifikate – Diese Zertifikate haben in der Regel eine relativ lange Gültigkeitsdauer (ein oder zwei Jahrzehnte). Wenn das Stamm-/Zwischenzertifikat abläuft, empfehlen wir Ihnen, bei Ihrem Zertifikatsanbieter nach neuen Zertifikatsdateien zu fragen. Achten Sie darauf, diese aktualisierte und vollständige Zertifikatkette (Leaf (topmost) > Intermediate(s) > Root) auf dem Back-End-Server zu installieren.
- Wenn das Stammzertifikat unverändert bleibt oder der Aussteller eine bekannte Zertifizierungsstelle ist, müssen Sie keine Maßnahmen für das Anwendungsgateway ergreifen.
- Wenn Sie eine private Zertifizierungsstelle verwenden, wenn sich das Stammzertifizierungsstellenzertifikat selbst oder der Stamm des erneuerten Zwischenzertifikats geändert hat, müssen Sie das neue Stammzertifikat in die Back-End-Einstellung des Anwendungsgateways hochladen.

Für V1-SKU:

Verlängern Sie das abgelaufene Blattzertifikat (auch als Domäne oder Server bezeichnet) bei Ihrer Zertifizierungsstelle und laden Sie dasselbe Blattzertifikat (. CER) in die zugeordnete Back-End-Einstellung Ihres Anwendungsgateways hoch.

Das Zwischenzertifikat wurde nicht gefunden

Meldung: Das Zwischenzertifikat fehlt in der vom Back-End-Server vorgelegten Zertifikatskette. Stellen Sie sicher, dass die Zertifikatskette auf dem Back-End-Server vollständig und korrekt angeordnet ist.

Ursache: Die Zwischenzertifikate sind nicht in der Zertifikatskette auf dem Back-End-Server installiert.

Lösung: Ein Zwischenzertifikat wird zum Signieren des Blattzertifikats verwendet und ist daher zum Abschließen der Kette erforderlich. Erfragen Sie bei Ihrer Zertifizierungsstelle die erforderlichen Zwischenzertifikate, und installieren Sie sie auf Ihrem Back-End-Server. Diese Kette muss mit dem untergeordneten Zertifikat beginnen, gefolgt von den Zwischenzertifikaten und schließlich dem Zertifikat der Stammzertifizierungsstelle. Es wird empfohlen, die vollständige Kette auf dem Back-End-Server zu installieren, einschließlich des Zertifikats der Stammzertifizierungsstelle. Betrachten Sie als Referenz das Beispiel für die Zertifikatkette unter Untergeordnetes Zertifikat muss in Kette an oberster Stelle sein.

Hinweis

Ein selbstsigniertes Zertifikat, das KEINE Zertifizierungsstelle ist, führt ebenfalls zu diesem Fehler. Dies liegt daran, dass das Anwendungsgateway ein solches selbstsigniertes Zertifikat als „Blatt“-Zertifikat betrachtet und nach dessen signierenden Zwischenzertifikat sucht. Sie können diesem Artikel folgen, um ein selbstsigniertes Zertifikat ordnungsgemäß zu generieren.

Diese Bilder zeigen den Unterschied zwischen den selbstsignierten Zertifikaten.

Das Blatt- oder Serverzertifikat wurde nicht gefunden

Meldung: Das Blattzertifikat fehlt in der vom Back-End-Server vorgelegten Zertifikatskette. Stellen Sie sicher, dass die Kette vollständig und korrekt auf dem Back-End-Server angeordnet ist.

Ursache: Das untergeordnete Zertifikat (auch bekannt als Domäne oder Server) fehlt in der Zertifikatkette auf dem Back-End-Server.

Lösung: Sie können das Blattzertifikat von Ihrer Zertifizierungsstelle (ZS) erhalten. Installieren Sie dieses untergeordnete Zertifikat und alle zugehörigen Signaturzertifikate (Zwischen- und Stamm-ZS-Zertifikate) auf dem Back-End-Server. Diese Kette muss mit dem untergeordneten Zertifikat beginnen, gefolgt von den Zwischenzertifikaten und schließlich dem Zertifikat der Stammzertifizierungsstelle. Es wird empfohlen, die vollständige Kette auf dem Back-End-Server zu installieren, einschließlich des Zertifikats der Stammzertifizierungsstelle. Betrachten Sie als Referenz das Beispiel für die Zertifikatkette unter Untergeordnetes Zertifikat muss in Kette an oberster Stelle sein.

Das Serverzertifikat wird nicht von einer öffentlich bekannten Zertifizierungsstelle ausgestellt

Meldung: The backend Server certificate isn't signed by a well-known Certificate Authority (CA). (Das Back-End-Serverzertifikat ist nicht von einer bekannten Zertifizierungsstelle (ZS) signiert.) Um unbekannte Zertifizierungsstellenzertifikate verwenden zu können, muss das zugehörige Stammzertifikat in die Back-End-Einstellung des Anwendungsgateways hochgeladen werden.

Ursache: Sie haben in der Back-End-Einstellung „Zertifikat einer bekannten Zertifizierungsstelle“ ausgewählt, aber das vom Back-End-Server bereitgestellte Stammzertifikat ist nicht öffentlich bekannt.

Lösung: Wenn ein Blattzertifikat von einer privaten Zertifizierungsstelle (ZS) ausgestellt wird, muss das Zertifikat der signierenden Stammzertifizierungsstelle in die zugeordnete Back-End-Einstellung des Anwendungsgateways hochgeladen werden. Dadurch kann Ihr Anwendungsgateway eine vertrauenswürdige Verbindung mit diesem Back-End-Server herstellen. Um dies zu beheben, wechseln Sie zur zugehörigen Back-End-Einstellung, wählen „Keine bekannte Zertifizierungsstelle" aus und laden das Zertifikat der Stammzertifizierungsstelle (CER) hoch. Um das Stammzertifikat zu identifizieren und herunterzuladen, können Sie die gleichen Schritte ausführen, wie unter Konflikt eines vertrauenswürdigen Stammzertifikats beschrieben.

Das Zwischenzertifikat ist NICHT von einer öffentlich bekannten ZS signiert.

Meldung: The Intermediate certificate isn't signed by a well-known Certificate Authority (CA). (Das Zwischenzertifikat ist nicht von einer bekannten Zertifizierungsstelle (ZS) signiert.) Stellen Sie sicher, dass die Zertifikatskette auf dem Back-End-Server vollständig und korrekt angeordnet ist.

Ursache: Sie haben in der Back-End-Einstellung „Zertifikat einer bekannten Zertifizierungsstelle“ ausgewählt, aber das vom Back-End-Server bereitgestellte Zwischenzertifikat ist nicht von einer öffentlich bekannten ZS signiert.

Lösung: Wenn ein Zertifikat von einer privaten Zertifizierungsstelle (ZS) ausgestellt wird, muss das Zertifikat der signierenden Stammzertifizierungsstelle in die zugeordnete Back-End-Einstellung des Anwendungsgateways hochgeladen werden. Dadurch kann Ihr Anwendungsgateway eine vertrauenswürdige Verbindung mit diesem Back-End-Server herstellen. Um dies zu beheben, wenden Sie sich an Ihre private Zertifizierungsstelle, um das entsprechende Zertifikat der Stammzertifizierungsstelle (.CER) zu erhalten, und laden Sie diese CER-Datei durch Auswahl von „Keine bekannte Zertifizierungsstelle“ in die Back-End-Einstellung Ihres Anwendungsgateways hoch. Es wird auch empfohlen, zur mühelosen Überprüfung die vollständige Kette einschließlich des Zertifikats der Stammzertifizierungsstelle auf dem Back-End-Server zu installieren.

Fehlende Übereinstimmung mit vertrauenswürdigen Stammzertifikaten (kein Stammzertifikat auf dem Back-End-Server)

Meldung: Das Zwischenzertifikat, das nicht von Stammzertifikaten signiert wurde, die in das Anwendungsgateway hochgeladen wurden. Stellen Sie sicher, dass die Zertifikatskette auf dem Back-End-Server vollständig und korrekt angeordnet ist.

Ursache: Keines der Zertifikate der Stammzertifizierungsstelle, die in die zugehörige Back-End-Einstellung hochgeladen wurden, hat das auf dem Back-End-Server installierte Zwischenzertifikat signiert. Auf dem Back-End-Server sind nur untergeordnete und Zwischenzertifikate installiert.

Lösung: Ein Blattzertifikat wird von einem Zwischenzertifikat signiert, das von einem Stammzertifizierungsstellenzertifikat signiert ist. Wenn Sie ein Zertifikat von der privaten Zertifizierungsstelle verwenden, müssen Sie das entsprechende Zertifikat der Stammzertifizierungsstelle in das Anwendungsgateway hochladen. Wenden Sie sich an Ihre private Zertifizierungsstelle, um das entsprechende Zertifikat der Stammzertifizierungsstelle (CER) zu erhalten, und laden Sie diese CER-Datei in die Back-End-Einstellung Ihres Anwendungsgateways hoch.

Fehlende Übereinstimmung mit vertrauenswürdigen Stammzertifikaten (Stammzertifikat ist auf dem Back-End-Server verfügbar)

Meldung: The root certificate of the server certificate used by the backend doesn't match the trusted root certificate added to the application gateway. (Das Stammzertifikat des Serverzertifikats, das vom Back-End verwendet wird, stimmt nicht mit dem vertrauenswürdigen Stammzertifikat überein, das dem Anwendungsgateway hinzugefügt wurde.) Ensure that you add the correct root certificate to allowlist the backend. (Stellen Sie sicher, dass Sie das richtige Stammzertifikat hinzufügen, um das Back-End in die Zulassungsliste aufzunehmen.)

Ursache: Dieser Fehler tritt auf, wenn keines der in die Back-End-Einstellung Ihres Anwendungsgateways hochgeladenen Stammzertifikate dem Stammzertifikat entspricht, das auf dem Back-End-Server vorhanden ist.

Lösung: Dies gilt für ein Back-End-Serverzertifikat, das von einer privaten Zertifizierungsstelle (ZS) ausgestellt wurde oder ein selbstsigniertes Zertifikat ist. Identifizieren Sie das richtige Zertifikat der Stammzertifizierungsstelle, und laden Sie es in die zugehörige Back-End-Einstellung hoch.

Tipps: Um das Stammzertifikat zu identifizieren und herunterzuladen, können Sie eine dieser Methoden verwenden.

Verwenden eines Browsers: Greifen Sie direkt (nicht über das Anwendungsgateway) auf den Back-End-Server zu und klicken Sie auf das Zertifikatsvorhängeschloss in der Adressleiste, um die Zertifikatdetails anzuzeigen.
1. Wählen Sie das Stammzertifikat in der Kette aus und klicken Sie auf „Exportieren“. Hierbei handelt es sich standardmäßig um eine CRT-Datei.
2. Öffnen Sie die .CRT-Datei.
3. Wechseln Sie zur Registerkarte „Details“ und klicken Sie auf „In Datei kopieren“,
4. Klicken Sie auf der Seite „Zertifikatexport-Assistent“ auf „Weiter“,
5. Wählen Sie „Basis-64-codiertes X.509 (.CER) aus und klicken Sie dann auf „Weiter“,
6. Geben Sie einen neuen Dateinamen ein und klicken Sie auf „Weiter“,
7. Klicken Sie auf „Fertigstellen“, um eine .CER-Datei zu erhalten.
8. Laden Sie dieses Stammzertifikat (.CER) Ihrer privaten Zertifizierungsstelle an die Back-End-Einstellung des Anwendungsgateways hoch.
Durch Anmelden beim Back-End-Server (Windows)
1. Melden Sie sich bei dem Computer an, auf dem Ihre Anwendung gehostet wird.
2. Drücken Sie WIN+R, oder klicken Sie mit der rechten Maustaste auf die Schaltfläche Start, und wählen Sie dann Ausführen aus.
3. Geben Sie certlm.msc ein, und drücken Sie die EINGABETASTE. Sie können auch im Startmenü nach dem Zertifikat-Manager suchen.
4. Suchen Sie das Zertifikat, in der Regel in Zertifikaten – Lokaler Computer\Personal\Zertifikate und öffnen Sie es.
5. Wählen Sie das Stammzertifikat und dann Zertifikat anzeigen aus.
6. Wählen Sie in den Zertifikateigenschaften die Registerkarte „Details“ aus und klicken Sie auf „In Datei kopieren“,
7. Klicken Sie auf der Seite „Zertifikatexport-Assistent“ auf „Weiter“,
8. Wählen Sie „Basis-64-codiertes X.509 (.CER) aus und klicken Sie dann auf „Weiter“,
9. Geben Sie einen neuen Dateinamen ein und klicken Sie auf „Weiter“,
10. Klicken Sie auf „Fertigstellen“, um eine .CER-Datei zu erhalten.
11. Laden Sie dieses Stammzertifikat (.CER) Ihrer privaten Zertifizierungsstelle an die Back-End-Einstellung des Anwendungsgateways hoch.

Blatt muss am weitesten oben in der Kette sein.

Meldung: The Leaf certificate isn't the topmost certificate in the chain presented by the backend server. (Das untergeordnete Zertifikat ist nicht das oberste Zertifikat in der Kette, die vom Back-End-Server bereitgestellt wird.) Stellen Sie sicher, dass die Zertifikatskette auf dem Back-End-Server korrekt angeordnet ist.

Ursache: Das untergeordnete Zertifikat (auch als Domänen- oder Serverzertifikat bezeichnet) ist nicht in der richtigen Reihenfolge auf dem Back-End-Server installiert.

Lösung: Die Zertifikatinstallation auf dem Back-End-Server muss eine geordnete Liste von Zertifikaten enthalten, die das Blattzertifikat sowie alle zugehörigen Signaturzertifikate (Zwischen- und Stammzertifizierungsstellenzertifikate) umfasst. Diese Kette muss mit dem untergeordneten Zertifikat beginnen, gefolgt von den Zwischenzertifikaten und schließlich dem Zertifikat der Stammzertifizierungsstelle. Es wird empfohlen, die vollständige Kette auf dem Back-End-Server zu installieren, einschließlich des Zertifikats der Stammzertifizierungsstelle.

Es folgt ein Beispiel für die Installation eines Serverzertifikats zusammen mit seinen Zwischen- und Stammzertifikaten, die in OpenSSL als Tiefe (0, 1, 2 usw.) bezeichnet werden. Sie können dasselbe für das Back-End-Serverzertifikat mit den folgenden OpenSSL-Befehlen überprüfen.
s_client -connect <FQDN>:443 -showcerts
ODER
s_client -connect <IPaddress>:443 -servername <TLS SNI hostname> -showcerts

Fehler bei der Zertifikatüberprüfung

Nachricht: The validity of the backend certificate could not be verified. (Die Gültigkeit des Back-End-Zertifikats konnte nicht bestätigt werden.) To find out the reason, check Open SSL diagnostics for the message associated with error code {errorCode}. (Um den Grund zu ermitteln, überprüfen Sie die OpenSSL-Diagnose für die Meldung, die dem Fehlercode {fehlerCode} zugeordnet ist.)

Ursache: Dieser Fehler tritt auf, wenn Application Gateway nicht in der Lage ist, die Gültigkeit des Zertifikats zu überprüfen.

Lösung: Um dieses Problem zu beheben, überprüfen Sie, ob das Zertifikat auf dem Server ordnungsgemäß erstellt wurde. Beispielsweise können Sie mit OpenSSL das Zertifikat und seine Eigenschaften überprüfen und dann versuchen, das Zertifikat erneut in die HTTP-Einstellungen von Application Gateway hochzuladen.

Back-End-Integritätsstatus: Unbekannt

Aktualisierungen der DNS-Einträge des Back-End-Pools

Meldung: Der Back-End-Integritätsstatus konnte nicht abgerufen werden. Dies geschieht, wenn eine NSG/UDR/Firewall im Application Gateway-Subnetz den Datenverkehr an den Ports 65503–65534 im Fall der v1-SKU und an den Ports 65200–65535 im Fall der v2-SKU blockiert oder der im Back-End-Pool konfigurierte FQDN nicht in eine IP-Adresse aufgelöst werden konnte. Weitere Informationen finden Sie hier: https://aka.ms/UnknownBackendHealth.

Ursache: Für FQDN-basierte Back-End-Ziele (Vollqualifizierter Domänenname) speichert das Anwendungsgateway zwischen und verwendet die zuletzt bekannte gute IP-Adresse, wenn keine Antwort für die nachfolgende DNS-Suche abgerufen werden kann. Ein PUT-Vorgang auf einem Gateway in diesem Zustand würde seinen DNS-Cache vollständig löschen. Daher gibt es keine Zieladresse, die für das Gateway erreichbar ist.

Lösung: Überprüfen und korrigieren Sie die DNS-Server, um sicherzustellen, dass sie eine Antwort für das DNS-Lookup des jeweiligen FDQN liefern. Sie müssen auch überprüfen, ob die DNS-Server über das virtuelle Netzwerk Ihres Anwendungsgateways erreichbar sind.

Andere Gründe

Wenn die Back-End-Integrität als „Unbekannt“ angezeigt wird, sieht die Portalansicht in etwa wie der folgende Screenshot aus:

Back-End-Integrität von Application Gateway: Unbekannt

Dieses Verhalten kann aus einem oder mehreren der folgenden Gründe auftreten:

Die Netzwerksicherheitsgruppe (NSG) im Application Gateway-Subnetz blockiert den eingehenden Zugriff auf die Ports 65503 bis 65534 (v1-SKU) oder 65200 bis 65535 (v2-SKU) aus dem „Internet“.
Die UDR im Application Gateway-Subnetz ist auf die Standardroute (0.0.0.0/0) festgelegt, und als nächster Hop ist nicht „Internet“ angegeben.
Die Standardroute wird von einer ExpressRoute-/VPN-Verbindung in einem virtuellen Netzwerk über BGP angekündigt.
Der benutzerdefinierte DNS-Server ist in einem virtuellen Netzwerk konfiguriert, das keine öffentlichen Domänennamen auflösen kann.
Application Gateway befindet sich in einem fehlerhaften Zustand.

Lösung:

Überprüfen Sie, ob Ihre NSG den Zugriff auf die Ports 65503 bis 65534 (v1-SKU) oder 65200 bis 65535 (v2-SKU) aus dem Internet blockiert:

a. Wählen Sie auf der Registerkarte Übersicht von Application Gateway den Link Virtuelles Netzwerk/Subnetz aus. b. Wählen Sie auf der Registerkarte Subnetze Ihres virtuellen Netzwerks das Subnetz aus, in dem Application Gateway bereitgestellt ist. c. Überprüfen Sie, ob eine NIC konfiguriert ist. d. Wenn eine NSG konfiguriert ist, suchen Sie nach dieser NSG-Ressource auf der Registerkarte Suche oder unter Alle Ressourcen. e. Fügen Sie im Abschnitt Eingehende Regeln eine Regel für eingehenden Datenverkehr hinzu, um den Zielportbereich 65503 bis 65534 für die v1-SKU oder 65200 bis 65535 für die v2-SKU mit der Quelle mit dem Diensttag GatewayManager zuzulassen. f. Wählen Sie Speichern aus, und überprüfen Sie, ob Sie die Integrität des Back-Ends als „Fehlerfrei“ anzeigen können. Alternativ dazu können Sie hierzu auch die PowerShell/CLI verwenden.
Überprüfen Sie, ob Ihre UDR über eine Standardroute (0.0.0.0/0) verfügt, wobei der nächste Hop nicht auf Internet festgelegt ist:

a. Führen Sie die Schritte 1a und 1b aus, um Ihr Subnetz zu ermitteln. b. Überprüfen Sie, ob ein UDR konfiguriert ist. Wenn dies der Fall ist, suchen Sie nach der Ressource über die Suchleiste oder unter Alle Ressourcen. c. Überprüfen Sie, ob es Standardrouten (0.0.0.0/0) gibt, wobei der nächste Hop nicht auf Internet eingestellt ist. Wenn die Einstellung entweder Virtuelles Gerät oder Virtuelles Netzwerkgateway ist, müssen Sie sicherstellen, dass Ihr virtuelles Gerät oder das lokale Gerät das Paket ordnungsgemäß zurück an das Internetziel weiterleiten kann, ohne das Paket zu ändern. Wenn Prüfpunkte über ein virtuelles Gerät weitergeleitet und geändert werden, zeigt die Back-End-Ressource den Statuscode 200 an, und für den Application Gateway-Integritätsstatus wird ggf. Unbekannt angezeigt. Dies weist nicht auf einen Fehler hin. Datenverkehr sollte weiterhin über das Anwendungsgateway ohne Probleme weitergeleitet werden. d. Andernfalls ändern Sie den nächsten Hop in Internet, wählen Sie Speichern aus, und überprüfen Sie die Back-End-Integrität.
Von einer ExpressRoute-/VPN-Verbindung in einem virtuellen Netzwerk über BGP (Border Gateway Protocol) angekündigte Standardroute:

a. Wenn Sie über eine ExpressRoute-/VPN-Verbindung mit dem virtuellen Netzwerk über BGP verfügen und eine Standardroute ankündigen, müssen Sie sicherstellen, dass das Paket zurück an das Internetziel weitergeleitet wird, ohne es zu ändern. Sie können dies überprüfen, indem Sie die Option Problembehandlung für Verbindung im Application Gateway-Portal verwenden. b. Wählen Sie das Ziel manuell als beliebige, internetroutingfähige IP-Adresse wie „1.1.1.1“ aus. Legen Sie den Zielport auf einen beliebigen Wert fest, und überprüfen Sie die Konnektivität. c. Wenn der nächste Hop „Virtual Network Gateway“ ist, ist möglicherweise eine Standardroute vorhanden, die über ExpressRoute oder VPN angekündigt wird.
Wenn im virtuellen Netzwerk ein benutzerdefinierter DNS-Server konfiguriert ist, überprüfen Sie, ob die Server öffentliche Domänen auflösen können. Die Auflösung öffentlicher Domänennamen ist möglicherweise in Szenarios erforderlich, in denen Application Gateway beispielsweise externe Domänen wie Online Certificate Status Protocol (OCSP)-Server erreichen oder den Sperrstatus des Zertifikats überprüfen muss.
Um zu überprüfen, ob Application Gateway fehlerfrei ist und ausgeführt wird, rufen Sie die Option Resource Health im Portal auf und überprüfen Sie, ob der Status Healthy ist. Wenn Sie den Zustand Fehlerhaft oder Beeinträchtigt sehen, wenden Sie sich an den Support.
Wenn das Internet und der private Datenverkehr über eine Azure Firewall laufen, die in einem geschützter virtueller Hub gehostet wird (mit Azure Virtual WAN Hub):

a. Um sicherzustellen, dass das Anwendungsgateway Datenverkehr direkt an das Internet senden kann, konfigurieren Sie die folgende benutzerdefinierte Route:

Adresspräfix: 0.0.0.0/0
Nächster Hop: Internet

b. Um sicherzustellen, dass das Anwendungsgateway Datenverkehr über eine Azure Firewall-Instanz im Virtual WAN-Hub an den Back-End-Pool senden kann, konfigurieren Sie die folgende benutzerdefinierte Route:

Adresspräfix: Subnetz des Back-End-Pools
Nächster Hop: Private Azure Firewall-IP-Adresse

Hinweis

Wenn das Anwendungsgateway nicht auf die CRL-Endpunkte zugreifen kann, kennzeichnet es den Back-End-Integritätsstatus möglicherweise als „Unbekannt“. Um diese Probleme zu verhindern, überprüfen Sie, ob das Subnetz Ihres Anwendungsgateways auf crl.microsoft.com und crl3.digicert.com zugreifen kann. Hierzu können Sie Ihre Netzwerksicherheitsgruppen so konfigurieren, dass Datenverkehr an die CRL-Endpunkte gesendet wird.

Nächste Schritte

Weitere Informationen zu Diagnose und Protokollen in Application Gateway.

Teilen über

Behandeln von Problemen mit der Back-End-Integrität in Application Gateway

Übersicht

Überprüfen der Back-End-Integrität

Back-End-Integritätsstatus: Fehlerhaft

Fehlermeldungen

Timeout des Back-End-Servers

Fehler bei der DNS-Auflösung

TCP-Verbindungsfehler

HTTP-Statuscodekonflikt

Konflikt im HTTP-Antworttext

Common Name (CN) stimmt nicht überein

Back-End-Zertifikat ist abgelaufen

Das Zwischenzertifikat wurde nicht gefunden

Das Blatt- oder Serverzertifikat wurde nicht gefunden

Das Serverzertifikat wird nicht von einer öffentlich bekannten Zertifizierungsstelle ausgestellt

Das Zwischenzertifikat ist NICHT von einer öffentlich bekannten ZS signiert.

Fehlende Übereinstimmung mit vertrauenswürdigen Stammzertifikaten (kein Stammzertifikat auf dem Back-End-Server)

Fehlende Übereinstimmung mit vertrauenswürdigen Stammzertifikaten (Stammzertifikat ist auf dem Back-End-Server verfügbar)

Blatt muss am weitesten oben in der Kette sein.

Fehler bei der Zertifikatüberprüfung

Back-End-Integritätsstatus: Unbekannt

Aktualisierungen der DNS-Einträge des Back-End-Pools

Andere Gründe

Nächste Schritte

Feedback

Zusätzliche Ressourcen