Сертифікати SNI та wildcard SSL на одному сервері з IIS

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

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

Чи може така установка розміщуватися на тому самому IIS (якщо це має значення в веб-ролі служби Azure Cloud Service)?

Проблема полягає саме в тому, що titobf пояснив тут : теоретично для цього нам знадобляться прив’язки за допомогою SNI, з хостом, вказаним для domain2 / 3.com, а потім загальнодоступним веб-сайтом з * хостом для * .domain.com. Але на практиці, незалежно від того, як налаштовані прив'язки, якщо веб-сайт "catch-all" на ньому, він також отримуватиме всі запити до domain2 / 3.com (хоча, мабуть, він відповідає лише в крайньому випадку).

Будь-яка допомога буде вдячна.

Досі нерозв’язаний

На жаль, мені це не вдалося вирішити: це, здається, вирішується лише надзвичайно складними способами, як, наприклад, створення програмного забезпечення, яке сидить між IIS та Інтернетом (так, в основному, брандмауер) та модифікує вхідні запити (до того, як відбудеться рукостискання SSL! ), щоб дозволити сценарій. Я досить впевнений, що з IIS це неможливо, навіть не з рідного модуля.

Я маю уточнити: ми використовуємо служби Cloud Cloud, тому ми маємо додаткове обмеження, що ми не можемо використовувати декілька IP-адрес (див .: http://feedback.azure.com/forums/169386-cloud-services-web-and -робоча роль / пропозиції / 1259311-кілька-ssl-і-домени-до-одного-додаток ). Якщо ви можете вказати кілька IP-адрес на ваш сервер, у вас цього питання не виникає, оскільки ви також можете створити прив’язки для IP-адрес, і вони працюватимуть разом прив'язки підстановки. Більш конкретно, вам потрібен IP-адрес для сайту wildcard (але, оскільки у вас є окремий IP-адресу, вам не доведеться налаштовувати прізвище хоста-підключення wildcard) та інший IP-адресу для всіх інших, що не мають wildcard.

Насправді наше вирішення полягало у використанні нестандартного порту 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.4543) завжди має перевагу в http.sys! Тож рішення таке:

Не налаштовуйте прив’язку IP: 443 для вашого сертифікату підстановки, але конфігуруйте прив'язку *: 443 (* означає "Усі непризначені") .

Якщо ви налаштували свій сертифікат підстановки на кінцевій точці служби SSL служби Azure (як у мене), ви повинні змінити прив'язку SSL, створену програмою служби служби Azure Cloud (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, навіть у лазерних веб-ролях хмарних служб, хоча ви не можете дійти до конфігурації через портал, і якщо ви зробите це у вікні після розгортання, він буде стертий при наступному розгортанні. Рішення полягає в автоматизації конфігурації. Подивіться тут деталі:

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