Certyfikaty SNI i wieloznaczne SSL na tym samym serwerze z IIS

Chciałbym hostować stronę internetową, która powinna słuchać subdomen (np. Sub.domain.com) wraz z wieloma stronami internetowymi, które żyją tuż pod domeną drugiego poziomu (np. Domain2.com, domain3.com) z IIS i SSL.

W przypadku witryny z poddomenami mam certyfikat wieloznaczny (* .domain.com), a także certyfikaty specjalnie dla innych witryn (domain2.com i domain3.com).

Czy taka konfiguracja może być hostowana na tym samym IIS (jeśli to ma znaczenie, w roli sieciowej Azure Cloud Service)?

Problem polega dokładnie na tym, co wyjaśnił titobf : teoretycznie do tego potrzebowalibyśmy powiązań za pomocą SNI, z hostem określonym dla domain2 / 3.com, a następnie witryną typu catch-all z * host dla * .domain.com. Ale w praktyce, bez względu na to, jak skonfigurowane są powiązania, jeśli witryna catch-all znajduje się na niej, otrzyma ona również wszystkie żądania do domain2 / 3.com (choć podobno jest ona dopasowana tylko w ostateczności).

Każda pomoc będzie mile widziana.

Wciąż nierozwiązane

Niestety nie byłem w stanie rozwiązać tego problemu: wydaje się, że można go rozwiązać tylko w bardzo skomplikowany sposób, na przykład tworząc oprogramowanie, które znajduje się między IIS a Internetem (czyli w zasadzie zaporą ogniową) i modyfikuje przychodzące żądania (zanim nastąpi uzgadnianie SSL! ), aby umożliwić scenariusz. Jestem całkiem pewien, że nie jest to możliwe w IIS, bez względu na wszystko, nawet z natywnego modułu.

Muszę wyjaśnić: korzystamy z usług Azure Cloud Services, więc mamy dodatkowe ograniczenie, że nie możemy używać wielu adresów IP (patrz: http://feedback.azure.com/forums/169386-cloud-services-web-and -worker-role / sugestie / 1259311-multiple-ssl-and-domains-to-one-app ). Jeśli możesz wskazać wiele adresów IP na serwerze, nie masz tego problemu, ponieważ możesz także tworzyć powiązania dla adresów IP, które będą ze sobą współdziałać. Mówiąc dokładniej, potrzebujesz adresu IP dla strony z symbolami wieloznacznymi (ale ponieważ masz teraz osobny adres IP, nie musisz konfigurować wiązania nazwy hosta z symbolami wieloznacznymi) i innego adresu IP dla wszystkich tych, które nie są symbolami wieloznacznymi.

W rzeczywistości naszym obejściem było użycie niestandardowego portu SSL, 8443. Tak więc powiązanie SNI jest faktycznie powiązane z tym portem, a zatem działa razem z innymi powiązaniami. Nie jest to przyjemne, ale akceptowalne obejście dla nas, dopóki nie możesz używać wielu adresów IP do ról internetowych.

Niedziałające wiązania teraz

Pierwsze wiązanie https to SNI z prostym certyfikatem, drugie to nie SNI, z certyfikatem wieloznacznym.

Witryna http działa, podobnie jak witryna SNI https, ale strona z powiązaniem ze znakiem wieloznacznym podaje „Błąd HTTP 503. Usługa jest niedostępna”. (bez dalszych informacji, brak śledzenia nieudanego żądania lub wpisu do dziennika zdarzeń).

Nareszcie to działa

Włączenie dziennika śledzenia ETW, tak jak opisano Tobiasza, pokazało, że błąd root był następujący:

Żądanie (identyfikator żądania 0xF500000080000008) odrzucone z powodu przyczyny: UrlGroupLookupFailed.

O ile rozumiem, oznacza to, że http.sys nie jest w stanie skierować żądania do żadnego dostępnego punktu końcowego.

Sprawdzanie zarejestrowanych punktów końcowych za pomocą netsh http show urlaclpokazało, że rzeczywiście zarejestrowano coś dla portu 443:

Reserved URL            : https://IP:443/
    User: NT AUTHORITY\NETWORK SERVICE
        Listen: Yes
        Delegate: No
        SDDL: D:(A;;GX;;;NS)

Usunięcie tego z netsh http delete urlacl url=https://IP:443/wreszcie włączyło moje wiązanie SSL.

Baris ma rację! Certyfikat SSL skonfigurowany w powiązaniu IP: PORT (przykład: 100.74.156.187:443) zawsze ma pierwszeństwo w http.sys! Tak więc rozwiązanie jest następujące:

Nie konfiguruj powiązania IP: 443 dla certyfikatu zastępczego zastępczego, ale skonfiguruj dla niego powiązanie *: 443 (* oznacza „Wszystkie nieprzypisane”) .

Jeśli skonfigurowałeś swój znak wieloznaczny na punkcie końcowym SSL usługi w chmurze Azure (tak jak ja), musisz zmienić powiązanie SSL utworzone przez środowisko uruchomieniowe usługi w chmurze Azure (IISconfigurator.exe) z IP: PORT na *: PORT. Wywołuję następującą metodę w OnStart mojej roli internetowej:

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());
        }
    }
}

Poniższy zrzut ekranu pokazuje działającą konfigurację naszej usługi w chmurze. Nie należy mylić niestandardowych portów. Zrzut ekranu pochodzi z emulowanej usługi w chmurze.

Jeszcze jedna rzecz do wspomnienia: Nie zmieniaj wszystkich powiązań na *, ponieważ powiązanie HTTP (port 80) działa tylko z powiązaniem IP: PORT we wdrożonej usłudze chmurowej. Coś innego wiąże się z adresem IP: 80, więc *: 80 nie działa, ponieważ * oznacza „wszystkie nieprzypisane”, a adres IP jest już przypisany w innym miejscu w http.sys.

Upewnij się, że twoje wiązanie typu catch-all nie jest typu IP: Port. Jeśli istnieje powiązanie IP: Port dla powiązania HTTPS, podczas gdy SNI nie jest wymagane, powiązanie to zawsze będzie miało pierwszeństwo. W przypadku catch-all użyj powiązania *: Port (* oznacza to, że wszystkie są nieprzypisane).

Usługi IIS obsługują SNI, nawet w rolach internetowych usługi w chmurze lazurowej, chociaż nie można dostać się do konfiguracji przez portal, a jeśli zrobisz to na pudełku po wdrożeniu, zostanie wyczyszczony przy następnym wdrożeniu. Rozwiązaniem jest zautomatyzowanie konfiguracji. Zobacz szczegóły:

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