1

AWSを使用してHTTPSを設定することで、私は自分の道を歩んできました。私は自己署名証明書でこれを試みてきましたが、プロセスに少し問題があることがわかりました。

途中で出てきた 1 つの疑問は、このサーバー側 HTTPS のビジネスです。私が使用しているクライアントは、ユーザーがサーバーにアクセスしたときに URL を HTTPS に変更することを要求しています。「サーバー側 HTTPS」とは、プロトコルがエンドユーザーに対して透過的であることを意味するのでしょうか? ブラウザに HTTP が表示されますか?

ありがとう。

4

1 に答える 1

2

これがあなたの質問に対する正確な答えかどうかはわかりませんが、おそらくアドバイスです。ELB を使用する場合、SSL 証明書を ELB にインストールし、SSL オフロードを使用して ELB のポート 443 から EC2 インスタンスのポート 80 にリクエストを転送する方がはるかに簡単であることがわかりました。

これの長所：

  • 多数のインスタンスにまたがってインストールする (または AMI を更新してインスタンスを再起動する) のではなく、証明書をインストールする必要がある場所が 1 か所だけであるため、証明書の更新がはるかに簡単になります。
  • SSL 暗号化を処理する必要がないため、Web サーバーのパフォーマンスが向上します。

いくつかの短所：

  • 通信はエンドツーエンドで暗号化されていないため、ELB とサーバーの間で通信が傍受される可能性が技術的に (可能性は低いですが) あります。PCI コンプライアンスのようなものを扱っている場合、これは重要なことかもしれません。
  • HTTPS 経由でインスタンスの 1 つに直接アクセスする必要がある場合、それは不可能です。
  • x-forwarded-protoアプリケーションがリクエストが HTTPS 経由かどうかを確認する必要がある場合は、ELB がリクエストに挿入するhttps 関連のヘッダー (つまり ) をアプリケーションが認識していることを確認する必要がある場合があります。

この構成が、HTTP 経由で受信した要求を HTTPS にリダイレクトすることを禁止する理由はありません。x-forwarded-protoただし、HTTPS への Web サーバーまたはアプリケーション レベルのリダイレクトを行うには、ヘッダーを確認する必要がある場合があります。エンド ユーザーは、リクエストの HTTPS ラッパーが ELB でオフロードされていることを知る方法がありません。

于 2012-10-12T22:51:09.100 に答える