У нас есть веб-приложение, которое обслуживает большое количество веб-сайтов с одного веб-сайта IIS. На веб-сайте IIS просто есть всеобъемлющая привязка к порту 80. До сих пор для привязок SSL мы добавляли новый IP-адрес к машине для каждого домена, которому требуется SSL, и добавляли привязку SSL к этому конкретному IP-адресу.
Сейчас мы исследуем централизованное хранилище сертификатов. Мы подумали, что теперь у нас может быть всеобъемлющая привязка SSL, которая будет просто использовать предоставленное имя хоста и искать сертификат в CCS. Но похоже, что это не так. Вы можете добавить всеобъемлющую привязку SSL с конкретным сертификатом, установленным на локальном IIS, или вы можете добавить отдельные привязки SSL с помощью CCS, но вы должны указать имя хоста.
Если я прав, то для нас это ошибка; мы по-прежнему будем связывать каждый используемый сертификат, даже если сам сертификат находится в CCS. Я прав?
РЕДАКТИРОВАТЬ: Это массовое арендованное приложение. Обслуживается около сотни клиентов с тысячами уникальных имен хостов, работающих в одном веб-приложении; приложение использует базу данных, чтобы определить, какой контент показывать для каждого имени хоста.
Наличие отдельной привязки для каждого имени хоста, которое используется для доступа к приложению, совершенно не запускается. И сохранение сертификатов SSL, загруженных в локальный экземпляр IIS, также не является началом; мы так до сих пор справляемся, и он становится громоздким.
На порте 80 у меня может быть всеобъемлющая привязка; любое имя хоста, используемое для подключения, будет направлено в веб-приложение.
На порте 443, по-видимому, я не могу этого сделать, если сертификат не загружен в экземпляр IIS вместо CCS. Таким образом можно использовать только один групповой сертификат на каждый IP-адрес. Я не могу использовать переданное SNI имя хоста для поиска нужного сертификата; переданное имя хоста должно сначала соответствовать привязке.
Идеальная ситуация была бы, если бы я мог просто привязать все к порту 443 с автоматическим поиском надлежащего сертификата на основе переданного имени хоста. Не похоже, что IIS хочет позволить мне это сделать.
Это очень удручает. Похоже, что для этого нам придется отказаться от IIS и переложить весь SSL на что-то на основе Apache, что кажется гораздо более гибким.
В IIS 10 вы можете иметь:
Name Bindings
---- --------
Default Web Site https *:443:*.bar.com sslFlags=3
https *:443:*.bar.net sslFlags=3
https *:443:*.foo.edu sslFlags=3
и используйте CCS для всех привязок, но вы не можете:
https *:443:*.*.com sslFlags=3
или
https *:443:*.com sslFlags=3
Поэтому, если все ваши домены являются разными доменами верхнего уровня, это не очень полезно, но если у вас есть что-то вроде username.domain.com
и домен одинаковый для всех имен хостов, это очень полезно.
После расследования apache
и nginx
, Я остановился на haproxy-1.5
. Версия 1.5 имеет встроенную поддержку https, которая мне нужна. После надлежащего haproxy.cfg
был написан для указания узлов балансировщика нагрузки, все, что мне нужно сделать после этого, это превратить мои экспортированные файлы сертификатов PFX в файлы PEM, используя openssl
, и выгрузите их в папку. Моя общая привязка будет работать нормально.
Конечно, у меня все еще есть обычные проблемы с обратным проксированием ... но ничего, кроме того, что я уже решил с помощью моего балансировщика ARR.
Вот часть моих haproxy.cfg
(продезинфицировано, конечно)
frontend http-in
bind *:80
bind *:443 ssl crt /media/windowsshare/myWindowsServer/ssl/pem/
default_backend myCluster
backend myCluster
server member1 10.4.0.184:80 maxconn 64
server member2 10.4.0.185:80 maxconn 64
Здесь вы говорите о двух разных концепциях:
SNI, возможность использовать TLS (SSL мертв) на основе имени хоста, поэтому вам не нужен отдельный IP-адрес для каждого сайта TLS.
Центральное хранилище сертификатов, которое просто меняет способ хранения сертификатов в IIS и упрощает их развертывание. Чтобы использовать CCS, вам необходимо определить имя хоста в привязке, поскольку оно используется для поиска правильного PFX-файла сертификата.
Но вы можете смешивать и сочетать, вы все равно можете использовать сертификаты, хранящиеся в старом хранилище сертификатов, для некоторых привязок и CSS для других.
Но у вас не может быть единой привязки для всего и указать ей использовать CCS.
Совет: Управляйте своими привязками и назначениями сертификатов в сценарии, никогда не щелкайте в диспетчере IIS.