Comment résoudre une erreur 502 : « The request could not be satisfied » (La requête n'a pas pu être satisfaite) de CloudFront ?

Brève description

Une erreur 502 se produit lorsque CloudFront ne peut pas à se connecter à l'origine. Consultez les sections suivantes pour connaître les causes de l'erreur et la procédure de résolution des problèmes.

Solution

CloudFront ne peut pas établir de connexion TCP avec le serveur d'origine

Par défaut, CloudFront se connecte à l'origine via le port 80 (pour HTTP) et le port 443 (pour HTTPS). Si l'origine n'autorise pas le trafic sur ces ports ou bloque la connexion de l'adresse IP CloudFront, la connexion TCP échoue. L'échec génère une erreur 502. Pour résoudre ce problème, confirmez que la configuration du protocole de la distribution CloudFront est définie sur le port approprié pour les connexions HTTP ou HTTPS.

Pour tester la connectivité du port, exécutez la commande suivante :

telnet ORIGIN_DOMAIN/ORIGIN_IP PORT

Remarque : pourORIGIN_DOMAIN, saisissez l'ID de votre domaine d'origine. PourORIGIN_IP, saisissez l'adresse IP de votre origine. PourPORT, saisissez le numéro de port que vous utilisez pour vous connecter à l'origine.

La négociation SSL/TLS avec le serveur d'origine a échoué

Si la transaction SSL/TLS échoue, la connexion entre CloudFront et l'origine échoue et génère une erreur 502. Consultez les sections suivantes pour connaître les causes de l'échec d'une transaction SSL/TLS et savoir comment le résoudre.

Le certificat SSL ne correspond pas au nom de domaine

Le certificat SSL à l'origine doit inclure ou couvrir l'un des noms de domaine suivants :

• Le nom de domaine d'origine dans le champ Common Name (Nom commun) ou Subject Alternative Names (Noms d'objet alternatifs) du certificat.
• Le nom de domaine de l'en-tête d'hôte pour les en-têtes d'hôtes visionneurs entrants qui sont transférés vers l'origine de la distribution CloudFront.

Pour vérifier le Common Name (Nom commun) et les Subject Alternative Names (Noms d'objet alternatifs) dans le certificat, exécutez la commande suivante :

$ openssl s_client -connect DOMAIN:443 -servername SERVER_DOMAIN | openssl x509 -text | grep -E '(CN|Alternative)' -A 2

Remarque : pour DOMAIN, saisissez le nom du domaine d'origine. Pour SERVER_DOMAIN, saisissez le nom de domaine d'origine. Ou, si l'en-tête d'hôte visionneur est transféré à l'origine, pour SERVER_DOMAIN, saisissez la valeur de l'en-tête d'hôte entrant.

Si les éléments suivants sont vrais, configurez la politique de cache ou la politique de requête d'origine pour inclure l'en-tête d'hôte :

1. Le nom commun ou le réseau de stockage (SAN) du certificat SSL inclut la valeur de l'en-tête d'hôte visionneur.
2. L'en-tête d'hôte n'est pas transféré à l'origine.

Le certificat d'origine a expiré, n'est pas fiable ou est auto-signé

Le certificat installé sur l'origine personnalisée doit être signé par une autorité de certification approuvée. Les autorités de certification approuvées par CloudFront se trouvent sur la liste des certificats CA inclus dans Mozilla sur le site web de Mozilla.

CloudFront ne prend pas en charge les certificats auto-signés pour SSL configurés avec l'origine. Les certificats auto-signés sont émis par les organisations elles-mêmes ou générés localement sur un serveur Web au lieu d'être émis par une autorité de certification approuvée.

Pour vérifier si votre certificat d'origine a expiré, exécutez la commande OpenSSL suivante. Dans la sortie, recherchez les paramètres Not Before (Pas avant) et Not After (Pas après). Vérifiez que la date et l'heure actuelles soient comprises dans la période de validité du certificat.

$ openssl s_client -connect DOMAIN:443 -servername SERVER_DOMAIN | openssl x509 -text | grep Validity -A 3

Remarque : pour DOMAIN, saisissez le nom du domaine d'origine. Pour SERVER_DOMAIN, saisissez le nom de domaine d'origine. Ou, si l'en-tête d'hôte visionneur est transféré à l'origine, pour SERVER_DOMAIN, saisissez la valeur de l'en-tête d'hôte entrant.

L'absence de certificats de l'autorité de certification (CA) intermédiaires ou l'ordre incorrect des certificats intermédiaires entraîne un échec entre la communication HTTPS et l'origine. Pour vérifier la chaîne de certificats, exécutez la commande suivante.

$ openssl s_client -showcerts -connect DOMAIN:443 -servername SERVER_DOMAIN

Remarque : pour DOMAIN, saisissez le nom du domaine d'origine et pour SERVER_DOMAIN, saisissez le nom du domaine d'origine. Ou, si l'en-tête d'hôte visionneur est transféré à l'origine, pour SERVER_DOMAIN, saisissez la valeur de l'en-tête d'hôte entrant.

La suite de chiffrement de l'origine n'est pas prise en charge par CloudFront

Les transactions SSL/TLS entre CloudFront et l'origine échouent s'il n'existe aucune suite de chiffrement négociée commune. Pour vérifier que vous utilisez la bonne suite de chiffrement, consultez Protocoles et chiffrements pris en charge entre CloudFront et l'origine.

Vous pouvez également utiliser un outil de test de serveur SSL pour vérifier si votre nom de domaine d'origine figure dans la liste des chiffrements pris en charge.

CloudFront ne parvient pas à résoudre l'adresse IP d'origine

Si CloudFront est incapable de résoudre le domaine d'origine, il renvoie l'erreur 502. Pour résoudre ce problème, utilisez une commande dig/nslookup pour vérifier si le domaine d'origine est résolu en une IP.

Linux :

$ dig ORIGIN_DOMAIN_NAME

Windows :

nslookup ORIGIN_DOMAIN_NAME

Remarque : pour ORIGIN_DOMAIN_NAME, saisissez le nom de domaine d'origine.

En cas de succès, la commande renvoie l'adresse IP du nom de domaine d'origine. Utilisez un outil de vérification DNS pour vérifier la résolution DNS dans différentes zones géographiques.

L'erreur est provoquée par l'origine en amont

L'origine personnalisée définie dans la distribution CloudFront peut être un proxy, un nom d'hôte de réseau de diffusion de contenu (CDN) ou un équilibreur de charge connecté à l'origine réelle. Si l'un de ces services intermédiaires est incapable de se connecter à l'origine, une erreur 502 est renvoyée à CloudFront. Pour résoudre ce problème, contactez votre fournisseur de services.

La fonction Lambda@Edge associée à la distribution CloudFront a échoué lors de la validation

Si la fonction Lambda@Edge renvoie une réponse non valide à CloudFront, CloudFront renvoie une erreur 502. Pour résoudre ce problème, recherchez les problèmes courants suivants de la fonction Lambda@Edge :

• Objet JSON renvoyé
• Champs obligatoires manquants
• Objet non valide dans la réponse
• Ajout ou mise à jour interdits ou en-têtes en lecture seule
• Dépassement de la taille de corps maximale
• Caractères ou valeurs non valides

Pour plus d'informations, consultez la section Test et débogage des fonctions Lambda@Edge.

---