そこで、haproxy または nginx を実行しているサーバーへの SSL パススルーを備えた ELB を用意する予定です。
潜在的に数千の Let's-Encrypt 証明書をホストすることになります。
nginx と haproxy のどちらが何千もの SSL 証明書を処理するのに優れていますか? それとも、この点に関しては基本的に違いはありませんか?
私は、haproxy または nginx のいずれかで SSL を終端し、多数の証明書ファイルなどを使用したいと考えています。これほど多くの証明書を処理するのにどちらが適しているかを知りたいです。
答え1
によるとElastic Load Balancer ドキュメントClassic Load Balancer では、リスナーごとに 1 つの証明書が許可され、最大 100 個のリスナー (異なるポート上) が許可されます。
アプリケーション ロード バランサー一方、バランサーごとに 25 個の証明書という制限がありますが、同じリスナーですべての証明書を使用できます。
このような膨大な量の証明書に対する唯一の実行可能なアプローチは、EC2 インスタンスをネットワーク ロード バランサーの背後にデプロイすることだと思います。これは、下位のネットワーク層で動作し、バックエンド インスタンスで SSL ネゴシエーションを完全に委任します。
ワークロードが HTTP 指向である場合、HAProxy よりも Nginx の方が適していると言えます。他のプロトコルをプロキシする場合は、HAproxy が最適な選択肢です。
答え2
どちらも素晴らしいです。個人的には、その観点からは複数のバックエンドを実行していないので (私の理解では) nginx を使用します。そのため、その面では haproxy は必要ありません。
nginx を ssl とプロキシ パスでセットアップするだけです :)
答え3
HAProxyを使えば何千もの証明書をロードするのが簡単だと思います。証明書を1つのディレクトリに置くだけで、HAProxyはすべての証明書をロードします。CRT ディレクティブ。
したがって、SSL オフロードの最小限の構成は次のようになります。
listen ssl_offload
mode http
bind IP:443 ssl crt <path-to-ssl-directory>
timeout client 30s
timeout server 30s
timeout connect 5s
server srv1 IP:80 check
HAProxyは、クライアントから提供されたSNIホスト名（現在はサポートされている(ほとんどの最新ブラウザではサポートされています)
複数の SSL 証明書をロードすることは、ここではメモリ消費の問題のみです。HAProxy には、必要な証明書と関連する秘密キーの両方を含む PEM ファイルが必要です。したがって、平均的な PEM ファイルが約 5K (2048 個の RSA キー) の場合、数百万の証明書をロードすると、約 5GB のメモリが必要になります。
HAProxy はリスナーごとに証明書を割り当てますが、NGINX は「サーバー名」ごとに証明書を割り当てるため、ドメインの数と同じ数のサーバー ブロックが必要になります。数千のサーバー ブロックを使用している場合は、スクリプトを作成する必要があるでしょう。