502 "Erreur" La requête n'a pas pu être satisfaite. " pour certaines URL
Nous avons une distribution Cloudfront avec Origin personnalisée qui fonctionne très bien depuis assez longtemps et qui gère des actifs statiques pour l'un de nos sites. Ce matin encore, nous avons remarqué que notre logo était affiché sous forme de lien brisé.
Après une enquête plus approfondie, Cloudfront renvoie un message d'erreur étrange que je n'ai jamais vu auparavant pour l'URL en question :
ERREUR
La demande n'a pas pu être satisfaite.
Généré par cloudfront (CloudFront)
Plusieurs autres URL Cloudfront de cette distribution renvoient la même erreur, mais d'autres (encore une fois, de la même distribution) fonctionnent parfaitement. Je ne vois pas de modèle à ce qui fonctionne et ce qui ne fonctionne pas.
Quelques autres points de données:
- Les URL d'origine fonctionnent parfaitement. À ma connaissance, il n'y a pas eu d'interruption récente du service.
- J'ai invalidé l'URL du logo spécifiquement, sans effet.
- J'ai invalidé l'URL racine de la distribution, sans effet.
Une idée de ce qui se passe ici? Je n'ai jamais vu Cloudfront faire cela auparavant.
METTRE À JOUR:
Voici la réponse HTTP textuelle de Cloudfront:
$ http GET https://d2yu7foswg1yra.cloudfront.net/static/img/crossway_logo.png
HTTP/1.1 502 Bad Gateway
Age: 213
Connection: keep-alive
Content-Length: 472
Content-Type: text/html
Date: Wed, 18 Dec 2013 17:57:46 GMT
Server: CloudFront
Via: 1.1 f319e8962c0268d31d3828d4b9d41f98.cloudfront.net (CloudFront)
X-Amz-Cf-Id: H_HGBG3sTOqEomHzHubi8ruLbGXe2MRyVhGBn4apM0y_LjQa_9W2Jg==
X-Cache: Error from cloudfront
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML><HEAD><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>ERROR: The request could not be satisfied</TITLE>
</HEAD><BODY>
<H1>ERROR</H1>
<H2>The request could not be satisfied.</H2>
<HR noshade size="1px">
</BODY></HTML>
<BR clear="all">
<HR noshade size="1px">
<ADDRESS>
Generated by cloudfront (CloudFront)
</ADDRESS>
</BODY></HTML>
J'ai eu un problème similaire récemment qui s'est avéré être dû à ssl_ciphers que j'utilisais.
"CloudFront transmet les demandes HTTPS au serveur Origin à l'aide des protocoles SSLv3 ou TLSv1 et des chiffrements AES128-SHA1 ou RC4-MD5. Si votre serveur Origin ne prend pas en charge les cryptages AES128-SHA1 ou RC4-MD5, CloudFront ne peut pas établir de connexion SSL à votre origine . "
J'ai dû modifier ma configuration pour ajouter AES128-SHA (obsolète RC4: HIGH) à ssl_ciphers afin de corriger l'erreur 302. J'espère que ça aide. J'ai collé la ligne de mon fichier ssl.conf
ssl_ciphers ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DH+3DES:RSA+3DES:AES128-SHA:!ADH:!AECDH:!MD5;
J'ai eu cette erreur aujourd'hui avec Amazon Cloudfront. C'est parce que le cname que j'ai utilisé (par exemple, cdn.example.com) n'a pas été ajouté aux paramètres de distribution sous "autres noms de fichiers". vous devez également l'ajouter au panneau Amazon CloudFront.
Trouvé ma réponse et l'ajouter ici au cas où cela pourrait aider David (et d'autres).
Il s'avère que mon serveur Origin (par exemple www.example.com) avait une configuration de redirection 301 permettant de modifier HTTP en HTTPS:
HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/images/Foo_01.jpg
Cependant, ma stratégie de protocole d'origine était définie sur HTTP uniquement. Cela a conduit CloudFront à ne pas trouver mon fichier et à générer une erreur 502. De plus, je pense que l'erreur 502 a été mise en mémoire cache pendant environ 5 minutes, car elle ne fonctionnait pas immédiatement après la suppression de la redirection 301.
J'espère que cela pourra aider!
Dans notre cas, tout semblait OK, mais il a fallu presque toute la journée pour comprendre ceci:
TLDR: Vérifiez les chemins de vos certificats pour vous assurer que le certificat racine est correct. Dans le cas des certificats COMODO, il devrait indiquer "USERTrust" et être émis par "AddTrust External CA Root". PAS "COMODO" émis par "l'autorité de certification COMODO RSA".
Dans les documents CloudFront: http://docs.aws.Amazon.com/AmazonCloudFront/latest/DeveloperGuide/SecureConnections.html
Si le serveur d'origine renvoie un certificat non valide ou un certificat auto-signé, ou si le serveur d'origine renvoie la chaîne de certificats dans le mauvais ordre, CloudFront interrompt la connexion TCP, renvoie le code d'erreur HTTP 502 et définit le paramètre X- En-tête de cache pour Error from cloudfront.
Nous avions les codes corrects activés selon: http://docs.aws.Amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html#RequestCustomEncryption
Notre certificat était valide selon Google, Firefox et ssl-checker: https://www.sslshopper.com/ssl-checker.html
Cependant, le dernier certificat de la chaîne du vérificateur SSL était "Autorité de certification du serveur sécurisé de validation de domaine COMA RSA", émis par "l'autorité de certification COMODO RSA".
Il semble que CloudFront ne détienne pas le certificat pour "Autorité de certification COMODO RSA" et pense donc que le certificat fourni par le serveur Origin est auto-signé.
Cela fonctionnait longtemps avant de s’arrêter soudainement. Ce qui s’est passé, c’est que je venais de mettre à jour nos certificats pour l’année, mais lors de l’importation, quelque chose a été modifié dans le chemin du certificat pour tous les certificats précédents. Ils ont tous commencé à faire référence à "Autorité de certification COMODO RSA" alors qu'avant, la chaîne était plus longue et la racine était "AddTrust External CA Root".
De ce fait, le retour à l'ancien certificat n'a pas résolu le problème de cloudfront.
J'ai dû supprimer le certificat supplémentaire nommé "Autorité de certification COMODO RSA", celui qui ne faisait pas référence à AddTrust. Cela fait, les chemins de tous les certificats de mon site Web sont mis à jour pour renvoyer à AddTrust/USERTrust. Remarque peut également ouvrir le certificat racine incorrect depuis le chemin, cliquez sur "Détails" -> "Modifier les propriétés", puis désactivez-le de cette façon. Cela a mis à jour le chemin immédiatement. Vous devrez peut-être également supprimer plusieurs copies du certificat, qui se trouvent sous "Personnel" et "Autorités de certification racines de confiance".
Enfin, je devais re-sélectionner le certificat dans IIS pour qu'il serve la nouvelle chaîne de certificats.
Après tout cela, ssl-checker a commencé à afficher un troisième certificat dans la chaîne, qui renvoyait à "AddTrust External CA Root".
Enfin, CloudFront a accepté le certificat du serveur d'origine et la chaîne fournie comme étant approuvés. Notre CDN a recommencé à fonctionner correctement!
Pour éviter que cela ne se produise à l'avenir, nous devrons exporter nos certificats nouvellement générés à partir d'une machine disposant de la chaîne de certificats appropriée, par exemple, méfier ou supprimer le certificat "Autorité de certification COMODO RSA" délivré par "Autorité de certification COMODO RSA" (expirant en 2038). ). Cela ne semble affecter que les machines Windows, où ce certificat est installé par défaut.
Une autre solution possible: j'ai un serveur de transfert qui dessert le site et les actifs de Cloudfront via HTTP. J'avais mon origine réglé sur "Match Viewer" au lieu de "HTTP uniquement". J'utilise également l'extension HTTPS Everywhere, qui redirige toutes les URL http://*.cloudfront.net vers la version https://*. Le serveur de transfert n'étant pas disponible via SSL et que Cloudfront correspondait au visualiseur, il n'a pas pu trouver les ressources à https://example.com et a mis en cache un lot de 502.
Dans mon cas, c'était parce que nous avions un certificat SSL invalide. Le problème était sur notre boîte de préparation et nous utilisons notre cert cert sur ce point également. Cela avait fonctionné ces deux dernières années avec cette configuration, mais tout à coup, nous avons commencé à avoir cette erreur. Étrange.
Si d'autres personnes rencontrent cette erreur, vérifiez que le certificat SSL est valide. Vous pouvez activer la journalisation sur s3 via l'interface de distribution AWS CloudFront pour faciliter le débogage.
Vous pouvez également consulter la documentation d'Amazon à ce sujet ici: http://docs.aws.Amazon.com/AmazonCloudFront/latest/DeveloperGuide/SecureConnections.html
Je viens juste de résoudre ce problème, et dans mon cas, il était effectivement lié à des redirections, mais pas à des paramètres incorrects dans mon origine ou mon comportement CloudFront. Cela se produira si votre serveur Origin est redirige toujours vers les URL Origin, et non ce que vous avez configuré pour vos URL Cloudfront . Cela semble être très courant si vous oubliez de changer de configuration. Par exemple, disons que si vous avez www.yoursite.com CNAME dans votre distribution Cloudfront, avec une origine de www.yoursiteorigin.com. Évidemment, les gens viendront sur www.votresite.com. Mais si votre code essaie de rediriger vers une page de www.votresiteorigin.com, vous obtiendrez cette erreur.
Pour moi, mon origine faisait toujours les redirections http-> https vers mes URL d'origine et non mes URL Cloudfront.
Dans notre cas, nous avions abandonné la prise en charge de SSL3, TLS1.0 et TLS1.1 pour la conformité PCI-DSS sur nos serveurs Origin. Cependant, vous devez ajouter manuellement la prise en charge de TLS 1.1+ sur votre configuration de serveur CloudFront Origin . La console AWS affiche les paramètres SSL client-à-CF, mais ne vous montre pas facilement les paramètres de CF à l'origine tant que vous n'êtes pas au point. Pour résoudre ce problème, dans la console AWS sous CloudFront:
- Cliquez sur DISTRIBUTIONS.
- Sélectionnez votre distribution.
- Cliquez sur l'onglet ORIGINS.
- Sélectionnez votre serveur d'origine.
- Cliquez sur EDIT.
- Sélectionnez tous les protocoles pris en charge par votre origine sous "Protocoles SSL d'origine".
J'ai rencontré ce problème, qui s'est résolu après avoir cessé d'utiliser un proxy. Peut-être que CloudFront liste noire certaines adresses IP.
Correction de ce problème en concaténant mes certificats pour générer une chaîne de certificats valide (à l'aide de GoDaddy Standard SSL + Nginx).
http://nginx.org/en/docs/http/configuring_https_servers.html#chains
Pour générer la chaîne:
cat 123456789.crt Gd_bundle-g2-g1.crt > my.domain.com.chained.crt
Ensuite:
ssl_certificate /etc/nginx/ssl/my.domain.com.chained.crt;
ssl_certificate_key /etc/nginx/ssl/my.domain.com.key;
J'espère que ça aide!
Dans mon cas, j'utilise nginx en tant que proxy inverse pour une URL de passerelle API. J'ai la même erreur.
J'ai résolu le problème en ajoutant les deux lignes suivantes à la configuration de Nginx:
proxy_set_header Host "XXXXXX.execute-api.REGION.amazonaws.com";
proxy_ssl_server_name on;
La source est ici: Configuration de proxy_pass sur nginx pour passer des appels API à API Gateway
Le problème, dans mon cas, était que j'utilisais simultanément Cloudflare d'Amazon et Cloudfront, et que Cloudfront n'aimait pas les paramètres que j'avais fournis à Cloudflare.
Plus spécifiquement, dans les paramètres Crypto sur Cloudflare, j'avais défini les "Paramètres TLS minimum" sur 1.2, sans activer le paramètre de communication TLS 1.2 pour la distribution dans Cloudfront. Cela a suffi pour que Cloudfront déclare une erreur 502 Bad Gateway lorsqu'elle a tenté de se connecter au serveur protégé par Cloudflare.
Pour résoudre ce problème, j'ai dû désactiver la prise en charge de SSLv3 dans les paramètres d'origine pour cette distribution Cloudfront et activer TLS 1.2 en tant que protocole pris en charge pour ce serveur d'origine.
Pour résoudre ce problème, j'ai utilisé des versions en ligne de commande de curl, pour voir ce que Cloudfront renvoyait en réalité lorsque vous demandiez une image de son CDN, et j'ai également utilisé la version en ligne de commande de openssl pour déterminer exactement les protocoles utilisés par Cloudflare offrant (ce n’était pas offrir TLS 1.0).
tl: dr; assurez-vous que tout accepte et demande TLS 1.2, ou ce que tout le monde utilise de plus récent et le meilleur TLS au moment où vous lisez ceci.