Сертификаты SNI и подстановочные SSL-сертификаты на одном сервере с IIS
Я хотел бы разместить веб-сайт, который должен прослушивать поддомены (например, sub.domain.com) вместе с несколькими веб-сайтами, которые живут непосредственно под доменом второго уровня (например, domain2.com, domain3.com) с IIS и с SSL.
Для веб-сайта с поддоменами у меня есть подстановочный сертификат (* .domain.com), а также сертификаты специально для других сайтов (domain2.com и domain3.com).
Можно ли разместить такую установку в том же IIS (если это важно, в веб-роли облачной службы Azure)?
Вопрос в том, в чем именно титобф объяснено здесь: теоретически для этого нам понадобятся привязки с использованием SNI, с указанием хоста для domain2 / 3.com, а затем универсального веб-сайта с * host для * .domain.com. Но на практике, независимо от того, как настроены привязки, если веб-сайт для приема всей почты домена находится на нем, он также будет получать все запросы к domain2 / 3.com (хотя предположительно он сопоставляется только в крайнем случае).
Любая помощь будет оценена.
Все еще не решено
К сожалению, я не смог решить эту проблему: кажется, что это можно решить только чрезвычайно сложными способами, такими как создание программного обеспечения, которое находится между IIS и Интернетом (то есть в основном брандмауэром) и изменяет входящие запросы (до того, как произойдет рукопожатие SSL! ), чтобы разрешить сценарий. Я совершенно уверен, что это невозможно с IIS, несмотря ни на что, даже из собственного модуля.
Я должен уточнить: мы используем облачные службы Azure, поэтому у нас есть еще одно ограничение - мы не можем использовать несколько IP-адресов (см. http://feedback.azure.com/forums/169386-cloud-services-web-and-worker-role/suggestions/1259311-multiple-ssl-and-domains-to-one-app). Если вы можете указать несколько IP-адресов на свой сервер, тогда у вас нет этой проблемы, поскольку вы также можете создавать привязки для IP-адресов, и они будут работать вместе с привязками с подстановочными знаками. В частности, вам нужен IP-адрес для сайта с подстановочными знаками (но поскольку теперь у вас есть отдельный IP-адрес, вам не нужно настраивать привязку имени хоста с подстановочными знаками) и другой IP-адрес для всех остальных без подстановочных знаков.
Фактически наш обходной путь заключался в использовании нестандартного порта SSL, 8443. Таким образом, привязка SNI фактически привязана к этому порту, поэтому она работает вместе с другими привязками. Неприятно, но приемлемый обходной путь для нас, пока вы не сможете использовать несколько IP-адресов для веб-ролей.
Нерабочие привязки сейчас
Первая привязка https - это SNI с простым сертификатом, вторая - не SNI с подстановочным сертификатом.
Сайт http работает так же, как и сайт SNI https, но тот, у которого есть привязка с подстановочными знаками, выдает ошибку «HTTP Error 503. Служба недоступна». (без какой-либо дополнительной информации, без отслеживания неудачных запросов или записи в журнале событий). 
Наконец-то он в основном работает
Включение журнала трассировки ETW, как описал Тобиас, показало, что основная ошибка была следующей:
Запрос (идентификатор запроса 0xF500000080000008) отклонен по причине: UrlGroupLookupFailed.
Насколько я понимаю, это означает, что http.sys не может направить запрос на любую доступную конечную точку.
Проверка зарегистрированных конечных точек с помощью netsh http show urlacl показал, что для порта 443 действительно что-то было зарегистрировано:
Reserved URL : https://IP:443/
User: NT AUTHORITY\NETWORK SERVICE
Listen: Yes
Delegate: No
SDDL: D:(A;;GX;;;NS)
Удаление этого с помощью netsh http delete urlacl url=https://IP:443/ наконец-то включил мою привязку SSL.
Барис прав! Сертификат SSL, настроенный для привязки IP: PORT (пример: 100.74.156.187:443), всегда имеет приоритет в http.sys! Итак, решение следующее:
Не настраивайте привязку IP: 443 для своего wildcard-fallback-сертификата, а настройте для него привязку *: 443 (* означает «Все неназначенные»)..
Если вы настроили подстановочный сертификат в конечной точке SSL облачной службы Azure (как и я), вам необходимо изменить привязку SSL, созданную средой выполнения облачной службы Azure (IISconfigurator.exe), с IP: PORT на *: PORT. Я вызываю следующий метод в OnStart моей веб-роли:
public static void UnbindDefaultSslBindingFromIp()
{
Trace.TraceInformation(">> IISTenantManager: Unbind default SSL binding from IP");
using (var serverManager = new Microsoft.Web.Administration.ServerManager())
{
try
{
var websiteName = string.Format("{0}_Web", Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironment.CurrentRoleInstance.Id);
var site = serverManager.Sites[websiteName];
var defaultSslBinding = site.Bindings.Single(b => b.IsIPPortHostBinding && b.Protocol == "https");
defaultSslBinding.BindingInformation = string.Format("*:{0}:", defaultSslBinding.EndPoint.Port);
serverManager.CommitChanges();
}
catch (Exception ex)
{
Trace.TraceError(ex.ToString());
}
}
}
На следующем снимке экрана показана рабочая конфигурация нашей облачной службы. Пожалуйста, не путайте нестандартные порты. Снимок экрана взят из эмулируемой облачной службы.
Еще одно замечание: не менять все привязки к *, поскольку привязка HTTP (порт 80) работает только с привязкой IP: PORT в развернутой облачной службе. Что-то еще привязано к IP: 80, поэтому *: 80 не работает, потому что * означает «все неназначенные», а IP уже назначен где-то еще в http.sys.
Убедитесь, что ваша всеобъемлющая привязка не относится к типу IP: Port. Если привязка IP: Port существует для привязки HTTPS, а SNI не требуется, эта привязка всегда будет иметь приоритет. Для вашего всеобъемлющего случая используйте привязку *: Port (* означает все неназначенные).
IIS поддерживает SNI даже в веб-ролях облачной службы Azure, хотя вы не можете получить доступ к конфигурации через портал, и если вы сделаете это на коробке после развертывания, она будет удалена при следующем развертывании. Решение - автоматизировать config. Подробности смотрите здесь: