Die Cloudfront-Distribution für benutzerdefinierte Herkunft gibt für einige URLs 502 "FEHLER Die Anforderung konnte nicht erfüllt werden." Zurück

Haben wir eine Cloudfront-Verteilung mit benutzerdefinierten Ursprungs, dass hat funktioniert ganz gut für eine Recht lange Zeit, die statischen assets für einen unserer Standorte. Gerade an diesem morgen, bemerkten wir, dass unser logo zeigt so einen Defekten link.

Bei der weiteren Untersuchung Cloudfront ist wieder eine seltsame Fehlermeldung, die ich noch nie zuvor gesehen haben für die URL in Frage:

FEHLER

Die Anforderung konnte nicht erfüllt werden.

Generiert cloudfront (CloudFront)

Mehrere andere Cloudfront-URLs von dieser distribution wieder den gleichen Fehler, aber dann andere (wieder aus der gleichen Verteilung) funktioniert ganz gut. Ich sehe nicht ein Muster, was funktioniert und was nicht.

Einige andere Daten-Punkte:

  • Die Ursprungs-URLs gut funktionieren. Es gibt keine aktuellen Unterbrechung im Dienst, meines Wissens.
  • Ich habe invalidiert die logo-URL speziell, keine Wirkung.
  • Ich habe invalidiert die Stamm-URL der Verteilung, keine Wirkung.

Irgendeine Idee, was hier Los ist? Ich habe noch nie gesehen Cloudfront dies zu tun, bevor.

UPDATE:

Hier ist die wörtliche 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>

InformationsquelleAutor der Frage David Eyk | 2013-12-18

  1. 29

    Ich hatte ein ähnliches Problem vor kurzem, wie sich herausstellte, aufgrund ssl_ciphers, dass ich mit war.

    Vom http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html

    "CloudFront vorwärts HTTPS Anfragen an den origin-server über das SSLv3 oder TLSv1 Protokolle und die AES128-SHA1 oder RC4-MD5-Verschlüsselungen. Wenn der origin-server nicht unterstützt entweder die AES128-SHA1 oder RC4-MD5-Verschlüsselungen, CloudFront nicht herstellen einer SSL-Verbindung zu Ihrem Ursprung.
    "

    Musste ich meine nginx confg hinzufügen AES128-SHA ( veraltet RC4:HIGH ) zu ssl_ciphers beheben der Fehler 302. Ich hoffe, das hilft. Ich habe eingefügt die Zeile aus meiner ssl.conf 

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

    InformationsquelleAutor der Antwort dminer

  2. 121

    Ich hatte diesen Fehler heute mit Amazon Cloudfront. Es war, weil der cname-I (e.g cdn.example.com) nicht Hinzugefügt wurde, um die Verteilung der Einstellungen unter "Alternative cnames", hatte ich nur cdn.example.com an die cloudfront-domain für meine Website/hosting control panel, aber Sie brauchen, um hinzuzufügen, Sie zu Amazon CloudFront-panel zu.

    InformationsquelleAutor der Antwort adrianTNT

  3. 13

    Fand meine Antwort und fügen Sie es hier, falls es hilft David (und andere).

    Stellt sich heraus, meine origin-server (sagen http://www.example.com) hatte eine 301-Weiterleitung einrichten auf Sie HTTPS anstelle von HTTP:

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

    Aber, meine Herkunft-Protokoll Richtlinie festgelegt wurde, nur HTTP. Dies verursacht CloudFront, nicht meine Datei und werfen Sie einen 502-Fehler. Darüber hinaus denke ich, es cached die 502-Fehler, für 5 min oder so, da hat es nicht funktioniert sofort nach dem entfernen, dass eine 301-Weiterleitung.

    Hoffe, das hilft!

    InformationsquelleAutor der Antwort Shawn Dube

  4. 7

    In unserem Fall, alles SAH ok aus, aber es dauerte fast den ganzen Tag, um dies herauszufinden:

    TLDR: Überprüfen Sie Ihre Zertifikats-Pfade, um sicherzustellen, dass das root-Zertifikat korrekt ist. Im Falle von COMODO-Zertifikaten, es sollte sagen, "USERTrust" und werden ausgestellt von "AddTrust External CA Root". NICHT "COMODO" ausgestellt von "COMODO RSA-Zertifizierungsstelle".

    Aus der CloudFront-docs:
    http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/SecureConnections.html

    Wenn der origin-server liefert ein ungültiges Zertifikat oder ein selbstsigniertes Zertifikat, oder wenn der origin-server gibt die Zertifikat-Kette in der falschen Reihenfolge, CloudFront, fällt die TCP-Verbindung, gibt HTTP-Fehlercode 502 und setzt den X-Cache header, um Fehler von cloudfront.

    Hatten wir das Recht, Verschlüsselungen aktiviert pro: http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html#RequestCustomEncryption

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

    Die Cloudfront-Distribution für benutzerdefinierte Herkunft gibt für einige URLs 502

    Jedoch die Letzte Zertifikat in die ssl-checker Kette war "COMODO RSA Domain Validation Secure Server CA", ausgestellt von "COMODO RSA-Zertifizierungsstelle"

    Scheint es, dass CloudFront nicht halten das Zertifikat für "COMODO RSA-Zertifizierungsstelle" und als solcher denkt, die Bescheinigung des Ursprungs-server signiert.

    Dieser arbeitete für eine lange Zeit, bevor Sie scheinbar plötzlich zu stoppen. Was war passiert, ich hatte soeben unsere Zertifikate für das Jahr, aber beim import etwas geändert wurde in den Pfad des Zertifikats für alle vorherigen Zertifikate. Sie alle begannen verweisen auf "COMODO RSA-Zertifizierungsstelle" in der Erwägung, dass, bevor die Kette wurde länger, und die Wurzel war "AddTrust External CA Root".

    Die Cloudfront-Distribution für benutzerdefinierte Herkunft gibt für einige URLs 502

    Weil dieser, Wechsel zurück auf die ältere cert nicht beheben cloudfront Problem.

    Musste ich löschen Sie das zusätzliche Zertifikat "COMODO RSA Certification Authority", die ein nicht-Referenz-AddTrust. Nachdem Sie dies tun, werden alle meine website-Zertifikate Pfade aktualisiert, um Punkt AddTrust/USERTrust wieder. Hinweis: kann auch geöffnet werden, bis die schlechten root-Zertifikat von der Pfad, klicken Sie auf "Details" -> "Eigenschaften Bearbeiten" und deaktivieren Sie es dann so. Dies aktualisiert den Pfad sofort. Sie können auch löschen müssen, um mehrere Kopien des Zertifikats finden Sie unter "Persönliches" und "Vertrauenswürdige Stammzertifizierungsstellen"

    Die Cloudfront-Distribution für benutzerdefinierte Herkunft gibt für einige URLs 502

    Schließlich musste ich neu wählen Sie das Zertifikat im IIS, um es zu dienen, das neue Zertifikat-Kette.

    Nachdem all dies, ssl-checker gestartet, die Anzeige eines Dritten-Zertifikat in der Kette, die weist zurück auf "AddTrust External CA Root"

    Die Cloudfront-Distribution für benutzerdefinierte Herkunft gibt für einige URLs 502

    Schließlich CloudFront akzeptiert die origin server-Zertifikat und die mitgelieferte Kette als vertrauenswürdig. Unser CDN begann wieder richtig!

    Um dies zu verhindern in der Zukunft, die wir brauchen, um den export unserer neu generierte Zertifikate werden von einer Maschine mit dem korrekten Zertifikatskette, d.h. Misstrauen oder löschen Sie das Zertifikat "COMODO RSA-Zertifizierung Authroity" ausgestellt von "COMODO RSA-Zertifizierung Authroity" (läuft im Jahr 2038). Dies scheint nur auf windows-Maschinen, wo dieses Zertifikat ist standardmäßig installiert.

    InformationsquelleAutor der Antwort Eddie Loeffen

  5. 2

    Ich ging gerade durch die Behandlung dieses Problems, und in meinem Fall ist es in der Tat war in Bezug auf die umgeleitet wird, aber nicht im Zusammenhang mit falschen Einstellungen in meinem CloudFront Herkunft oder Verhalten. Das wird passieren, wenn der origin-server ist noch umleiten, um Ursprungs-URLs, und nicht das, was Sie eingerichtet haben für Ihre cloudfront-URLs. Scheint, dass das sehr Häufig, wenn Sie vergessen, das zu ändern configs. Zum Beispiel können sagen, wenn Sie haben http://www.yoursite.com CNAME Ihrer cloudfront-Verteilung, mit einer Herkunft von http://www.yoursiteorigin.com. Offensichtlich Leute kommen http://www.yoursite.com. Aber wenn der code versucht, die Umleitung zu einer beliebigen Seite auf http://www.yoursiteorigin.com erhalten Sie diese Fehlermeldung.

    Für mich, meine Herkunft war immer noch die http->https umleitet, um meine Ursprungs-URLs und nicht meine Cloudfront-URLs.

    InformationsquelleAutor der Antwort Peter

  6. 2

    In meinem Fall, es war, weil wir hatten ein ungültiges ssl-cert. Das problem wurde auf unsere Inszenierung box und wir nutzen unsere prod cert. Es war für die letzten paar Jahren mit dieser Konfiguration, aber alle von einer plötzlichen wir begannen immer diese Fehlermeldung. Seltsam.

    Wenn andere diese Fehlermeldung bekommen, überprüfen Sie, dass das ssl-Zertifikat gültig ist. Sie können die Protokollierung aktivieren, s3 über die AWS-CloudFront-Verteilung Schnittstelle zu Hilfe Debuggen.

    Können, können Sie auch beziehen sich auf amazon docs auf die Frage hier: http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/SecureConnections.html

    InformationsquelleAutor der Antwort Peter P.

  7. 2

    Noch eine mögliche Lösung: ich habe ein staging-server, dient die Website und die Cloudfront-Vermögen-über-HTTP. Ich hatte meine Herkunft zu "Match Viewer" statt "Nur HTTP". Ich benutze auch das HTTPS-Everywhere-Erweiterung, die die Weiterleitung aller http://*.cloudfront.net URLs zu den https://* version. Da der staging-server nicht über SSL verfügbar und Cloudfront war, die passenden Zuschauer, es konnte nicht finden, dass die Vermögenswerte bei https://example.com zwischengespeichert und eine Reihe von 502s statt.

    InformationsquelleAutor der Antwort Devin

  8. 0

    Ich lief in dieses problem, das löste sich, nachdem ich nicht mehr mit einem proxy. Vielleicht CloudFront ist blacklisting einige IPs.

    InformationsquelleAutor der Antwort lid

  9. 0

    Behoben dieses Problem durch die Verkettung meine Zertifikate zu generieren, die ein gültiges Zertifikat-Kette (mit GoDaddy SSL + Nginx).

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

    Generieren der Kette:

    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;

    Hoffe, es hilft!

    InformationsquelleAutor der Antwort Pedro

  10. 0

    In meinem Fall, ich benutze nginx als reverse-proxy für ein API-Gateway-URL ein. Ich bekam dieselbe Fehlermeldung.

    Ich das Problem behoben, wenn ich fügte hinzu, die folgenden beiden Zeilen in die Nginx-config:

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

    Quelle ist hier: Einrichten proxy_pass auf nginx zu machen-API-Aufrufe an API-Gateway

    InformationsquelleAutor der Antwort Adil Ilhan

  11. 0

    In unserem Fall, hatten wir fallen gelassen Unterstützung für SSL3, TLS1.0 und TLS1.1 für PCI-DSS-compliance auf unserer origin-Server. Allerdings müssen Sie manuell fügen Sie die Unterstützung für TLS 1.1+ auf Ihrer CloudFront-origin-server config. Die AWS-Konsole zeigt die client-zu-CF-SSL-Einstellungen, aber nicht einfach zeigen, CF-to-origin-Einstellungen, bis Sie einen drill-down. Zu beheben, die in der AWS-Konsole unter CloudFront:

    1. Klicken Sie auf DISTRIBUTIONEN.
    2. Wählen Sie Ihre Distribution.
    3. Auf HERKUNFT tab.
    4. Wählen Sie Ihre Ursprungs-server.
    5. Klicken Sie auf BEARBEITEN.
    6. Wählen Sie alle Protokolle, die von Ihrer Herkunft unterstützt, die unter "Origin SSL-Protokolle"

    InformationsquelleAutor der Antwort leiavoia

Schreibe einen Kommentar