it-swarm.com.de

Benutzerdefinierte Origin-Verteilung von Cloudfront gibt 502 "FEHLER Die Anforderung konnte nicht erfüllt werden." für einige URLs

Wir haben eine Cloudfront-Distribution mit benutzerdefiniertem Origin, die seit geraumer Zeit einwandfrei funktioniert und statische Assets für eine unserer Websites bereitstellt. Erst heute Morgen haben wir festgestellt, dass unser Logo als defekter Link angezeigt wird.

Nach weiteren Untersuchungen gibt Cloudfront eine seltsame Fehlermeldung zurück, die ich noch nie für die fragliche URL gesehen habe :

ERROR

Die Anfrage konnte nicht erfüllt werden.



Generiert von Cloudfront (CloudFront)

Einige andere Cloudfront-URLs aus dieser Distribution geben den gleichen Fehler zurück, aber andere (wiederum aus derselben Distribution) funktionieren einwandfrei. Ich sehe kein Muster dafür, was funktioniert und was nicht.

Einige andere Datenpunkte:

  • Die Origin-URLs funktionieren einwandfrei. Meines Wissens gab es in letzter Zeit keine Unterbrechung des Dienstes. 
  • Ich habe die Logo-URL speziell ungültig gemacht, jedoch ohne Wirkung.
  • Ich habe die Stamm-URL der Distribution ungültig gemacht, jedoch ohne Wirkung.

Irgendeine Idee, was hier los ist? Ich habe Cloudfront noch nie so gesehen.

UPDATE:

Hier ist die ausführliche HTTP-Antwort von 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>
62
David Eyk

Ich hatte kürzlich ein ähnliches Problem, das sich aufgrund der verwendeten ssl_ciphers herausstellte. 

Von http://docs.aws.Amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html

"CloudFront leitet HTTPS-Anforderungen über die Protokolle SSLv3 oder TLSv1 und die Verschlüsselungscodes AES128-SHA1 oder RC4-MD5 an den Origin-Server weiter. Wenn Ihr Origin-Server die Verschlüsselungscodes AES128-SHA1 oder RC4-MD5 nicht unterstützt, kann CloudFront keine SSL-Verbindung herstellen zu Ihrem Ursprung . "

Ich musste mein nginx-confg ändern, um AES128-SHA (veraltete RC4: HIGH) zu ssl_ciphers hinzuzufügen, um den Fehler 302 zu beheben. Ich hoffe das hilft. Ich habe die Zeile aus meiner ssl.conf eingefügt 

ssl_ciphers ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DH+3DES:RSA+3DES:AES128-SHA:!ADH:!AECDH:!MD5;
31
dminer

Ich hatte diesen Fehler heute bei Amazon Cloudfront. Dies war darauf zurückzuführen, dass der von mir verwendete cname (z. B. cdn.example.com) nicht zu den Verteilungseinstellungen unter "alternative cnames" hinzugefügt wurde. Ich hatte jedoch nur cdn.example.com zur Cloudfront-Domäne in meinem Site/Hosting-Steuerungsfeld weitergeleitet Sie müssen es auch zu Amazon CloudFront-Panel hinzufügen.

125
adrianTNT

Ich habe meine Antwort gefunden und sie hier hinzugefügt, falls sie David (und anderen) hilft.

Es stellte sich heraus, dass auf meinem Origin-Server (z. B. www.example.com) eine 301-Weiterleitung eingerichtet war, um HTTP in HTTPS zu ändern:

HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/images/Foo_01.jpg

Meine Origin-Protokollrichtlinie wurde jedoch nur auf HTTP festgelegt. Dies führte dazu, dass CloudFront meine Datei nicht fand und einen Fehler 502 auslöste. Außerdem glaube ich, dass der Fehler 502 für 5 Minuten zwischengespeichert wurde, da er nach dem Entfernen der 301-Weiterleitung nicht sofort funktioniert hat.

Hoffentlich hilft das!

13
Shawn Dube

In unserem Fall sah alles OK aus, aber es dauerte fast den ganzen Tag, um das herauszufinden:

TLDR: Überprüfen Sie Ihre Zertifikatpfade, um sicherzustellen, dass das Stammzertifikat korrekt ist. Bei COMODO-Zertifikaten sollte "USERTrust" stehen und von "AddTrust External CA Root" ausgestellt werden. NICHT "COMODO", ausgestellt von "COMODO RSA Certification Authority".

Aus den CloudFront-Dokumenten: http://docs.aws.Amazon.com/AmazonCloudFront/latest/DeveloperGuide/SecureConnections.html

Wenn der Origin-Server ein ungültiges Zertifikat oder ein selbstsigniertes Zertifikat zurückgibt oder wenn der Origin-Server die Zertifikatkette in der falschen Reihenfolge zurückgibt, bricht CloudFront die Verbindung TCP ab, gibt den HTTP-Fehlercode 502 zurück und legt den X-Code fest. Cache-Header in Fehler von Cloudfront.

Wir hatten die richtigen Chiffren aktiviert wie folgt: http://docs.aws.Amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html#RequestCustomEncryption

Unser Zertifikat war laut Google, Firefox und SSL-Checker gültig: https://www.sslshopper.com/ssl-checker.html

SSL Checker result without all required certificates

Das letzte Zertifikat in der SSL-Überprüfungskette war jedoch "COMODO RSA Domain Validation Secure Server CA", ausgestellt von "COMODO RSA Certification Authority".

Es scheint, dass CloudFront das Zertifikat für "COMODO RSA Certification Authority" nicht besitzt und ist daher der Meinung, dass das vom Origin-Server bereitgestellte Zertifikat selbstsigniert ist.

Dies funktionierte lange Zeit, bevor es scheinbar plötzlich zum Stillstand kam. Was passiert ist, war, ich hatte gerade unsere Zertifikate für das Jahr aktualisiert, aber während des Imports wurde im Zertifikatpfad für alle vorherigen Zertifikate etwas geändert. Sie begannen alle, auf "COMODO RSA Certification Authority" zu verweisen, während die Kette zuvor länger war und die Wurzel "AddTrust External CA Root" war.

Bad certificate path

Aus diesem Grund wurde das Cloudfront-Problem durch das Umschalten auf das ältere Zertifikat nicht behoben. 

Ich musste das zusätzliche Zertifikat mit dem Namen "COMODO RSA Certification Authority" löschen, das sich nicht auf AddTrust bezieht. Danach wurden alle Pfade meiner Websitezertifikate aktualisiert, sodass sie wieder auf AddTrust/USERTrust verweisen. Hinweis kann auch das fehlerhafte Stammzertifikat über den Pfad öffnen. Klicken Sie auf "Details" -> "Eigenschaften bearbeiten" und deaktivieren Sie es auf diese Weise. Dies hat den Pfad sofort aktualisiert. Möglicherweise müssen Sie auch mehrere Kopien des Zertifikats löschen, die sich unter "Persönlich" und "Vertrauenswürdige Stammzertifizierungsstellen" befinden.

Good certificate path

Schließlich musste ich das Zertifikat in IIS erneut auswählen, damit es die neue Zertifikatkette bedienen kann.

Nach all dem zeigte ssl-checker ein drittes Zertifikat in der Kette an, das wieder auf "AddTrust External CA Root" verweist.

SSL Checker with all certificates

Schließlich akzeptierte CloudFront das Zertifikat des Origin-Servers und die bereitgestellte Kette als vertrauenswürdig. Unser CDN hat wieder richtig funktioniert!

Um dies in Zukunft zu verhindern, müssen wir unsere neu generierten Zertifikate von einer Maschine mit der richtigen Zertifikatkette exportieren, dh Misstrauen oder das Zertifikat "COMODO RSA Certification Authroity" löschen, das von "COMODO RSA Certification Authroity" ausgestellt wurde (bis 2038 ausläuft) ). Dies scheint nur Windows-Computer zu betreffen, auf denen dieses Zertifikat standardmäßig installiert ist.

7
Eddie Loeffen

Eine weitere mögliche Lösung: Ich habe einen Staging-Server, der die Site und die Cloudfront-Assets über HTTP bedient. Ich hatte mein Origin auf "Match Viewer" anstelle von "HTTP Only" gesetzt. Ich verwende auch die HTTPS Everywhere-Erweiterung, die alle http://*.cloudfront.net-URLs zur https://*-Version umleitete. Da der Staging-Server nicht über SSL verfügbar ist und Cloudfront mit dem Viewer übereinstimmt, konnte er die Assets unter https://example.com nicht finden und stattdessen eine Reihe von 502s zwischengespeichert.

2
Devin

In meinem Fall war es, weil wir ein ungültiges SSL-Zertifikat hatten. Das Problem lag auf unserer Bereitstellungsbox und wir verwenden auch unser prod cert. Es hatte in den letzten Jahren mit dieser Konfiguration funktioniert, aber plötzlich kamen wir auf diesen Fehler. Seltsam.

Wenn andere Benutzer diesen Fehler erhalten, überprüfen Sie, ob das SSL-Zertifikat gültig ist. Sie können die Protokollierung in s3 über die AWS CloudFront Distribution-Schnittstelle aktivieren, um das Debugging zu unterstützen. 

Außerdem können Sie sich hier auf die Dokumente von Amazon beziehen: http://docs.aws.Amazon.com/AmazonCloudFront/latest/DeveloperGuide/SecureConnections.html

2
Peter P.

Ich habe gerade die Problembehandlung durchgegangen, und in meinem Fall bezog sich dies tatsächlich auf Weiterleitungen, jedoch nicht auf falsche Einstellungen in meinem CloudFront Origin oder Verhalten. Dies geschieht, wenn Ihr Origin-Server noch auf Origin-URLs umleitet und nicht das, was Sie für Ihre Cloudfront-URLs eingerichtet haben. Dies scheint sehr häufig zu sein, wenn Sie vergessen, die Konfiguration zu ändern. Nehmen wir zum Beispiel an, Sie haben www.yoursite.com CNAME in Ihrer Cloudfront-Distribution mit Origin von www.yoursiteorigin.com. Natürlich werden die Leute zu www.yoursite.com kommen. Wenn Ihr Code jedoch versucht, auf eine Seite auf www.yoursiteorigin.com umzuleiten, erhalten Sie diesen Fehler.

Für mich führte mein Origin noch die http-> https-Weiterleitungen zu meinen Origin-URLs und nicht zu meinen Cloudfront-URLs durch.

2
Peter

In unserem Fall hatten wir die Unterstützung für SSL3, TLS1.0 und TLS1.1 für die PCI-DSS-Konformität auf unseren Origin-Servern eingestellt. Sie müssen jedoch manuell Unterstützung für TLS 1.1+ auf Ihrem CloudFront Origin-Server config hinzufügen. Die AWS-Konsole zeigt die Client-zu-CF-SSL-Einstellungen an, zeigt jedoch die CF-zu-Origin-Einstellungen nicht an, bis Sie einen Drilldown ausführen. Um dies zu beheben, in der AWS-Konsole unter CloudFront: 

  1. Klicken Sie auf DISTRIBUTIONS.
  2. Wählen Sie Ihre Distribution aus.
  3. Klicken Sie auf die Registerkarte ORIGINS.
  4. Wählen Sie Ihren Origin-Server aus.
  5. Klicken Sie auf BEARBEITEN.
  6. Wählen Sie alle Protokolle aus, die Ihr Origin unter "Origin SSL-Protokolle" unterstützt.
1
leiavoia

Ich bin auf dieses Problem gestoßen, das sich gelöst hat, nachdem ich keinen Proxy mehr verwendet habe. Vielleicht setzt CloudFront einige IPs auf die schwarze Liste.

0
lid

Dieses Problem wurde behoben, indem meine Zertifikate verkettet wurden, um eine gültige Zertifikatkette zu generieren (mithilfe von GoDaddy Standard SSL + Nginx).

http://nginx.org/de/docs/http/configuring_https_servers.html#chains

Um die Kette zu erzeugen:

cat 123456789.crt Gd_bundle-g2-g1.crt > my.domain.com.chained.crt

Dann: 

ssl_certificate /etc/nginx/ssl/my.domain.com.chained.crt;
ssl_certificate_key /etc/nginx/ssl/my.domain.com.key;

Ich hoffe es hilft!

0
Pedro

In meinem Fall verwende ich nginx als Reverse-Proxy für eine API-Gateway-URL. Ich habe den gleichen Fehler bekommen.

Ich habe das Problem behoben, als ich der Nginx-Konfiguration die folgenden zwei Zeilen hinzugefügt habe:

proxy_set_header Host "XXXXXX.execute-api.REGION.amazonaws.com";
proxy_ssl_server_name on;

Quelle ist hier: Proxy-Pass für Nginx einrichten, um API-Aufrufe für API-Gateway auszuführen

0
Adil Ilhan

In meinem Fall bestand das Problem darin, dass ich Amazons Cloudflare und Cloudfront's Cloudfront im Tandem verwendete und Cloudfront die von Cloudflare bereitgestellten Einstellungen nicht mochte.

Genauer gesagt hatte ich in den Crypto-Einstellungen von Cloudflare die "Minimum TLS Settings" auf 1,2 gesetzt, ohne die Kommunikationseinstellung TLS 1.2 für die Verteilung in Cloudfront zu aktivieren. Dies war ausreichend, um Cloudfront einen Fehler 502 Bad Gateway erklären zu lassen, als versucht wurde, eine Verbindung zum durch Cloudflare geschützten Server herzustellen.

Um dies zu beheben, musste ich die SSLv3-Unterstützung in den Origin-Einstellungen für diese Cloudfront-Verteilung deaktivieren und TLS 1.2 als unterstütztes Protokoll für diesen Origin-Server aktivieren.

Um dieses Problem zu debuggen, habe ich Befehlszeilenversionen von curl verwendet, um zu sehen, was Cloudfront tatsächlich zurückkehrte, als Sie nach einem Image von seinem CDN gefragt hatten. Außerdem verwendete ich die Befehlszeilenversion von openssl, um genau zu bestimmen, welche Protokolle Cloudflare waren Angebot (TLS 1.0 wurde nicht angeboten).

tl: dr; Stellen Sie sicher, dass alles akzeptiert und nach TLS 1.2 gefragt wird.

0
johnwbyrd