Можно ли игнорировать прокси-сертификат Apache

Для справочной информации: (Вопрос внизу)

Я пытаюсь подключиться к клиенту, у которого есть 8 серверов, каждый из которых имеет уникальные IP-адреса. Клиент использует один и тот же сертификат SSL на всех серверах (в данном примере имя сертификата == www.all_servers.com). Клиент разрешает входящие запросы только через https.

Я пытаюсь создать прокси-сервер apache, используя mod_proxy, который сопоставляет разные сопоставления URI с разными серверами. Например:

https://PROXY_SERVER/SERVER1/{REQUEST}

Это отправит {ЗАПРОС} на server1

https://PROXY_SERVER/SERVER2/{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 www.all_servers.com

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

Но многие серверы не


Итак, собственно вопрос:

Есть ли способ заставить mod_proxy игнорировать несоответствующие сертификаты. Или есть лучший способ сделать это.

Спасибо за любую помощь в этом!


person Gwynnie    schedule 10.10.2013    source источник
comment
Чтобы избежать путаницы, вы можете называть своего клиента/заказчика как-то иначе, чем клиент, когда говорите о серверах.   -  person Bruno    schedule 10.10.2013
comment
Голосование за переход на ServerFault.   -  person Bruno    schedule 10.10.2013


Ответы (1)


Вы можете установить параметры SSLProxy* на своем сервере Apache (который является клиентом, насколько речь идет об обратных прокси-соединениях).

Это было сделано с помощью SSLProxyCheckPeerCN (по умолчанию отключено в 2.2, но включено по умолчанию в 2.4), но я не уверен, как это будет работать с IP-адресами (поскольку наличие IP-адресов в CN не является стандартным). В Apache Httpd 2.4 есть новая опция для проверки SAN (SSLProxyCheckPeerName), но я не уверен, как она ведет себя и для IP-адресов.

Наличие IP-адресов в расширениях DNS SAN или в CN не соответствует стандарту HTTPS:

Если присутствует расширение subjectAltName типа dNSName, оно ДОЛЖНО использоваться в качестве идентификатора. В противном случае ДОЛЖНО использоваться (наиболее конкретное) поле Common Name в поле Subject сертификата. Хотя использование общего имени является существующей практикой, оно устарело, и центрам сертификации рекомендуется использовать вместо него имя dNSName.

[...]

В некоторых случаях URI указывается как IP-адрес, а не как имя хоста. В этом случае iPAddress subjectAltName должен присутствовать в сертификате и должен точно соответствовать IP-адресу в URI.

person Bruno    schedule 10.10.2013
comment
Спасибо, это сработало хорошо, я отключил только checkCN, как только я добавил checkName в off, все заработало волшебным образом. - person Gwynnie; 10.10.2013
comment
Отключение этого параметра делает это соединение потенциально уязвимым для MITM-атак, если, возможно, вы не импортировали эти сертификаты в SSLProxyCACertificate* напрямую (и там есть только эти сертификаты). - person Bruno; 10.10.2013