ロードバランサーまたはサーバーのSSL証明書
2つのサーバー間でトラフィックを分散するロードバランサーを使用しており、パブリック向けのURLにはすべてhttpsプレフィックスが付いています。
ワイルドカードのssl証明書を生成したいのですが、ロードバランサーと2つのサーバーのどちらに配置する方がよいかわかりません。何をお勧めしますか？メリットと違いは何ですか。
ありがとう
非常に一般的な方法（私はstandardとは言いません）は、バックエンドサーバーではなく、ロードバランサーに証明書を配置/構成することです。どうして？これにより、バックエンドアプリケーションサーバーで暗号化にtheir CPUを使用するのではなく、ロードバランサーがTLSハンドシェイク/終了オーバーヘッド（ie TLSメッセージのメモリ/ CPU）を処理できるようになります、アプリケーションの動作を提供することに加えて。したがって、それは通常、TLSターミネーションがアプリケーションサーバーの前にあることの「プロ」です。
これにより、サーバーへの単一のルートでTLSセッションキャッシングが可能になります（つまり、ロードバランサーを介してつまり）。これにより、キャッシュされたTLSセッションを使用する可能性が高くなります。一方、各バックエンドサーバーで証明書を構成した場合、それらのサーバーには（おそらく）独自のseparate TLSセッションキャッシュがあります。クライアントは、ロードバランサーによって、キャッシュされたits TLSセッションを使用してバックエンドサーバーに転送される場合と転送されない場合があります。
したがって、短いバージョンは、ロードバランサーで証明書を構成することが一般的に推奨されるアプローチです。
お役に立てれば！
証明書をロードバランサーに読み込まない場合は、トラフィック自体が暗号化されているため、TCP/IP接続のみを負荷分散できます。
ロードバランサーに証明書をロードすることで、ロードバランサーの機能に応じて、あらゆる種類の興味深いことを実行できます。
- 特定のユーザーからの後続の要求が常に同じバックエンドサーバーにルーティングされるように（たとえば、セッションCookieに基づいて）、セッションの永続性/スティッキーセッションを作成します。これは、ソースIPアドレスをベースとして使用するよりもはるかに信頼性が高くなります。アフィニティ。これは、LBに証明書がない場合の唯一のオプションです。
- 異なるURLをバックエンドサーバーの異なるプールにルーティングします。つまり、direct
example.com/app-1に使用されるアプリケーションサーバーとは異なるアプリケーションサーバーにexample.com/app-2 - 等.
多くの場合、LBでTLS/SSL接続を終了し、LBとバックエンドサーバーの間で暗号化されていないトラフィックが発生しますが、セキュリティ要件がそのような場合、そこに2番目のTLS/SSL接続を確立できます。
TJが述べたように、ロードバランサーにSSL CERTSをインストールすると、作業を処理し、ユーザーをバックエンドサーバーにオフロードできます。
CentOS 7のHAプロキシサーバーにLets Encrypt証明書をインストールするDigital Oceanには、これに関する優れた例/チュートリアルがあります????