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

Dernière mise à jour : 22/06/2022

J'ai configuré une distribution Amazon CloudFront avec un domaine personnalisé. Lorsque je demande le domaine Enregistrement de nom canonique (CNAME) alternatif via CloudFront, je reçois une réponse d'erreur 502 avec le message « The request could not be satisfied » (La requête n'a pas pu être satisfaite). Comment puis-je résoudre cette erreur ?

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 et génère une erreur 502. Pour résoudre ce problème, confirmez que la configuration du protocole de distribution CloudFront est défini 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, ce qui génère une erreur 502. Consultez les sections suivantes pour connaître les causes de l'échec d'une transaction SSL/TLS et 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.
  • Si l'en-tête d’hôte visionneur entrant est transféré à l'origine dans la distribution CloudFront, le certificat d'origine doit inclure ou couvrir le domaine de l'en-tête d’hôte.

Pour vérifier Common Name (Nom commun) et 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 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 visionneur entrant.

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

  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 Mozilla sur le site internet 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 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 visionneur 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

La transaction SSL/TLS entre CloudFront et l’origine échoue 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 le nom de domaine d'origine figure dans la liste des chiffrements pris en charge.

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

Si CloudFront ne peut pas à 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 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 ne peut pas à se connecter à l'origine, une erreur 502 est renvoyée à CloudFront. Pour résoudre ce problème, contactez votre prestataire 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.


Cet article vous a-t-il été utile ?


Avez-vous besoin d'aide pour une question technique ou de facturation ?