Amazon S3、route53、Cloudfrontを使用する機能しないhttps設定をデバッグする方法は？

Question

次の静的サイトを設定しています。

s3（中央ヨーロッパ地域）でホストされるコンテンツ
カスタムドメインで
Httpsを使用したCloudfront
dNSセットアップ用のroute53
httpをhttpsにリダイレクトします
wwwをネイキッドドメインにリダイレクトします。

AmazonからSSL証明書を取得しました。

現在の状態：

裸リダイレクトへのwwwは機能します。
http：// my-domain.comアクセスが機能する
https：// my-domain.comが機能しません

Httpsを介したアクセスは単にタイムアウトし、ブラウザはサイトに到達できなかったことを通知します。

私はすべて同じことを言っている複数の記事に従いました。（それらのいくつかを最後にリストします）

しかし、私は問題を見つけることができません。

私が見た唯一の奇妙なことは、これらの記事のCloudfront配布オプションのスクリーンショットで、すべてのOrigin SSLプロトコル設定が利用できることです。私はこれらを持っていません。

だから、これに関する専門家ではなく、どのようにデバッグできますか？これらすべての記事に続いて、トラブルシューティングセクションはありません。

記事の一部：- https://www.lambrospetrou.com/articles/migrate-to-aws-static-website/ - https://simonecarletti.com/blog/ 2016/08/redirect-domain-https-Amazon-cloudfront / - https://simonecarletti.com/blog/2016/08/redirect-domain-http-https-www-cloudfront/ =

Patrick Mevzek · Answer

残念ながら、関係する名前を提供しないので、人々は推測を投げない限り実際にトラブルシューティングを行うことができません。

ここに私のgeneric（網羅的ではなく、可能性のあるすべてのコーナーケースではありません）タイムアウトをチェックするために実行するステップの迅速かつ論理的なリストがあり、次のステップに進む前に、その順序で各ステップを正常に完了します。

「明白」：ウェブサーバーのログファイルを見て、エラーがないことを忘れないでください。手順5以降で、それらに注意してください。また、サーバーにアクセスする他の人がすべてを見ることができる場合に問題が発生する可能性があるため、他のポイントからもテストを行うようにしてください（URLを提供した場合、あなたはすでにこの情報を助けようとしている人から無料でここにあります）
「ドメインレベル」：ドメイン名はDNSに関して正しく設定されていますか？ DNSviz または Zonemaster などのオンラインツールを試すことができます。 whoisでは、ドメインが正しい解決を禁止する何らかの種類のclientHoldstatusになっていないことに注意してください。 DNSSEC関連のエラーがないことも確認してください。以前のオンライン診断ツールを使用する場合、これらの最後の2つのポイントが表示されます。
「IPレベル」：URLに関連するホスト名を照会すると、どのIPアドレスが取得されますか？ Digなどのツールを使用して、最初にドメインの権限のあるネームサーバーをチェックし、次にいくつかのキャッシュ（yours、8.8.8.8、9.9.9.9）をチェックする必要があります。取得するはずのIPを取得していますか？ IPv4とIPv6の世話をし、後の手順で両方を使用します。
「TCPレベル」：tcptracerouteなどのツールを使用し、前の手順で見つかったIPを使用して、httpクエリのポート80またはhttpsの443（またはURLで指定された他のポート）。トレースはエラーなしで完了しますか（最後の行に*や!Xorなどはありません）？結果に関連性がないため、このようなものにはtracerouteもpingも使用しないでください。TCPレベルをテストする必要があります。
「TLSレベル」（もちろんhttps:// URLのみ）：openssl s_clientまたは同等のもの（SNIを忘れないでください。したがって、opensslには適切なホスト名でフラグ-servernameを追加する必要があります）少なくともTLSハンドシェイクの最初に戻り、できればサーバー証明書まで戻してください。正しい証明書であることを確認してください。 HEAD（Perl libwwwモジュールから）またはwgetまたはcurlなど、適切なスイッチを備えた他のコマンドラインツールを使用して、より多くのデバッグデータを取得することもできます。証明書内のOCSPのものを見てください。
「アプリケーションレベル」：何も返されない場合、またはHTTPヘッダーのみがWebアプリケーションに問題がある場合は、サーバーのログファイルを確認する必要があります。それらをより綿密に調査し始めてください（そしてロギングを増やしてみてください）。ブラウザの複雑な動作を排除するために、wget/curlなどの低レベルのツールを引き続き使用してください。

これがすべて失敗した場合、Webサーバーの前で受信内容を確認するために、また自分のクライアントの後に送信内容を確認するために、下に移動してネットワークスニファーの実行を開始する必要があります。しかし、これはそれだけで別の投稿になる可能性があり、以前の手順をすべて削除していない場合は不要です。

また、インフラストラクチャを処理するために商用エンティティを使用しているため、何らかのサポートに対しても支払いを行っていると確信しているので、それらに問い合わせてみてください。特定のケースに役立つトラブルシューティングツールとスキルが必要です。