Несколько сертификатов SSL со Сквидом инвертируют прокси
Я обновлял свою сеть от использования апачского обратного прокси (Достаточно не совсем мощный) к прокси Сквида, настроенному только для обратного использования.
Мой прокси сквида находится на CentOS 6 VM, и в настоящее время работающий вместе с моим предсуществующим апачским прокси - таким образом, у меня все еще есть работа сквида порта 3128.
У меня есть эта установка в моем/etc/squid/squid.conf,
http_port 3128 accel vhost
visible_hostname squid
cache_peer 192.168.0.13 parent 80 0 no-query originserver name=server1
cache_peer_domain server1 www.server1.com server1.com
cache_peer 192.168.0.14 parent 80 0 no-query originserver name=server2
cache_peer_domain server2 www.server2.com server2.com
cache_peer 192.168.0.15 parent 80 0 no-query originserver name=server3
cache_peer_domain server3 www.server3.com server3.com
http_access allow all
Это работает отлично на все HTTP-соединения.
Это направляет
www.server1.com:3128
кому:
192.168.0.13:80
Я пытался реализовать сертификаты SSL для двух из этих трех доменов. Вчера вечером мне удалось получить некоторую успешную конфигурацию для полностью рабочего Подключения HTTPS к одному из моих доменов.
Я добавил эту конфигурацию перед настройками HTTP:
https_port 443 accel ssl-bump transparent vhost cert=/usr/ssl/CA/server1.crt key=/usr/ssl/CA/server1.key
cache_peer 192.168.0.12 parent 443 0 no-query originserver login=PASS ssl sslflags=DONT_VERIFY_PEER name=server1_ssl
cache_peer_domain server1_ssl ssl www.server1.com server1.com
Это, казалось, было в порядке вчера вечером. Это соединилось бы с
https:// www.domain1.com
полностью зашифрованный. Из-за одной из опций (метод проб и ошибок - не может помнить, который), он дешифрует пакеты и направляет Запрос HTTPS к корректному VM. VM уже установили сертификат SSL, так распознает Запросы HTTPS, и целый pageload от начала до конца был зашифрован.
Я мог посетить https://www.domain2.com, и он скажет, что соединение было частично зашифровано и покажет ошибку сертификата, что сертификат был для www.domain1.com
Однако сегодня это действительно вмешивалось в HTTP-соединение с domain1, и мой браузер говорил, что страница перенаправлялась способом, который никогда не будет завершаться.
Я с тех пор удалил целую конфигурацию соединения SSL из файла конфигурации, и я выполняю стандартный HTTP только.
Есть ли какие-либо способы, которыми я могу заставить https://www.domain1.com читать сертификат domain1.crt и прямо к VM domain1 и https://www.domain2.com для чтения сертификата domain2.crt и прямо к VM domain2?
Извините за такой долгий вопрос, но это - очень конкретный вопрос, который я имел, и я пытался дать как можно больше информации.
Спасибо
Squid не поддерживает SNI то, что написано здесь . Итак, чтобы иметь в Squid:
https://server1.com (cert for server1.com) => http://mylanip1
https://server2.com (cert for server2.com) => http://mylanip2
, вам необходимо:
- Поместить адреса на разные IP-адреса, потому что сертификат назначается уникальной паре [IP, порт].
- Настроить Squid следующим образом:
https_port server1.com:443 cert=/etc/ssl/server1.pem vhost
https_port server2.com:443 cert=/etc/ssl/server2.pem vhost
cache_peer mylanip1 parent 80 0 name=lanip1 no-query originserver
cache_peer_domain lanip1 server1.com
cache_peer mylanip2 parent 80 0 name=lanip2 no-query originserver
cache_peer_domain lanip2 server2.com
It Было бы лучше, если бы у вас были серверы на поддоменах домена, для которого у вас есть групповой сертификат (например, s1.myserver.com, s2.myserver.com, сертификат для * .myserver.com). Тогда вы могли бы использовать только одну запись https_port
https_port 443 cert=/etc/ssl/wildcard.myserver.com.pem vhost
Так что в squid это возможно.
Но такой простой случай гораздо проще сделать с httpd и виртуальными хостами на основе имен . Вы сохраните один публичный IP. В Centos 6 версии openssl и httpd поддерживают SNI. Это видно из версии openssl. (См. здесь и здесь )