Résoudre les problèmes d’intégrité des back-ends dans Application Gateway

Article
03/08/2024

Vue d’ensemble

Par défaut, Azure Application Gateway sonde les serveurs back-end afin de vérifier leur état d’intégrité et leur disponibilité pour traiter les requêtes. Les utilisateurs peuvent également créer des sondes personnalisées pour indiquer le nom d’hôte, le chemin à sonder et les codes d’état à considérer comme sains. Dans les deux cas, si le serveur back-end ne répond pas, Application Gateway marque le serveur comme Non sain et arrête la transmission des requêtes au serveur. Quand le serveur répond de nouveau, Application Gateway reprend la transmission des requêtes.

Comment vérifier l’intégrité des back-ends

Vous pouvez vérifier l’intégrité de votre pool de back-ends par le biais de la page Intégrité principale du portail Azure. Vous pouvez également utiliser Azure PowerShell, l’interface CLI ou l’API REST.

L’état récupéré par l’une de ces méthodes peut être l’un des états suivants :

Healthy
Unhealthy
Inconnu

Application Gateway transfère une requête à un serveur du pool principal si son état est sain. Si tous les serveurs d’un pool principal sont non sain ou inconnus, les clients peuvent rencontrer des problèmes d’accès à l’application principale. Lisez plus en détail pour comprendre les différents messages signalés par l’intégrité du serveur principal, leurs causes et leur résolution.

Remarque

Si votre utilisateur n’est pas autorisé à voir l’état d’intégrité du serveur principal, No results. sera affiché.

État d’intégrité du serveur principal : Non sain

Si l’état d’intégrité principal est Non sain, la vue du portail se présente comme sur la capture d’écran suivante :

Si vous utilisez une requête Azure PowerShell, d’interface CLI ou d’API REST Azure, vous obtenez une réponse qui se présente comme l’exemple suivant :

PS C:\Users\testuser\> Get-AzApplicationGatewayBackendHealth -Name "appgw1" -ResourceGroupName "rgOne"
BackendAddressPools :
{Microsoft.Azure.Commands.Network.Models.PSApplicationGatewayBackendHealthPool}
BackendAddressPoolsText : [
{
                              "BackendAddressPool": {
                                "Id": "/subscriptions/536d30b8-665b-40fc-bd7e-68c65f816365/resourceGroups/rgOne/providers/Microsoft.Network/applicationGateways/appgw1/b
                          ackendAddressPools/appGatewayBackendPool"
                              },
                              "BackendHttpSettingsCollection": [
                                {
                                  "BackendHttpSettings": {
                                    "TrustedRootCertificates": [],
                                    "Id": "/subscriptions/536d30b8-665b-40fc-bd7e-68c65f816365/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"
                                    }
                                  ]
                                }
                              ]
                            }
                        ]

Quand vous recevez un état d’intégrité non sain pour tous les serveurs back-end d’un pool de back-ends, les requêtes ne sont pas transmises à ces serveurs, et Application Gateway retourne l’erreur « Passerelle incorrecte - 502 » au client à l’origine des requêtes. Pour résoudre ce problème, examinez la colonne Détails de l’onglet Intégrité principale.

Le message affiché dans la colonne Détails fournit des insights plus détaillés sur ce problème, qui vous aident à entreprendre la résolution du problème.

Remarque

La demande de sondage par défaut est envoyée au format <protocole>://127.0.0.1:<port>. Par exemple, http://127.0.0.1:80 pour une sonde HTTP sur le port 80. Seuls les codes d’état HTTP de 200 à 399 sont considérés comme sains. Le protocole et le port de destination sont hérités des paramètres HTTP. Si vous souhaitez qu’Application Gateway sonde sur un autre protocole, nom d’hôte ou chemin et reconnaisse un autre code d’état comme sain, configurez une sonde personnalisée et associez-la aux paramètres HTTP.

Messages d’erreur

Délai d’attente dépassé pour le serveur back-end

Message : le temps pris par le serveur back-end pour répondre à la sonde d’intégrité d’Application Gateway est supérieur au seuil de délai d’attente défini dans les paramètres de la sonde.

Cause : Après avoir envoyé une demande de sondage HTTP(S) au serveur back-end, Application Gateway attend la réponse de ce serveur pendant une période définie. Si le serveur back-end ne répond pas au cours de la période configurée (valeur de délai), il est marqué comme Non sain jusqu’à ce qu’il recommence à répondre (dans le délai imparti).

Résolution : Vérifiez la raison pour laquelle l’application ou le serveur back-end ne répond pas dans le délai configuré, et vérifiez les dépendances de l’application. Par exemple, vérifiez si la base de données présente des problèmes susceptibles d’entraîner un retard dans la réponse. Si l’application a le comportement attendu et qu’elle doit répondre seulement après le délai défini, augmentez la valeur du délai dans les paramètres de la sonde personnalisée. Vous devez disposer d’une sonde personnalisée pour modifier la valeur du délai. Pour plus d’informations sur la configuration d’une sonde personnalisée, consultez la page de documentation.

Pour augmenter la valeur du délai, effectuez les étapes suivantes :

Accédez directement au serveur back-end et regardez le temps que le serveur a pris pour répondre sur cette page. Vous pouvez pour cela utiliser n’importe quel outil, y compris les outils de développement d’un navigateur.
Après avoir déterminé le temps de réponse de l’application, sélectionnez l’onglet Sondes d’intégrité, puis sélectionnez la sonde associée à vos paramètres HTTP.
Entrez une valeur de délai supérieure au délai de réponse de l’application, en secondes.
Enregistrez les paramètres de la sonde personnalisée et vérifiez si l’intégrité du back-end a désormais l’état Sain.

Erreur de résolution du DNS

Message : Application Gateway n’a pas pu créer de sonde d’intégrité pour ce back-end. Cela se produit généralement quand le nom de domaine complet du back-end n’a pas été entré correctement.

Cause : si le pool principal est de type Adresse IP, FQDN (nom de domaine complet) ou App Service, Application Gateway résout l’adresse IP du FQDN entré à l’aide du DNS (personnalisé ou Azure par défaut). La passerelle d’application tente ensuite de se connecter au serveur sur le port TCP mentionné dans les paramètres HTTP. Toutefois, si ce message s’affiche, cela peut indiquer qu’Application Gateway n’a pas pu résoudre correctement l’adresse IP du nom de domaine complet entré.

Résolution :

Vérifiez que le nom de domaine complet entré dans le pool de back-ends est correct et qu’il s’agit d’un domaine public, puis essayez de le résoudre à partir de votre machine locale.
Si vous réussissez à résoudre l’adresse IP, il y a peut-être un problème avec la configuration DNS dans le réseau virtuel.
Vérifiez si le réseau virtuel est configuré avec un serveur DNS personnalisé. Si c’est le cas, examinez le serveur DNS pour comprendre pourquoi il ne parvient pas à résoudre l’adresse IP du nom de domaine complet spécifié.
Si vous utilisez le DNS par défaut d’Azure, vérifiez dans votre registre d’inscription des noms de domaine que le mappage approprié avec un enregistrement A ou un enregistrement CNAME a été effectué.
Si le domaine est privé ou interne, essayez de le résoudre à partir d’une machine virtuelle dans le même réseau virtuel. Si vous pouvez le résoudre, redémarrez Application Gateway et vérifiez de nouveau. Pour redémarrer Application Gateway, vous devez l’arrêter et le démarrer à l’aide des commandes PowerShell correspondantes (cliquez sur les liens fournis ici pour plus d’informations).

Erreur de connexion TCP

Message : Application Gateway n’a pas pu se connecter au back-end. Vérifiez que le serveur back-end répond sur le port utilisé pour la sonde. Vérifiez également qu’aucun NSG, UDR ou pare-feu ne bloque l’accès à l’adresse IP et au port de ce serveur back-end.

Cause : Après la phase de résolution du DNS, Application Gateway tente de se connecter au serveur back-end sur le port TCP configuré dans les paramètres HTTP. Si Application Gateway ne parvient pas à établir une session TCP sur le port spécifié, la sonde est marquée avec l’état Non sain, avec ce message.

Solution : si cette erreur se produit, effectuez les étapes suivantes :

Essayez de vous connecter au serveur back-end sur le port indiqué dans les paramètres HTTP à l’aide d’un navigateur ou de PowerShell. Par exemple, exécutez la commande suivante : Test-NetConnection -ComputerName www.bing.com -Port 443.
Si le port indiqué n’est pas le port souhaité, entrez le numéro de port approprié à utiliser par Application Gateway pour se connecter au serveur principal.
Si vous ne réussissez pas non plus à vous connecter sur le port à partir de votre machine locale :

a. Vérifiez les paramètres de groupe de sécurité réseau (NSG, network security group) de la carte réseau et du sous-réseau du serveur back-end, et vérifiez si les connexions entrantes sont autorisées sur le port configuré. Si ces connexions ne sont pas autorisées, créez une règle pour les autoriser. Pour savoir comment créer des règles NSG, consultez cette page de documentation.

b. Vérifiez si les paramètres NSG du sous-réseau d’Application Gateway autorisent le trafic public et privé sortant, pour que la connexion puisse être établie. Consultez la page de documentation indiquée à l’étape 3a pour en savoir plus sur la création de règles NSG.
```
        $vnet = Get-AzVirtualNetwork -Name "vnetName" -ResourceGroupName "rgName"
        Get-AzVirtualNetworkSubnetConfig -Name appGwSubnet -VirtualNetwork $vnet
```
c. Vérifiez les paramètres d’Application Gateway relatifs aux routes définies par l’utilisateur (UDR, user-defined route) ainsi que le sous-réseau du serveur back-end pour identifier d’éventuelles anomalies de routage. Assurez-vous que l’UDR ne détourne pas le trafic du sous-réseau du back-end. Vérifiez, par exemple, les routes vers les appliances virtuelles du réseau ou les routes par défaut annoncées sur le sous-réseau d’Application Gateway par le biais d’une connexion Azure ExpressRoute et/ou VPN.

d. Vous pouvez vérifier les règles et routes effectives d’une carte réseau à l’aide des commandes PowerShell suivantes :
```
        Get-AzEffectiveNetworkSecurityGroup -NetworkInterfaceName "nic1" -ResourceGroupName "testrg"
        Get-AzEffectiveRouteTable -NetworkInterfaceName "nic1" -ResourceGroupName "testrg"
```
Si vous ne constatez pas d’erreur au niveau du NSG ou de l’UDR, examinez votre serveur back-end pour identifier d’éventuels problèmes d’application empêchant les clients d’établir une session TCP sur les ports configurés. Voici quelques points à vérifier :

a. Ouvrez une invite de commandes (Win+R-> cmd), entrez netstat, puis appuyez sur Entrée.

b. Vérifiez que le serveur écoute sur le port configuré. Par exemple :
```
        Proto Local Address Foreign Address State PID
        TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 4
```
c. Si le serveur n’écoute pas sur le port configuré, vérifiez les paramètres de votre serveur web. Vérifiez, par exemple, les liaisons de site dans IIS, le bloc serveur dans NGINX et l’hôte virtuel dans Apache.

d. Vérifiez les paramètres de pare-feu du système d’exploitation pour vous assurer que le trafic entrant vers le port est autorisé.

Non-correspondance du code d’état HTTP

Message : le code d’état de la réponse HTTP du back-end ne correspond pas au paramètre de la sonde. Attendu :{HTTPStatusCode0} Reçu :{HTTPStatusCode1}.

Cause : Une fois que la connexion TCP a été établie et que la négociation TLS est terminée (si TLS est activé), Application Gateway envoie la sonde sous forme de requête HTTP GET au serveur back-end. Comme décrit précédemment, la sonde par défaut est envoyée à <protocol>://127.0.0.1:<port>/, et elle considère que les codes d’état de la réponse compris entre 200 et 399 comme étant Sain. Si le serveur retourne un autre code d’état, il est marqué comme Non sain, avec ce message.

Solution : selon le code de réponse du serveur principal, effectuez les étapes appropriées parmi les suivantes. Quelques codes d’état courants sont décrits ici :

Error	Actions
Non-correspondance du code d’état de la sonde d’intégrité : reçu 401	Vérifiez si le serveur back-end nécessite une authentification. Les sondes Application Gateway ne peuvent pas transmettre d’informations d’identification pour l’authentification. Autorisez la réponse « HTTP 401 » dans une correspondance de code d’état de la sonde ou configurez la sonde sur un chemin où le serveur ne nécessite pas d’authentification.
Non-correspondance du code d’état de la sonde d’intégrité : reçu 403	Accès interdit. Vérifiez que l’accès au chemin est autorisé sur le serveur back-end.
Non-correspondance du code d’état de la sonde d’intégrité : reçu 404	Page introuvable. Vérifiez si le chemin du nom d’hôte est accessible sur le serveur back-end. Affectez au paramètre du chemin ou du nom d’hôte une valeur accessible.
Non-correspondance du code d’état de la sonde d’intégrité : reçu 405	Les demandes de sondage d’Application Gateway utilisent la méthode HTTP GET. Vérifiez que votre serveur autorise cette méthode.
Non-correspondance du code d’état de la sonde d’intégrité : reçu 500	Erreur de serveur interne. Vérifiez l’intégrité du serveur back-end et vérifiez si les services sont en cours d’exécution.
Non-correspondance du code d’état de la sonde d’intégrité : reçu 503	Service indisponible. Vérifiez l’intégrité du serveur back-end et vérifiez si les services sont en cours d’exécution.

Si vous pensez que la réponse est légitime et que vous souhaitez qu’Application Gateway considère d’autres codes d’état comme sains, vous pouvez créer une sonde personnalisée. Cette approche est utile dans les situations où le site web back-end nécessite une authentification. Les demandes de sondage échouent, car elles ne contiennent pas d’informations d’identification d’utilisateur. Un code d’état HTTP 401 est alors retourné par le serveur back-end.

Pour créer une sonde personnalisée, effectuez les étapes décrites ici.

Non-correspondance du corps de la réponse HTTP

Message : le corps de la réponse HTTP du serveur principal ne correspond pas au paramètre de la sonde. Le corps de la réponse reçue ne contient pas {string}.

Cause : quand vous créez une sonde personnalisée, vous pouvez marquer un serveur back-end comme Sain en mettant en correspondance une chaîne du corps de la réponse. Par exemple, configurez Application Gateway pour accepter la mise en correspondance de la chaîne « non autorisé ». Si la réponse du serveur principal à la requête de sonde d’intégrité contient la chaîne non autorisé, le serveur est marqué comme Sain. Sinon, il est marqué comme Non sain avec le message donné.

Solution : pour résoudre ce problème, suivez les étapes suivantes :

Accédez au serveur back-end localement ou à partir d’une machine cliente sur le chemin de la sonde et examinez le corps de la réponse.
Vérifiez que le corps de la réponse dans la configuration de la sonde personnalisée d’Application Gateway correspond à ce qui a été configuré.
Si ce n’est pas le cas, modifiez la configuration de la sonde en indiquant la valeur de chaîne correcte à accepter.

Pour en savoir plus sur la correspondance des sondes d’Application Gateway, consultez cette section.

Remarque

Pour tous les messages d’erreur liés au protocole TLS, consultez la page de présentation de TLS afin d’en savoir plus sur le comportement SNI et les différences entre les références SKU v1 et v2.

Le nom commun (CN) ne correspond pas

Message : (pour V2) le nom commun du certificat feuille présenté par le serveur principal ne correspond pas au nom d’hôte de la sonde d’intégrité ou du paramètre principal de la passerelle applicative.
(Pour V1) Le nom commun (CN) du certificat du back-end ne correspond pas.

Cause : (Pour V2) ceci se produit lorsque vous avez sélectionné le protocole HTTPS dans le paramètre principal, et que ni le nom d’hôte de la sonde d’intégrité personnalisée ni celui du paramètre principal (dans cet ordre) ne correspondent au nom commun (CN) du certificat du serveur principal.
(Pour V1) Le nom de domaine complet de la cible du pool de back-end ne correspond pas au nom commun (CN) du certificat du serveur principal.

Solution : les informations du nom d’hôte sont essentielles pour la connexion HTTPS principale, car cette valeur est utilisée pour définir l’indication de nom de serveur (SNI) pendant l’établissement de la liaison TLS. Vous pouvez résoudre ce problème de la manière suivante en fonction de la configuration de votre passerelle.

Pour V2,

Si vous utilisez une sonde d’intégrité par défaut, vous pouvez spécifier un nom d’hôte dans le paramètre principal associé de votre passerelle applicative. Vous pouvez sélectionner « Remplacer avec un nom d’hôte spécifique » ou « Choisir un nom d’hôte à partir de la cible back-end » dans le paramètre principal.
Si vous utilisez une sonde d’intégrité personnalisée, vous pouvez utiliser le champ « hôte » pour spécifier le nom commun du certificat de serveur principal. Sinon, si le paramètre principal est déjà configuré avec le même nom d’hôte, vous pouvez sélectionner « Choisir le nom d’hôte à partir du paramètre principal » dans les paramètres de la sonde d’intégrité.

Pour V1, vérifiez que le nom de domaine complet de la cible du pool principal est identique au nom commun (CN).

Conseils : pour déterminer le nom commun (CN) du ou des serveurs principaux, vous pouvez utiliser l’une de ces méthodes. Notez également que, conformément à la norme RFC 6125 si un réseau SAN existe, la vérification SNI n’est effectuée que sur ce champ. Le champ du nom commun est mis en correspondance s’il n’y a pas de SAN dans le certificat.

À l’aide d’un navigateur ou de n’importe quel client : accédez directement au serveur principal (pas via Application Gateway), puis cliquez sur le cadenas de certificat dans la barre d’adresse pour afficher les détails du certificat. Vous le trouverez sous la section « Délivré à ».
En vous connectant au serveur principal (Windows) :
1. Connectez-vous à la machine qui héberge votre application.
2. Appuyez sur les touches Win+R ou cliquez avec le bouton droit sur le bouton Démarrer, puis sélectionnez Exécuter.
3. Entrez certmgr.msc et appuyez sur Entrée. Vous pouvez également ouvrir le gestionnaire de certificats à partir du menu Démarrer.
4. Recherchez le certificat, qui se trouve généralement dans Certificates - Local Computer\Personal\Certificates, puis ouvrez-le.
5. Dans l’onglet Détails, vérifiez l’objet du certificat sous Objet.
En vous connectant au serveur principal (Linux) : exécutez cette commande OpenSSL en spécifiant le nom de fichier de certificat approprié openssl x509 -in certificate.crt -subject -noout

Le certificat back-end a expiré

Message : le certificat du serveur principal n’est pas valide. La date actuelle ne s’inscrit pas dans la plage de dates définie par les options « Valide à partir du » et « Valide jusqu’au » pour le certificat.

Cause : Un certificat expiré est considéré comme non sain. Par conséquent, la passerelle applicative marque le serveur principal avec un certificat expiré comme non sain.

Solution : la solution dépend de la partie de la chaîne de certificats qui a expiré sur le serveur principal.

Pour la référence SKU V2,

Certificat feuille (également appelé domaine ou serveur) expiré : renouvelez le certificat de serveur auprès du fournisseur de certificats et installez le nouveau certificat sur serveur principal. Vérifiez que vous avez installé la chaîne de certificats complète comprenant Leaf (topmost) > Intermediate(s) > Root. Selon le type d’autorité de certification (CA), vous pouvez effectuer les actions suivantes sur votre passerelle.
- Autorité de certification publique : si l’émetteur de certificat est une autorité de certification connue, vous n’avez pas besoin d’effectuer d’action sur la passerelle d’application.
- Autorité de certification privée : si le certificat feuille est émis par une autorité de certification privée, vous devez vérifier si le certificat d’autorité de certification racine de signature a changé. Si c’est le cas, vous devez charger le nouveau certificat d’autorité de certification racine (. CER) au paramètre principal associé de votre passerelle.
Certificat intermédiaire ou racine expiré : généralement, ces certificats ont des périodes de validité relativement étendues (une décennie ou deux). Lorsque le certificat racine/intermédiaire expire, nous vous recommandons de vérifier auprès de votre fournisseur de certificats pour renouveler les fichiers de certificats. Vérifiez que vous avez installé cette chaîne de certificats mise à jour et complète comprenant Leaf (topmost) > Intermediate(s) > Root sur le serveur principal.
- Si le certificat racine reste inchangé ou si l’émetteur de certificat est une autorité de certification connue, vous n’avez PAS besoin d’effectuer d’action sur la passerelle d’application.
- Lorsque vous utilisez une autorité de certification privée, si le certificat d’autorité de certification racine lui-même ou la racine du certificat intermédiaire renouvelé a changé, vous devez charger le nouveau certificat racine dans le paramètre principal de la passerelle d’application.

Pour la référence SKU V1,

Renouvelez le certificat feuille (également appelé domaine ou serveur) expiré auprès de votre autorité de certification et chargez le même certificat feuille (.CER) sur le paramètre principal associé de votre passerelle d’application.

Le certificat intermédiaire est introuvable

Message : le certificat intermédiaire est manquant dans la chaîne de certificats présentée par le serveur principal. Assurez-vous que la chaîne de certificats est complète et correctement ordonnée sur le serveur principal.

Cause : les certificats intermédiaires ne sont pas installés dans la chaîne de certificats sur le serveur principal.

Solution : un certificat intermédiaire est utilisé pour signer le certificat feuille et est donc nécessaire pour terminer la chaîne. Vérifiez auprès de votre autorité de certification les certificats intermédiaires nécessaires et installez-les sur votre serveur principal. Cette chaîne doit commencer par le certificat du nœud terminal, puis le ou les certificats intermédiaires et enfin le certificat d’autorité de certification racine. Nous vous recommandons d’installer la chaîne complète sur le serveur principal, y compris le certificat d’autorité de certification racine. Pour référence, examinez l’exemple de chaîne de certificats sous Le nœud terminal doit être le plus haut dans la chaîne.

Remarque

Un certificat auto-signé qui n’est PAS une autorité de certification entraîne également la même erreur. Cela est dû au fait que la passerelle applicative considère un tel certificat auto-signé comme certificat « feuille » et recherche son certificat intermédiaire de signature. Vous pouvez suivre cet article pour générer correctement un certificat auto-signé.

Ces images montrent la différence entre les certificats auto-signés.

Le certificat feuille ou de serveur est introuvable

Message : le certificat feuille est manquant dans la chaîne de certificats présentée par le serveur principal. Assurez-vous que la chaîne est complète et correctement ordonnée sur le serveur principal.

Cause : Le certificat Leaf (également appelé domaine ou serveur) est manquant dans la chaîne de certificats sur le serveur principal.

Solution : vous pouvez obtenir le certificat feuille auprès de votre autorité de certification (CA). Installez ce certificat de nœud terminal et tous ses certificats de signature (certificats d’autorité de certification intermédiaire et racine) sur le serveur principal. Cette chaîne doit commencer par le certificat du nœud terminal, puis le ou les certificats intermédiaires et enfin le certificat d’autorité de certification racine. Nous vous recommandons d’installer la chaîne complète sur le serveur principal, y compris le certificat d’autorité de certification racine. Pour référence, examinez l’exemple de chaîne de certificats sous Le nœud terminal doit être le plus haut dans la chaîne.

Le certificat de serveur n’est pas émis par une autorité de certification publiquement connue

Message : le certificat de serveur utilisé par le serveur principal n’est pas signé par une autorité de certification (CA) reconnue. Pour utiliser des certificats d’autorité de certification inconnus, leur certificat racine doit être chargé dans le paramètre principal de la passerelle applicative.

Cause : vous avez choisi « certificat de l’autorité de certification reconnue » dans les paramètres principaux, mais le certificat racine présenté par le serveur principal n’est pas publiquement connu.

Solution : lorsqu’un certificat Leaf est émis par une autorité de certification (CA) privée, le certificat de l’autorité de certification racine signataire doit être chargé dans le paramètre principal associé à la passerelle applicative. Cela permet à votre passerelle applicative d’établir une connexion approuvée avec ce serveur principal. Pour résoudre ce problème, accédez au paramètre du back-end associé, choisissez « Autorité de certification non connue » et chargez le certificat d’autorité de certification racine (.CER). Pour identifier et télécharger le certificat racine, vous pouvez suivre les mêmes étapes que celles décrites dans la section Non-correspondance du certificat racine approuvé.

Le certificat intermédiaire n’est PAS signé par une autorité de certification publiquement connue.

Message : le certificat intermédiaire n’est pas signé par une autorité de certification (CA) reconnue. Assurez-vous que la chaîne de certificats est complète et correctement ordonnée sur le serveur principal.

Cause : vous avez choisi « certificat de l’autorité de certification reconnue » dans les paramètres principaux, mais le certificat intermédiaire présenté par le serveur principal n’est pas signé par une autorité de certification publiquement connue.

Solution : lorsqu’un certificat est émis par une autorité de certification (CA) privée, le certificat de l’autorité de certification racine signataire doit être chargé dans le paramètre principal associé à la passerelle applicative. Cela permet à votre passerelle applicative d’établir une connexion approuvée avec ce serveur principal. Pour résoudre ce problème, contactez votre autorité de certification privée pour obtenir le certificat d’autorité de certification racine (.CER) approprié et chargez ce fichier CER dans le paramètre principal de votre passerelle applicative en sélectionnant « autorité de certification non connue ». Nous vous recommandons également d’installer la chaîne complète sur le serveur principal, y compris le certificat d’autorité de certification racine, pour une vérification plus aisée.

Le certificat racine approuvé ne correspond pas (pas de certificat racine sur le serveur principal)

Message : le certificat intermédiaire n’est pas signé par les certificats racines chargés sur la passerelle applicative. Assurez-vous que la chaîne de certificats est complète et correctement ordonnée sur le serveur principal.

Cause : Aucun des certificats d’autorité de certification racine chargés sur le paramètre principal associé n’a signé le certificat intermédiaire installé sur le serveur principal. Seuls les certificats de nœud terminal et intermédiaires sont installés sur le serveur principal.

Solution : un certificat feuille est signé par un certificat intermédiaire, qui est signé par un certificat d’autorité de certification racine. Quand vous utilisez un certificat provenant d’une autorité de certification privée, vous devez charger le certificat d’autorité de certification racine correspondant dans la passerelle applicative. Contactez votre autorité de certification privée pour obtenir le certificat d’autorité de certification racine approprié (.CER) et chargez ce fichier CER dans le paramètre back-end de votre passerelle applicative.

Le certificat racine approuvé ne correspond pas (le certificat racine est disponible sur le serveur principal)

Message : Le certificat racine du certificat de serveur utilisé par le serveur back-end ne correspond pas au certificat racine approuvé qui a été ajouté dans Application Gateway. Assurez-vous d’ajouter le certificat racine approprié pour faire figurer le serveur back-end dans la liste d’autorisation.

Cause : cette erreur se produit lorsqu’aucun des certificats racines chargés sur le réglage principal de votre passerelle applicative ne correspond au certificat racine présent sur le serveur principal.

Solution : cela s’applique à un certificat de serveur principal émis par une autorité de certification (CA) privée ou auto-signé. Identifiez et chargez le certificat racine de l’autorité de certification approprié dans le paramètre principal associé.

Conseils : pour identifier et télécharger le certificat racine, vous pouvez utiliser l’une de ces méthodes.

À l’aide d’un navigateur : accédez directement au serveur principal (pas via Application Gateway), puis cliquez sur le cadenas de certificat dans la barre d’adresse pour afficher les détails du certificat.
1. Choisissez le certificat racine dans la chaîne, puis cliquez sur Exporter. Par défaut, il s’agit d’un fichier .CRT.
2. Ouvrez ce fichier .CRT.
3. Accédez à l'onglet Détails, puis cliquez sur « Copier vers le fichier »,
4. Sur la page de l’assistant Exportation de certificat, cliquez sur Suivant,
5. Sélectionnez « X.509 encodé en base 64 (.CER) », puis Suivant,
6. Donnez un nouveau nom de fichier puis cliquez sur Next,
7. Cliquez sur Terminer pour obtenir un fichier .CER.
8. Chargez ce certificat racine (.CER) de votre autorité de certification privée sur le paramètre principal de la passerelle applicative.
En vous connectant au serveur principal (Windows)
1. Connectez-vous à la machine qui héberge votre application.
2. Appuyez sur les touches Win+R ou cliquez avec le bouton droit sur le bouton Démarrer, puis sélectionnez Exécuter.
3. Entrez certmgr.msc et appuyez sur Entrée. Vous pouvez également ouvrir le gestionnaire de certificats à partir du menu Démarrer.
4. Recherchez le certificat, qui se trouve généralement dans Certificates - Local Computer\Personal\Certificates, puis ouvrez-le.
5. Sélectionnez le certificat racine, puis sélectionnez Afficher le certificat.
6. Dans les propriétés du certificat, sélectionnez l’onglet Détails puis cliquez sur « Copier vers le fichier »,
7. Sur la page de l’assistant Exportation de certificat, cliquez sur Suivant,
8. Sélectionnez « X.509 encodé en base 64 (.CER) », puis Suivant,
9. Donnez un nouveau nom de fichier puis cliquez sur Next,
10. Cliquez sur Terminer pour obtenir un fichier .CER.
11. Chargez ce certificat racine (.CER) de votre autorité de certification privée sur le paramètre principal de la passerelle applicative.

Le nœud terminal doit être le plus haut placé dans la chaîne.

Message : le certificat feuille n’est pas le plus haut placé dans la chaîne présentée par le serveur principal. Assurez-vous que la chaîne de certificats est correctement ordonnée sur le serveur principal.

Cause : le certificat feuille (également appelé certificat Domaine ou Serveur) n’est pas installé dans le bon ordre sur le serveur principal.

Solution: l’installation du certificat sur le serveur principal doit inclure une liste ordonnée de certificats comprenant le certificat feuille et tous ses certificats de signature (certificats d’autorité intermédiaire et racine). Cette chaîne doit commencer par le certificat feuille, puis le ou les certificats intermédiaires et enfin le certificat racine. Nous vous recommandons d’installer la chaîne complète sur le serveur principal, y compris le certificat d’autorité de certification racine.

Voici un exemple d’installation de certificat de serveur avec ses certificats d’autorité de certification intermédiaire et racine, indiqués par des profondeurs (0, 1, 2, et ainsi de suite) dans OpenSSL. Vous pouvez vérifier la même chose pour le certificat de votre serveur principal à l’aide des commandes OpenSSL suivantes.
s_client -connect <FQDN>:443 -showcerts
OU
s_client -connect <IPaddress>:443 -servername <TLS SNI hostname> -showcerts

Échec de la vérification du certificat

Message : la validité du certificat du serveur principal n’a pas pu être vérifiée Pour en déterminer la raison, examinez le message associé au code d’erreur {errorCode} dans les diagnostics OpenSSL

Cause : Cette erreur se produit quand Application Gateway n’est pas en mesure de vérifier la validité du certificat.

Solution : pour résoudre ce problème, vérifiez que le certificat sur votre serveur a été créé correctement. Par exemple, utilisez OpenSSL pour vérifier le certificat et ses propriétés, puis réessayez de charger le certificat dans les paramètres HTTP d’Application Gateway.

État d’intégrité du serveur principal : Inconnu

Mises à jour des entrées DNS du pool principal

Message : impossible de récupérer l’état d’intégrité du pool principal. Cela se produit quand un NSG/UDR/pare-feu sur le sous-réseau de passerelle applicative bloque le trafic sur les ports 65503 à 65534 dans le cas d’une référence SKU v1 et sur les ports 65200 à 65535 dans le cas d’une référence SKU v2 ou si le nom de domaine complet configuré dans le pool principal n’a pas pu être résolu en adresse IP. Pour en savoir plus, consultez https://aka.ms/UnknownBackendHealth.

Cause : pour les cibles principales basées sur le nom de domaine complet (FQDN), Application Gateway met en cache et utilise la dernière adresse IP connue si elle ne parvient pas à obtenir une réponse pour la recherche DNS suivante. Une opération PUT sur une passerelle dans cet état effacerait complètement son cache DNS. Par conséquent, il n’y aura aucune adresse de destination vers laquelle la passerelle peut atteindre.

Résolution : vérifiez et corrigez les serveurs DNS pour vous assurer qu’ils envoient une réponse pour la recherche DNS du nom de domaine complet donné. Vous devez également vérifier si les serveurs DNS sont accessibles via le réseau virtuel de votre passerelle applicative.

Autres raisons

Si l’état d’intégrité des back-ends est présenté comme Inconnu, la vue du portail est semblable à la capture suivante :

Application Gateway backend health - Unknown

Ce comportement peut être dû à différentes raisons :

Le NSG sur le sous-réseau d’Application Gateway bloque l’accès entrant sur les ports 65503-65534 (SKU v1) ou 65200-65535 (SKU v2) à partir d’« Internet ».
L’UDR sur le sous-réseau Application Gateway est définie en tant que route par défaut (0.0.0.0/0) et le tronçon suivant n’est pas spécifié en tant que « Internet ».
La route par défaut est annoncée par une connexion ExpressRoute/VPN à un réseau virtuel avec le protocole BGP.
Le serveur DNS personnalisé est configuré sur un réseau virtuel qui ne peut pas résoudre les noms de domaine publics.
Application Gateway se trouve dans un état Non sain.

Solution :

Vérifiez si votre NSG bloque l’accès aux ports 65503-65534 (SKU v1) ou 65200-65535 (SKU v2) à partir d’Internet :

a. Dans Application Gateway, sous l’onglet Vue d’ensemble, sélectionnez le lien Réseau/sous-réseau virtuel. b. Dans l’onglet Sous-réseaux de votre réseau virtuel, sélectionnez le sous-réseau où Application Gateway a été déployé. c. Vérifiez si un NSG est configuré. d. Si un NSG est configuré, recherchez cette ressource NSG dans l’onglet Recherche ou sous Toutes les ressources. e. Dans la section Règles de trafic entrant, ajoutez une règle de trafic entrant pour autoriser la plage de ports de destination 65503-65534 pour la référence SKU v1 ou 65200-65535 pour la référence SKU v2, avec le paramètre Source défini en tant qu’étiquette de service GatewayManager. f. Sélectionnez Enregistrer et vérifiez que le back-end apparaît comme Sain. Vous pouvez également faire cette vérification à l’aide de PowerShell/CLI.
Vérifiez si votre UDR a une route par défaut (0.0.0.0/0) avec le tronçon suivant non défini comme Internet :

a. Effectuez les étapes 1a et 1b pour identifier votre sous-réseau. b. Vérifiez si un UDR est configuré. Si c’est le cas, recherchez la ressource dans la barre de recherche ou sous Toutes les ressources. c. Vérifiez la présence de routes par défaut (0.0.0.0/0) avec le tronçon suivant non défini comme Internet. Si le paramètre est Appliance virtuelle ou Passerelle de réseau virtuel, assurez-vous que l’appliance virtuelle ou l’appareil local est en mesure de rediriger correctement le paquet vers la destination Internet sans le modifier. Si les sondes d’intégrité sont routées via une appliance virtuelle et modifiées, la ressource principale affiche un code d’état 200 et l’état d’intégrité d’Application Gateway peut s’afficher comme Inconnu. Cela n’indique pas une erreur. Le trafic doit toujours être routé via Application Gateway sans problème. d. Si ce n’est pas le cas, définissez le tronçon suivant sur Internet, sélectionnez Enregistrer, puis vérifiez l’intégrité du serveur back-end.
Une route par défaut annoncée par la connexion ExpressRoute/VPN au réseau virtuel avec BGP (Border Gateway Protocol) :

a. Si vous avez une connexion ExpressRoute/VPN au réseau virtuel via le protocole BGP et que vous annoncez une route par défaut, vérifiez que le paquet est redirigé correctement vers la destination Internet sans être modifié. Vous pouvez vérifier ce point à l’aide de l’option Résoudre les problèmes de connexion disponible dans le portail Application Gateway. b. Choisissez la destination manuellement (n’importe quelle adresse IP routable sur Internet), par exemple 1.1.1.1. Définissez le port de destination de votre choix, puis vérifiez la connectivité. c. Si le tronçon suivant est une passerelle de réseau virtuel, il y a peut-être une route par défaut annoncée par ExpressRoute ou VPN.
Si un serveur DNS personnalisé est configuré sur le réseau virtuel, vérifiez que les serveurs peuvent résoudre les domaines publics. La résolution des noms de domaines publics peut être nécessaire dans les scénarios où Application Gateway doit accéder à des domaines externes tels que des serveurs OCSP (Online Certificate Status Protocol) ou vérifier l’état de révocation du certificat.
Pour vérifier si Application Gateway est sain et en cours d’exécution, accédez à l’option Intégrité des ressources dans le portail et vérifiez que l’état est Sain. Si l’état est Non sain ou Dégradé, contactez le support.
Si le trafic Internet et privé transite via un pare-feu Azure hébergé dans un hub virtuel sécurisé (utilisant un hub Azure Virtual WAN) :

a. Pour vous assurer que la passerelle applicative peut envoyer le trafic directement à Internet, configurez l’itinéraire défini par l’utilisateur suivant :

Préfixe de l’adresse : 0.0.0.0/0
Tronçon suivant : Internet

b. Pour vous assurer que la passerelle applicative peut envoyer le trafic au pool principal via un pare-feu Azure dans le hub Virtual WAN, spécifiez les routes définies par l’utilisateur suivantes :

Préfixe d’adresse : sous-réseau du pool principal
Tronçon suivant : adresse IP privée du Pare-feu Azure

Étapes suivantes

Apprenez-en davantage sur les diagnostics et la journalisation dans Application Gateway.

Résoudre les problèmes d’intégrité des back-ends dans Application Gateway

Vue d’ensemble

Comment vérifier l’intégrité des back-ends

État d’intégrité du serveur principal : Non sain

Messages d’erreur

Délai d’attente dépassé pour le serveur back-end

Erreur de résolution du DNS

Erreur de connexion TCP

Non-correspondance du code d’état HTTP

Non-correspondance du corps de la réponse HTTP

Le nom commun (CN) ne correspond pas

Le certificat back-end a expiré

Le certificat intermédiaire est introuvable

Le certificat feuille ou de serveur est introuvable

Le certificat de serveur n’est pas émis par une autorité de certification publiquement connue

Le certificat intermédiaire n’est PAS signé par une autorité de certification publiquement connue.

Le certificat racine approuvé ne correspond pas (pas de certificat racine sur le serveur principal)

Le certificat racine approuvé ne correspond pas (le certificat racine est disponible sur le serveur principal)

Le nœud terminal doit être le plus haut placé dans la chaîne.

Échec de la vérification du certificat

État d’intégrité du serveur principal : Inconnu

Mises à jour des entrées DNS du pool principal

Autres raisons

Étapes suivantes

Ressources supplémentaires