SNI и подстановочные SSL-сертификаты на одном сервере с IIS

Я хотел бы разместить веб-сайт, который должен прослушивать субдомены (например, sub.domain.com) вместе с несколькими веб-сайтами, которые живут только под доменом второго уровня (например, domain2.com, domain3.com) с IIS и с SSL.

Для веб-сайта с поддоменами у меня есть подстановочный сертификат (* .domain.com), а также сертификаты специально для других сайтов (domain2.com и domain3.com).

Можно ли разместить такую ​​настройку на том же IIS (если это важно, в веб-роли облачной службы Azure)?

Проблема именно в том, что пояснил Titobf : теоретически для этого нам понадобятся привязки с использованием SNI с хостом, указанным для domain2 / 3.com, а затем с универсальным веб-сайтом с * host для * .domain.com. Но на практике, независимо от того, как устанавливаются привязки, если веб-сайт перехвата включен, он также будет получать все запросы к домену 2 / 3.com (хотя, предположительно, он соответствует только в качестве последнего средства).

Любая помощь будет оценена.

Все еще не решено

К сожалению, я не смог решить эту проблему: кажется, что это можно решить только чрезвычайно сложными способами, такими как создание программного обеспечения, которое находится между IIS и Интернетом (то есть, в основном, брандмауэром) и изменяет входящие запросы (до того, как произойдет рукопожатие SSL! ) разрешить сценарий. Я вполне уверен, что это невозможно с IIS, несмотря ни на что, даже из родного модуля.

Я должен уточнить: мы используем облачные службы Azure, поэтому у нас есть еще одно ограничение: мы не можем использовать несколько IP-адресов (см. Http://feedback.azure.com/forums/169386-cloud-services-web-and -worker-role / ideas / 1259311-множественные ssl-and-domains-to-one-app ). Если вы можете указать несколько IP-адресов для вашего сервера, то у вас нет этой проблемы, поскольку вы можете создавать привязки для IP-адресов, и они будут работать вместе с подстановочными знаками. Более конкретно, вам нужен IP-адрес для сайта с подстановочными знаками (но поскольку у вас есть отдельный IP-адрес, теперь вам не нужно настраивать привязку имени узла с подстановочными знаками) и еще один IP-адрес для всех других подстановочных знаков.

На самом деле наш обходной путь - использование нестандартного порта SSL, 8443. Таким образом, привязка SNI фактически привязана к этому порту, поэтому она работает вместе с другими привязками. Не очень, но приемлемый обходной путь для нас, пока вы не можете использовать несколько IP-адресов для веб-ролей.

Нерабочие привязки сейчас

Первая привязка https - это SNI с простым сертификатом, вторая - не SNI, с подстановочным сертификатом.

Сайт http работает так же, как и сайт SNI https, но сайт с подстановочными знаками выдает «Ошибка HTTP 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 для своего подстановочного-резервного сертификата, но настройте привязку *: 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: порт. Если для привязки HTTPS существует привязка IP: порт, а SNI не требуется, эта привязка всегда будет иметь приоритет. В вашем общем случае используйте привязку *: Port (* - все неназначенные).

IIS поддерживает SNI даже в веб-ролях облачной службы Azure, хотя вы не можете получить доступ к конфигурации через портал, и если вы сделаете это в поле после развертывания, оно будет удалено при следующем развертывании. Решение состоит в том, чтобы автоматизировать конфиг. Посмотрите здесь для деталей:

http://www.vic.ms/microsoft/windows-azure/multiples-ssl-certificates-on-windows-azure-cloud-services/