в настоящее время я использую следующую схему для обслуживания как статического y, так и динамического контента.
Я скомпилировал stunnel с патчем поддержки X-Forwarded-For.
Интернет (http) -> haproxy (frontend1) -> Apache Farm
Интернет (https) -> stunnel -> haproxy (frontend2) -> Apache Farm
Stunnel настроен на использование сертификата с xxxx.com. Можно ли добавить поддержку stunnel для работы с другими сертификатами?
cert = /etc/stunnel/group.cert
key = /etc/stunnel/private.key
verify = 0
debug = local0.debug
CAfile = /etc/stunnel/group.cert
chroot = /var/run/stunnel4/chroot
setuid = stunnel4
setgid = stunnel4
failover = prio
xforwardedfor = yes
TIMEOUTclose=0
socket=l:TCP_NODELAY=1
socket=r:TCP_NODELAY=1
[https]
accept = 443
connect = HAPROXYHOST:FRONTEND2PORT
Я знаю, что могу запустить еще один экземпляр stunnel, который привязывается к другому IP-адресу, но у нас нет бесконечного публичного адреса, если мы решим разместить больше сайтов, я знаю, что можно настроить Apache для обслуживания разных сертификатов для каждого VirtualHost, можно сделать это с этой схемой? Или, возможно, переход с stunnel на Apache mod_proxy или другое решение.
Большое спасибо.
Обычно при работе с SSL / TLS и несколькими сайтами на одном IP у вас есть два варианта.
Во-первых, клиент должен отправить имя хоста, который его интересует, с первоначальным запросом. Это то, что http://en.wikipedia.org/wiki/Server_Name_Indication доставляет, но это поддерживается не всеми клиентами (см. на странице википедии список того, что работает, а что нет). С SNI имя хоста доступно в начале безопасного согласования, поэтому сервер может выбрать правильный сертификат для ответа.
Если вы не можете использовать SNI, у вас небольшая проблема. Клиент появляется и говорит: «Привет, я хочу использовать SSL», но вы не знаете, какое имя хоста ему нужно, поэтому вы не можете выбрать правильный сертификат. Все, что вам известно, это IP-адрес. Итак, для этого вы должны убедиться, что возвращаемый вами сертификат действителен для всех различных vhosts на этом IP.
Последнее не обязательно так плохо, как кажется на первый взгляд. Один из вариантов - получить подстановочный сертификат, например * .mysite.com. Пока вы обслуживаете www.mysite.com и images.mysite.com (т. Е. Оба в одном пространстве с подстановочными знаками), все в порядке. Другой вариант - использовать subjectAltName в вашем сертификате. С этой опцией ваш один сертификат действителен для нескольких веб-сайтов. Таким образом, когда вы отправите один общий сертификат обратно клиенту, он будет действителен для любого из хостов, которые они хотели. Довольно много центров сертификации поддерживают этот последний вариант, и, как правило, это единственный вариант для сертификатов EVA (обычно вы не можете получить из них подстановочные знаки), и вы обычно просто звоните в свой центр сертификации каждый раз, когда хотите добавить новый. vhost на этот IP-адрес, и они взимают с вас небольшую плату и выпускают новый сертификат с дополнительным именем в нем.
Обслуживание разных сертификатов на одном и том же порте по одному и тому же адресу зависит от поддержки TLS Server Name Indication, которая не поддерживается stunnel.
Использование Apache в качестве прокси-сервера действительно даст вам поддержку на стороне сервера, которая вам понадобится, однако имейте в виду, что поддержка на стороне клиента (кхм, Windows XP) для указания имени сервера еще не повсеместна.
Альтернативой для рассмотрения, если она находится в вашем ценовом диапазоне, является сертификат, в котором представлены альтернативные имена субъектов.