Здесь два основных вопроса:
Если я хочу обслуживать SSL-контент с 3 разных серверов (A, B, C) через обратный прокси-сервер (P), где происходит волшебство SSL?
Я предполагаю, что каждый сервер будет отвечать за обработку материалов SSL, а X просто маршрутизирует биты, но я не уверен. Предположительно в этом случае я бы использовал один и тот же сертификат, подписанный для X, на каждой машине A, B, C. Или X выполняет все действия SSL самостоятельно?
Во-вторых, какой веб-сервер лучше всего использовать для обратного прокси-сервера в Windows Server 2008? IIS, Apache и т. Д. Дополнительная заслуга, если у вас есть хороший пример настройки по вашей рекомендации.
Спасибо за вашу помощь!
Я предполагаю, что под «обратным прокси» вы подразумеваете сервер Apahce, действующий как прокси, а не DNAT (NAT назначения). В этом случае ваши клиенты видят ваши серверы (A, B, C) с внутренними IP-адресами (IA, IB, IC) как внешние или общедоступные IP-устройства (XA, XB, XC).
Если, с другой стороны, вы хотите представить свои устройства (IA, IB, IC) как один внешний IP-адрес (XIP), вам необходимо использовать сертификаты SSL, которые включают несколько альтернативных имен субъектов. Фактически, если у вас есть только один общедоступный IP-адрес и вы хотите использовать несколько сайтов SSL для этого одного общедоступного IP-адреса, вам нужно будет использовать сертификат с несколькими альтернативными именами субъектов независимо от того, работает ли обратный прокси-сервер. Атрибут называется «SubjAltName» в области X.500.
Эта ссылка может вам помочь: http://www.wlug.org.nz/ApacheReverseProxy
Вы действительно не можете подключиться к DNAT HTTPS, если ваш DNAT не знает, как обрабатывать сертификаты SSL - вы в основном создаете процесс MITM (человек посередине); одна из тех вещей, от которых SSL пытается защитить.
Вы можете настроить сервер Microsoft ISA в качестве обратного прокси для вашего SSL. Затем он перенаправляет трафик через порт 80 на IIS, находящийся на другом сервере. Это также будет работать для сертификатов с подстановочными знаками, если вы захотите их использовать. Я считаю, что вы также можете использовать это для балансировки нагрузки.
Я цитирую нашего отличного специалиста по поддержке CMS
"Здесь нужно подумать о том, где вы будете выполнять завершение SSL
Другими словами, запрос будет клиентом к прокси как https, а затем http от прокси к внутреннему ящику, где вы получаете apache для завершения SSL
Или
Весь разговор - SSL
Я бы предпочел 1-й вариант, когда вы позволяете Apache завершать SSL, поскольку нет реальной необходимости иметь весь разговор как https
Я бы поместил сертификат на сервер apache в директиве виртуального хоста, а затем отправил бы этот запрос на внутренний ящик ".
Другими словами, тоже самое, но проще избежать внутреннего шифрования в вашей собственной сети.
Насколько мне известно, IIS не будет реверсировать прокси (конечно, до IIS 6, не уверен, что будет позже), поэтому это Apache. Вы также можете использовать SQUID, что кажется хорошим, хотя у меня нет прямого опыта.
См. Также мой вопрос о StackOverflow (https://stackoverflow.com/questions/283636/apache-reverse-proxy-set-up-ssl-certificate) по поводу правильного конфига для Apache.