web-dev-qa-db-ja.com

Cloudfront custom-Originディストリビューションは、502「エラーは要求を満たせませんでした」を返します。一部のURL

カスタムOriginを備えたCloudfrontディストリビューションがあり、これはかなり長い間正常に機能しており、サイトの1つに静的アセットを提供しています。今朝、ロゴが壊れたリンクとして表示されていることに気付きました。

さらに調査すると、Cloudfrontは、 問題のURL に対してこれまで見たことのない奇妙なエラーメッセージを返しています。

エラー

要求を満たせませんでした。



クラウドフロント(CloudFront)によって生成

このディストリビューションの他のいくつかのCloudfront URLは同じエラーを返しますが、その後(他の同じディストリビューションから)正常に機能しています。何が機能し、何が機能しないかのパターンは見当たりません。

その他のデータポイント:

  • Origin URLs は問題なく動作します。私の知る限り、最近のサービスの中断はありません。
  • ロゴURLを具体的に無効にしましたが、効果はありません。
  • ディストリビューションのルートURLを無効にしましたが、効果はありません。

ここで何が起こっているのでしょうか? Cloudfrontがこれを行うのを見たことがありません。

UPDATE:

Cloudfrontからの逐語的なHTTPレスポンスは次のとおりです。

$ 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>
64
David Eyk

最近使用したssl_ciphersが原因であることが判明した同様の問題がありました。

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

「CloudFrontは、SSLv3またはTLSv1プロトコルとAES128-SHA1またはRC4-MD5暗号を使用してHTTPS要求をOriginサーバーに転送します。OriginサーバーがAES128-SHA1またはRC4-MD5暗号をサポートしていない場合、CloudFrontはSSL接続を確立できませんあなたの起源に。」

302エラーを修正するには、nginxの設定を変更してAES128-SHA(廃止予定のRC4:HIGH)をssl_ciphersに追加する必要がありました。これがお役に立てば幸いです。 ssl.confの行を貼り付けました

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

今日、Amazon Cloudfrontでこのエラーが発生しました。これは、使用したcname(例:cdn.example.com)が「alternate cnames」の下の配布設定に追加されなかったためです。サイト/ホスティングコントロールパネルでcdn.example.comのみをcloudfrontドメインに転送しましたが、 Amazon CloudFrontパネルにも追加する必要があります。

125
adrianTNT

私の答えを見つけて、David(および他の人)を助けるためにここに追加します。

私のOriginサーバー(www.example.comなど)には、HTTPをHTTPSに変更するための301リダイレクト設定がありました:

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

ただし、Origin Protocol PolicyはHTTPのみに設定されていました。これにより、CloudFrontはファイルを見つけられず、502エラーをスローしました。さらに、301リダイレクトを削除した直後に機能しなかったため、502エラーを5分程度キャッシュしたと思います。

お役に立てば幸いです!

14
Shawn Dube

私たちの場合、すべてが正常に見えましたが、これを理解するのにほとんどの時間がかかりました:

TLDR:証明書パスをチェックして、ルート証明書が正しいことを確認します。 COMODO証明書の場合、「USERTrust」と表示され、「AddTrust External CA Root」によって発行される必要があります。 「COMODO RSA認証局」によって発行された「COMODO」ではありません。

CloudFrontドキュメントから: http://docs.aws.Amazon.com/AmazonCloudFront/latest/DeveloperGuide/SecureConnections.html

オリジンサーバーが無効な証明書または自己署名証明書を返す場合、またはオリジンサーバーが証明書チェーンを間違った順序で返す場合、CloudFrontはTCP接続をドロップし、HTTPエラーコード502を返し、クラウドフロントからのエラーへのXキャッシュヘッダー。

http://docs.aws.Amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html#RequestCustomEncryption に従って、適切な暗号を有効にしました。

Google、Firefox、ssl-checkerによると、証明書は有効でした: https://www.sslshopper.com/ssl-checker.html

SSL Checker result without all required certificates

ただし、SSLチェッカーチェーンの最後の証明書は、「COMODO RSA認証局」によって発行された「COMODO RSAドメイン検証セキュアサーバーCA」でした。

CloudFrontは「COMODO RSA証明機関」の証明書を保持していないようで、そのため、Originサーバーによって提供された証明書は自己署名されていると考えています。

これは長い間働いていましたが、突然突然停止しました。何が起こったのか、その年の証明書を更新したばかりでしたが、インポート中に、すべてのprevious証明書の証明書パスで何かが変更されました。チェーンが長くなり、ルートが「AddTrust External CA Root」になる前に、それらはすべて「COMODO RSA Certification Authority」を参照し始めました。

Bad certificate path

このため、古い証明書に切り替えてもクラウドフロントの問題は解決しませんでした。

AddTrustを参照していない「COMODO RSA Certification Authority」という名前の余分な証明書を削除する必要がありました。これを行った後、すべてのWebサイト証明書のパスは、AddTrust/USERTrustを再度指すように更新されました。また、パスから不正なルート証明書を開き、[詳細]-> [プロパティの編集]をクリックして無効にすることもできます。これにより、パスがすぐに更新されました。 「個人」および「信頼されたルート認証局」の下にある証明書の複数のコピーを削除する必要がある場合もあります

Good certificate path

最後に、IISの証明書を再選択して、新しい証明書チェーンを提供するようにしなければなりませんでした。

このすべての後、ssl-checkerはチェーン内の3番目の証明書を表示し始めました。これは、「AddTrust External CA Root」を指し示していました。

SSL Checker with all certificates

最後に、CloudFrontは、オリジンサーバーの証明書と提供されたチェーンを信頼されているものとして受け入れました。 CDNが再び正常に機能するようになりました!

将来これが起こらないようにするには、新しい証明書を正しい証明書チェーンを持つマシンからエクスポートする必要があります。つまり、「COMODO RSA Certification Authroity」が発行した証明書「COMODO RSA Certification Authroity」(2038年に期限切れ)。これは、この証明書がデフォルトでインストールされるWindowsマシンにのみ影響するようです。

8
Eddie Loeffen

もう1つの可能な解決策:HTTP経由でサイトおよびCloudfrontアセットを提供するステージングサーバーがあります。 Originを「HTTP Only」ではなく「Match Viewer」に設定しました。また、すべてのhttp://*.cloudfront.net URLをhttps://*バージョンにリダイレクトするHTTPS Everywhere拡張機能も使用します。ステージングサーバーはSSL経由では利用できず、Cloudfrontはビューアーと一致していたため、https://example.comでアセットを見つけることができず、代わりに多数の502をキャッシュしました。

2
Devin

私の場合、無効なssl証明書があったためです。問題はステージングボックスにあり、その上でも製品証明書を使用します。この構成では過去数年間機能していましたが、突然このエラーが発生し始めました。奇妙な。

他の人がこのエラーを受け取っている場合は、SSL証明書が有効であることを確認してください。デバッグを支援するために、AWS CloudFront Distributionインターフェイスを介してs3へのロギングを有効にできます。

また、この問題に関するAmazonのドキュメントを参照できます: http://docs.aws.Amazon.com/AmazonCloudFront/latest/DeveloperGuide/SecureConnections.html

2
Peter P.

この問題のトラブルシューティングを行ったところ、実際にはリダイレクトに関連していましたが、CloudFrontのOriginまたはBehaviorの誤った設定には関連していませんでした。これは、OriginサーバーがまだCloudfront URLに設定したものではなく、Origin URLにリダイレクトしているの場合に発生します。設定の変更を忘れた場合、これは非常に一般的だと思われます。たとえば、www.yoursiteorigin.comのOriginを使用して、クラウドフロントディストリビューションへのwww.yoursite.com CNAMEがあるとします。明らかに人々はwww.yoursite.comに来るでしょう。ただし、コードがwww.yoursiteorigin.comのページにリダイレクトしようとすると、このエラーが発生します。

私にとって、Originはまだhttp-> httpsをCloudfront URLではなくOrigin URLにリダイレクトしていました。

2
Peter

私たちの場合、オリジンサーバーでのPCI-DSS準拠のためのSSL3、TLS1.0、およびTLS1.1のサポートを廃止しました。ただし、CloudFront Originサーバー設定でTLS 1.1+のサポートを手動で追加する必要があります。 AWSコンソールには、クライアントからCFへのSSL設定が表示されますが、ドリルダウンするまでCFからオリジンへの設定は簡単には表示されません。修正するには、CloudFrontの下のAWSコンソールで:

  1. [配布]をクリックします。
  2. ディストリビューションを選択します。
  3. ORIGINSタブをクリックします。
  4. Originサーバーを選択します。
  5. 編集をクリックします。
  6. 「Origin SSL Protocols」でOriginがサポートするすべてのプロトコルを選択します
1
leiavoia

この問題に遭遇しましたが、プロキシの使用をやめた後に解決しました。 CloudFrontが一部のIPをブラックリストに登録している可能性があります。

0
lid

証明書を連結して有効な証明書チェーンを生成することにより、この問題を修正しました(GoDaddy Standard SSL + Nginxを使用)。

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

チェーンを生成するには:

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

次に:

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

それが役に立てば幸い!

0
Pedro

私の場合、API Gateway URLのリバースプロキシとしてnginxを使用しています。同じエラーが発生しました。

Nginx構成に次の2行を追加すると、問題が解決しました。

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

ソースはこちらです: nginxでproxy_passを設定してAPI GatewayへのAPI呼び出しを行う

0
Adil

私の場合の問題は、AmazonのCloudflareとCloudfrontのCloudfrontを並行して使用していたことであり、CloudfrontはCloudflareに提供した設定が気に入らないということでした。

具体的には、Cloudflareの暗号設定で、CloudfrontのディストリビューションのTLS 1.2通信設定を有効にせずに、「最小TLS設定」を1.2に設定しました。これは、Cloudflareで保護されたサーバーに接続しようとしたときに、Cloudfrontが502 Bad Gatewayエラーを宣言するのに十分でした。

これを修正するには、そのCloudfrontディストリビューションのOrigin設定でSSLv3サポートを無効にし、そのOriginサーバーでサポートされているプロトコルとしてTLS 1.2を有効にする必要がありました。

この問題をデバッグするには、curlのコマンドラインバージョンを使用して、CDNからイメージを要求したときにCloudfrontが実際に返すものを確認し、opensslのコマンドラインバージョンも使用して、Cloudflareがどのプロトコルかを正確に判断しました提供(TLS 1.0を提供していませんでした)。

tl:dr;すべてがTLS 1.2、またはこれを読むまでに誰もが使用している最新かつ最高のTLSをすべて受け入れて要求するようにしてください。

0
johnwbyrd