1

次のシナリオでは、

[client]---https--->[Nginx]---http--->[app server]

証明書を一意に識別するために、どのように (そして何を) アプリ サーバーに渡しますか? つまり、Nginx は証明書を検証しますが、アプリ サーバーには表示されません。アプリサーバーでユーザーを区別する必要があるため、ユーザーが互いに偽装することはできません。

4

2 に答える 2

2

この質問で説明されているものと同じ手法を Apache Httpd に適応させることができます。次のようなNginxに相当するものが必要です。

RequestHeader set X-ClientCert ""
RequestHeader set X-ClientCert "%{SSL_CLIENT_CERT}s"

私は試していませんが、Nginx SSL モジュールのドキュメントには「埋め込み変数」に関するセクションがあります。すなわち：

$ssl_client_cert確立された SSL 接続のクライアント証明書を PEM 形式で返します。最初の行を除く各行にはタブ文字が付加されます。これは proxy_set_headerディレクティブでの使用を意図しています。

これは、あなたが持っているようなリバースプロキシ設定で必要なもののように見えます.

途中でこのヘッダーをクリアすることが非常に重要であることに注意してください。そうしないと、クライアントはヘッダー自体を設定して、好きな証明書を使用することができます。

アプリケーション サーバーでこれを確認する方法は、使用しているプラ​​ットフォームによって異なります。たとえば、Java では、このカスタム HTTP ヘッダーからの要求にパラメーターを設定するフィルター (または Tomcat バルブ) を作成できます。

于 2013-09-13T16:18:09.307 に答える
0

SSLターミネーションにNginxを使用したいようですが、バックエンドサーバーが元のリクエストがHTTPSまたはHTTP経由であったことを認識できるようにしたい. 私はこれがうまくいくと思います：

server {
    ssl on;
    listen 443;

    add_header  X-Forwarded-Proto  https;

    proxy_pass ...
}

# If you need insecure requests as well
server {
    listen 80;

    add_header  X-Forwarded-Proto  http;

    proxy_pass ...
}

X-Forwarded-Protoその後、アプリ サーバーはヘッダーの値を確認できます。

これは、Amazon Web Services が Elastic Load Balancer で SSL を終了するために使用するのと同じ設計パターンです。X-Forwarded-Protoまた、チェックするバックエンド サーバーのヘッダーも設定します。

于 2013-09-13T15:44:01.843 に答える