次のシナリオでは、
[client]---https--->[Nginx]---http--->[app server]
証明書を一意に識別するために、どのように (そして何を) アプリ サーバーに渡しますか? つまり、Nginx は証明書を検証しますが、アプリ サーバーには表示されません。アプリサーバーでユーザーを区別する必要があるため、ユーザーが互いに偽装することはできません。
この質問で説明されているものと同じ手法を 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 バルブ) を作成できます。
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
また、チェックするバックエンド サーバーのヘッダーも設定します。