web-dev-qa-db-ja.com

SSL証明書を使用してF5ロードバランサーとバックエンドサーバーの両方を構成する方法

F5ロードバランサーバックエンドサーバーがあります。ロードバランサーはwww.example.comです。バックエンドサーバーはserver1.example.comです。 SSL Profile (client)SSL Profile (server)が有効になっているF5ロードバランサーと、ロードバランサーとバックエンドサーバーにSSL証明書があります。したがって、次のようになります。

クライアント(ラップトップ)-> HTTPS/SSL-> F5ロードバランサー(www.example.com)-> HTTPS/SSL->バックエンドサーバー(server1.example.com)

バックエンドサーバーは実行中ですWindows 2012/IIS 8.5。バインディングでは、ホスト名フィールドは空白です。

バックエンドサーバーのSSL証明書はserver1.example.com用であるため、www.example.comへのリクエストが失敗すると予想していました。それは実際に成功します。なぜ機能するのかわかりません。

[〜#〜] iis [〜#〜]server1.example.comへのバインディングでホスト名を設定すると、リクエストは失敗しません。空白のままにするかwww.example.comに設定すると、リクエストは成功します。なぜだかわかりません。意味がありません。

F5 LBがそれ自体とバックエンドサーバー間のハンドシェイクでクライアントとして機能していることを理解しています。しかし、私の理解は、F5がwww.example.com(ホスト名)のリクエストをバックエンドサーバーに送信していることです。バックエンドSSL証明書はserver1.example.com用です。したがって、F5によって送信されているホスト名がバックエンドサーバーのSSL証明書に関連付けられているホスト名と一致しないため、要求は失敗するはずです。つまり、www.example.com!= server1.example.comです。

私の論理のどこが間違っているのかを教えてください。なぜそれが機能するのか理解できません。

ありがとうございました。

2
user3621633

F5 LBがそれ自体とバックエンドサーバー間のハンドシェイクでクライアントとして機能していることを理解しています。しかし、私の理解では、F5がwww.example.com(ホスト名)のリクエストをバックエンドサーバーに送信しています。バックエンドSSL証明書はserver1.example.com用です。したがって、F5によって送信されているホスト名がバックエンドサーバーのSSL証明書に関連付けられているホスト名と一致しないため、要求は失敗するはずです。つまり、www.example.com!= server1.example.comです。

「リクエストは失敗するはずです」という意味がわかりません。どのエージェントが失敗しますか?サーバーはホスト名に対してSSL証明書を検証しません。クライアント(この場合はLB)が行います。

証明書の検証を担当するのはLBであるため、個々のサーバーノードのホスト名ではなく、正しいホスト名に対して何が行われているかをインテリジェントに把握して検証できます。

だからここにおおよそ何が起こるかです:

  1. ブラウザはwww.example.comに関連付けられたIPアドレスを検索します
  2. ブラウザはアドレスへのTCP/IP接続を確立します
  3. ブラウザはTCP/IPを介してTLS接続を確立し、それによってLB(www.example.com)から証明書を取得します
  4. ブラウザは、上記のステップ1で送信されたドメイン名に対して証明書のサブジェクトを検証します。それらが一致しない場合、フィッシング警告が表示されます
  5. ブラウザは、TCP/IP + TLSを介してHTTPペイロードをロードバランサに送信します。このペイロードには、HTTPヘッダー「Host:www.example.com」が含まれています
  6. LBは負荷分散ルールを評価し、リクエストの送信先となるバックエンドサーバーを選択します。これの出力は、これをどのように設定したかに応じて、サーバー名またはIPアドレスのいずれかです。
    • ホスト名の場合、IPルックアップにのみ使用されます。サーバーノードの名前はシステム全体にとって何の意味もないので、すぐに破棄されます。
    • IPアドレスの場合、LBはそれを使用します。この設定では、LBはバックエンドサーバーの名前がserver1.example.comであることを学習することさえありません。実際、その名前が何であるかはわかりません。
  7. LBがバックエンドサーバーへのTCP/IP接続を確立する
  8. LBはバックエンドサーバーへのTLS接続を確立し、それによってバックエンドサーバー(www.example.com)から証明書を取得します
  9. LBはバックエンド証明書の件名を検証します手順5で元のクライアントによって提供されたホストヘッダーに対して(www.example.com)
  10. LBはHTTPペイロードを再暗号化し、バックエンドサーバーに送信します。 HTTPヘッダー "Host:www.example.com"が含まれ、x-forwarded-forなどの追加のヘッダーが含まれる場合もあります。

Server1.example.comを示すHostヘッダーがあってはならず、そのHost名がSSL証明書の検証に使用されることもありません。

1
John Wu