6

これはよくある質問だと思いますが、同じ質問であると認識できるものは見つかりませんでした。

Tomcat でいくつかの Web アプリを実行しています。たとえば、web.xml の機密要素で定義されているように、SSL で保護されたログイン ページなどのいくつかのページがあります。アプリの 1 つは、証明書によるクライアント認証も受け入れます。また、かなり広範な JAAS ベースの承認および認証方式を使用しており、さまざまな Web アプリケーション間であらゆる種類の共有コードやさまざまな JAAS 構成などがあります。

以下を達成している間、私は本当にそれを邪魔したくありません。

Tomcat インスタンスを追加する前に、ロード バランサーとして Tomcat の前に mod-proxy および mod-proxy-balancer を使用して Apache HTTPD を挿入する作業を行っています。

私が HTTPS リクエストに対して達成したいことは、HTTPD が SSL エンドポイントでなくても Tomcat に「ブラインド」でリダイレクトされることです。つまり、HTTPD は暗号文を Tomcat に直接渡すだけで、TC がログイン、SSL、Web .xml の機密性が保証され、最も重要なのはクライアント認証です。

これは、私が説明した構成で可能ですか?

私は webapps と SSL と HTTPS と Tomcat に精通していますが、Apache HTTPD の外部範囲に関する知識は限られています。

必要に応じてこれを移動できてうれしいですが、構成ファイルを使用したプログラミングのようなものです ;)

4

1 に答える 1

7

これはこの質問に似ていますが、私はそれは不可能だと答えました:

SSL/TLS トラフィックを Apache から Tomcat に中継することはできません。SSL 接続が Apache で終了し、Tomcat へのトラフィックをリバース プロキシする必要があります (この場合、[Httpd と Tomcat の間の] SSL はほとんど役に立ちません)。または、クライアントを Tomcat に直接接続させて SSL 接続を処理させます。 .

この主張を裏付けるリンクが少し不足していることは認めます。私は間違っているかもしれないと思います（これが行われたのを見たことはありませんが、厳密には存在しないという意味ではありません...）。

ご存知のように、ユーザー エージェントと SSL エンドポイント (この場合、Tomcat にする必要があります) の間に直接接続、または完全に中継された接続が必要です。これは、Apache Httpd が URL を調べることができないことを意味します。せいぜいホスト名を知っているだけです (サーバー名表示を使用している場合)。

mod_proxyドキュメントの URL に依存していないように見える唯一のオプションは、HTTPS のフォワードプロキシ サーバーにAllowCONNECT使用されるものです。

のオプションでmod_proxy_balancerさえ、構成のある時点でパスを想定しています。そのドキュメントでは、SSL/HTTPSについて言及していません (「HTTP、FTP、および AJP13 プロトコルのロード バランシング サポートを提供します」) 。mod_proxyCONNECT

いくつかのオプションをお勧めします。

  • iptablesHttpd を介さずにベースのロードバランサーを使用して、Tomcat で直接接続を終了します。

  • Httpd で SSL/TLS 接続を終了し、プレーンな HTTP リバース プロキシを使用して Tomcat に接続します。

この 2 番目のオプションでは、クライアント証明書と Tomcat のセキュリティ制約を処理するために、もう少し構成が必要です。

で webapp を構成し<transport-guarantee>CONFIDENTIAL</transport-guarantee>た場合は、Tomcat がプレーンな HTTP ポートから接続されていることを認識しているにもかかわらず、Tomcat が接続に安全なフラグを立てる必要があります。Tomcat 5 については、 set にバルブを実装する方法を説明する記事(元はフランス語ですが、自動翻訳はそれほど悪くありません)isSecure()です。（バルブに慣れていない場合、それらはフィルターに似ていますが、リクエストが webapp に伝達される前に Tomcat 自体で動作します。Catalina 内で構成できます）Tomcat 5.5 から、HTTP コネクタsecureオプションは正確に機能すると思いますつまり、独自のバルブを必要としません。AJP コネクタにも同様のオプションがあります (mod_proxy_ajpまたはを使用する場合mod_jk)。

AJP コネクタを使用している場合mod_proxy_ajpは、チェーン内の最初の証明書を転送し、Tomcat 内で (通常の要求属性を介して) 使用できるようにします。おそらく必要になるでしょうSSLOptions +ExportCertData +StdEnvVars。mod_jk（私が知る限り非推奨ですが）クライアントから送信されたチェーン全体を（ を使用してJkOptions +ForwardSSLCertChain）転送することもできます。これは、プロキシ証明書を使用する場合に必要になる場合があります(エンドエンティティ証明書までのチェーンがなければ意味がありません)。

を使用したい場合は、HTTP ヘッダー ( )mod_proxy_http経由で証明書を渡すのがコツです。たとえば、. 正確な詳細は覚えていませんが、このヘッダーがクライアントのブラウザー (別の方法で偽造される可能性がある) から送信されないように、このヘッダーがクリアされていることを確認することが重要です。完全なチェーンが必要な場合は、この Httpd パッチ試行を試すことができます。このアプローチでは、 (PEM ブロックを解析することによって)ヘッダーを に変換するために、おそらく追加のバルブ/フィルターが必要になります。mod_headerRequestHeader set X-ClientCert %{SSL_CLIENT_CERT}sjavax.servlet.request.X509Certificate

興味深いかもしれない他のいくつかのポイント：

  • 私の記憶がよければ、Httpd 用に明示的に CRL ファイルをダウンロードし、それらを使用するように構成する必要があります。使用している Httpd のバージョンによっては、CRL をリロードするために再起動する必要がある場合があります。
  • クライアント証明書を取得するために再ネゴシエーションを使用している場合CLIENT-CERT、私の知る限り、ディレクティブは Httpd にクライアント証明書を要求させません (これはSSLSession、JSSE コネクタを直接使用するときにアクセスできるバルブを介して行われます)。クライアント証明書を要求するには、Httpd で一致するパスを構成する必要がある場合があります。
于 2012-04-13T02:22:54.160 に答える