クライアント認証を要求するために、ApacheでVirtualhost
の一部をセットアップしようとしています。問題のVirtualHost
は、実際のWebサーバーのリバースプロキシとしても機能します。これが私がやったことです:
ca.crt
、ca.csr
、およびca.key
を作成しました。VirtualHost
の設定を次のように変更しました:...
ProxyPass / http://xxx.xxx.xxx.xxx:80/
ProxyPassReverse / http://xxx.xxx.xxx.xxx:80/
ProxyPassReverseCookiePath / /
SSLEngine On
SSLCertificateFile "/private/etc/Apache2/server.crt"
SSLCertificateKeyFile "/private/etc/Apache2/server.key"
SSLCertificateChainFile "/private/etc/Apache2/ca_bundle.crt"
SSLCACertificateFile "/private/etc/Apache2/self_ca.crt"
SSLVerifyClient none
SSLOptions StrictRequire
SSLProtocol all -SSLv2
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
<Location /clientauth>
# These options force the client to authenticate with a client certificate.
SSLVerifyClient require
SSLVerifyDepth 1
</Location>
しかし、/clientauth
パスを参照できません。
Re-negotiation handshake failed: Not accepted by client!?
という行を繰り返し続けますこれはクライアント認証の使用とリバースプロキシの競合ですか?それとも私は何か間違ったことをしましたか?
ここでの根本的な問題は、再交渉の拒否です。これは、TLSの脆弱性を修正するための過去1〜2年の活動に起因しており、新しいTLS拡張が実装されるまで再ネゴシエーションを拒否するさまざまな暫定的な修正がありました。したがって、SSL(OpenSSL)を確実にして、Apache HTTPDもできるだけ最新であることを確認する必要があります。
HTTPクライアントは、SSLセッションがネゴシエートされた後でのみHTTP要求を送信します。つまり、サーバーは、SSLがセットアップされた後のみ、クライアントによって要求されたURLを認識します。 URLに基づいてSSLVerifyClient
の値を変更しているので、ApacheはSSLセッションが最初にネゴシエートされるときにクライアント証明書を要求できません。代わりに、URLがわかると、セッションの再ネゴシエーションを強制する必要があります。問題はこの再交渉にあるようですので、SSLVerifyClient require
をVirtualHost
ブロックに追加し、Location
ブロックから削除します。