web-dev-qa-db-ja.com

Apacheのプロキシされた証明書を無視することは可能ですか？

背景情報：（下の質問）

8つのサーバーがあり、すべてが一意のIPアドレスを持っているクライアントに接続しようとしています。クライアントは、すべてのサーバーで同じSSL証明書を使用します（この例では、cert name == www.all_servers.com）。クライアントは、httpsを介した着信要求のみを許可します。

さまざまなURIマッピングをさまざまなサーバーにマップするmod_proxyを使用してApacheプロキシを作成しようとしています。例えば：

https://PROXY_SERVER/SERVER1/{REQUEST}

これにより、{REQUEST}がserver1に送信されます

https://PROXY_SERVER/SERVER2/{REQUEST}

{REQUEST}をserver2に送信します。これまでのところ、非常に簡単です。

Apache 2.2では、次のようなIPアドレスを使用してこれを実現できました。

SSLProxyEngine On

ProxyPass /server1 https://1.1.1.1/
ProxyPassReverse /server1 https://1.1.1.1/

ProxyPass /server2 https://1.1.1.2/
ProxyPassReverse /server2 https://1.1.1.2/

これは、Apache 2.2が証明書が一致したかどうかを確認しなかったためです（1.1.1.1！= www.all_servers.com）

ただし、Apache 2.4では、証明書の問題が発生しています（当然）。 （この正確なコードはApache 2.2ボックスで動作します）

[Thu Oct 10 12:01:48.571246 2013] [proxy:error] [pid 13282:tid 140475667224320] (502)Unknown error 502: [client 192.168.1.1:48967] AH01084: pass request body failed to 1.1.1.1:443 (1.1.1.1)
[Thu Oct 10 12:01:48.571341 2013] [proxy:error] [pid 13282:tid 140475667224320] [client 192.168.1.1:48967] AH00898: Error during SSL Handshake with remote server returned by /server1/asd
[Thu Oct 10 12:01:48.571354 2013] [proxy_http:error] [pid 13282:tid 140475667224320] [client 192.168.1.1:48967] AH01097: pass request body failed to 1.1.1.1:443 (1.1.1.1) from 192.168.1.1 ()

/ etc/hostsは使用できません。1台のサーバーが機能するため、次を使用します。

1.1.1.1 www.all_servers.com

SSLProxyEngine On
ProxyPass /server1 https://www.all_servers.com/
ProxyPassReverse /server1 https://www.all_servers.com/

しかし、多くのサーバーはそうしません

つまり、実際の質問：

Mod_proxyに一致しない証明書を無視させる方法はありますか。または、これを行うより良い方法があります。

これで助けてくれてありがとう！

apachesslproxymod-proxymod-ssl
19
Gwynnie

SSLProxy* Apacheサーバーのオプション（リバースプロキシ接続に関する限り、クライアントです）。

これはSSLProxyCheckPeerCN（2.2ではデフォルトでオフ、2.4ではデフォルトでオン）で行われましたが、これがIPアドレスでどのように機能するかわかりません（CNにIPアドレスがあるので標準）。 Apache Httpd 2.4にはSAN（SSLProxyCheckPeerName）をチェックするための新しいオプションがありますが、IPアドレスに対してどのように動作するかわかりません。

[〜＃〜] dns [〜＃〜]SAN拡張またはCNにIPアドレスがある [〜＃〜] https [〜＃〜] に準拠した標準：

DNSName型のsubjectAltName拡張が存在する場合、それをIDとして使用する必要があります。それ以外の場合、証明書のSubjectフィールドの（最も具体的な）Common Nameフィールドを使用する必要があります。共通名の使用は既存の慣習ですが、非推奨であり、代わりにdNSNameを使用することを証明機関に推奨します。

[...]

場合によっては、URIはホスト名ではなくIPアドレスとして指定されます。この場合、iPAddress subjectAltNameは証明書に存在する必要があり、URIのIPと正確に一致する必要があります。

20
Bruno