Comment résoudre une erreur 502 « The request could not be satisfied » dans CloudFront ?

Résolution

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

Si CloudFront ne parvient pas à résoudre le domaine d'origine, il renvoie l'erreur « The request could not be satisfied ». À moins que votre distribution n'utilise que Amazon Virtual Private Cloud (Amazon VPC) Origins, CloudFront doit être en mesure de résoudre votre domaine d'origine via des requêtes DNS publiques.

Vous n'avez pas besoin de rendre votre origine accessible au public, mais vous devez être en mesure d'interroger publiquement son domaine. Pour résoudre ce problème, utilisez une commande dig ou nslookup pour déterminer si le domaine d'origine correspond à une adresse IP.

Si vous utilisez Linux, exécutez la commande suivante :

dig ORIGIN_DOMAIN_NAME

Si vous utilisez Windows, exécutez la commande suivante :

nslookup ORIGIN_DOMAIN_NAME

Remarque : Remplacez ORIGIN_DOMAIN_NAME par le nom de domaine de votre origine.

Les commandes renvoient 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. Par exemple, vous pouvez utiliser l'outil Vérifier la propagation du DNS sur le site Web de DNS Checker. Vérifiez si les méthodes de vérification ne parviennent pas à interroger votre domaine d’origine. Puis, contactez votre fournisseur de DNS public afin der confirmer qu'il existe un enregistrement DNS pouvant être résolu publiquement pour le domaine d'origine.

Pour d’autres étapes de résolution de problèmes liés au DNS, consultez la section Comment le DNS fonctionne-t-il et comment puis-je résoudre les échecs DNS partiels ou intermittents ?

Le certificat SSL/TLS ne correspond pas au nom de domaine

Le certificat SSL/TLS d'origine doit inclure l'un des noms de domaine suivants :

• Le nom de domaine d'origine indiqué dans le champ Nom commun ou Noms alternatifs d'objet du certificat.
• Le nom de domaine de l'en-tête d'hôte pour les en-têtes d'hôte de l’utilisateur entrant que la requête transmet à l'origine dans la distribution CloudFront.

Pour vérifier la présence du nom commun et des noms alternatifs d’objet 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 : Remplacez DOMAIN par le nom du domaine d'origine et SERVER_DOMAIN par le nom du domaine d'origine. Si la requête transmet l'en-tête d'hôte de l'utilisateur à l'origine, remplacez SERVER_DOMAIN par la valeur de l'en-tête d'hôte entrant.

Vous devez configurer la politique de cache ou la politique de demande d'origine pour inclure l'en-tête d'hôte dans les scénarios suivants :

• Le certificat d'origine inclut la valeur d'en-tête d'hôte de l’utilisateur sous forme de nom commun du certificat SSL/TLS ou de nom alternatif d’objet (SAN).
• La requête ne transmet pas l'en-tête d'hôte à l'origine.

Le certificat d'origine a expiré, n'est pas fiable, est auto-signé ou la chaîne de certificats n'est pas dans le bon ordre

Une autorité de certification (CA) approuvée doit signer le certificat que vous avez installé sur l'origine personnalisée. Pour obtenir la liste des autorités de certification approuvées, consultez la page Autorités de certification sur le site Web de Mozilla. CloudFront ne prend pas en charge les origines qui utilisent des certificats SSL/TLS auto-signés.

Pour vérifier si votre certificat d'origine a expiré, exécutez la commande OpenSSL suivante :

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

Remarque : Remplacez DOMAIN par le nom du domaine d'origine et SERVER_DOMAIN par le nom du domaine d'origine. Si la requête transmet l'en-tête d'hôte de l'utilisateur à l'origine, remplacez SERVER_DOMAIN par la valeur de l'en-tête d'hôte entrant.

Dans la sortie de la commande, recherchez les paramètres Pas avant et Pas après. Vérifiez que la date et l'heure actuelles se situent dans la période de validité du certificat.

L'absence de certificats CA intermédiaires ou l'ordre incorrect des certificats intermédiaires entraînent l'échec de la communication entre 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 : Remplacez DOMAIN par le nom du domaine d'origine et SERVER_DOMAIN par le nom du domaine d'origine. Si la requête transmet l'en-tête d'hôte de l'utilisateur à l'origine, remplacez SERVER_DOMAIN par la valeur de l'en-tête d'hôte entrant.

Pour plus d'informations, consultez la section Exigences relatives à l'utilisation de certificats SSL/TLS avec CloudFront.

CloudFront ne prend pas en charge la suite de chiffrement de l'origine

Les transactions SSL/TLS entre CloudFront et l'origine échouent lorsqu'il n'existe pas de suite de chiffrement négociée commune. Pour résoudre ce problème, vous devez utiliser des protocoles et des chiffrements pris en charge.

Utilisez un outil de test de serveur SSL pour vérifier si la liste des chiffrements pris en charge inclut la suite de chiffrement de votre origine. Par exemple, vous pouvez utiliser le test de serveur SSL sur le site Web de Qualys.

Il existe des problèmes d'origine en amont

Vous pouvez utiliser un nom d'hôte du réseau de diffusion de contenu (CDN) proxy ou un équilibreur de charge connecté à l'origine en tant qu'origine personnalisée dans la distribution CloudFront. Si l'un de ces services intermédiaires ne parvient pas à se connecter à l'origine, vous recevez une erreur 502. Pour résoudre ce problème, contactez votre fournisseur de services d'origine.

Si vous utilisez un Application Load Balancer comme origine, consultez la section Comment résoudre les erreurs HTTP 502 de l'Application Load Balancer ?

Si vous utilisez Amazon API Gateway, consultez la section Comment résoudre les erreurs HTTP 502 provenant des API REST API Gateway avec intégration de proxy Lambda ?

La fonction Lambda@Edge associée à la distribution CloudFront a échoué à 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, vérifiez que votre fonction Lambda@Edge ne présente pas les problèmes suivants :

• L'objet JSON est renvoyé.
• Les champs obligatoires sont manquants.
• Les objets de la réponse ne sont pas valides.
• La possibilité d'ajouter ou de mettre à jour n'est pas autorisée.
• Les en-têtes sont en lecture seule.
• Vous avez dépassé la taille maximale.
• Les caractères ou les valeurs ne sont pas valides.

Pour résoudre ces problèmes, consultez la section Tester et déboguer les fonctions Lambda@Edge. Consultez également la section Comment résoudre les erreurs 502 et 503 provoquées par les fonctions Lambda@Edge dans CloudFront ?