Certyfikaty SNI i wieloznaczne SSL na tym samym serwerze z IIS

12

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ń). Wiązania

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.

Piedone
źródło
Powinieneś absolutnie być w stanie to zrobić na IIS za pomocą SNI, bez uciekania się do wielu adresów IP lub niestandardowych portów.
Joe Sniderman
Masz na myśli, że usługi IIS powinny to obsługiwać? Zgadzam się :-).
Piedone
Całkowicie się z tobą zgadzam, Piedone. Jestem naprawdę rozczarowany, że IIS (a ściślej http.sys) NIE obsługuje kombinacji certyfikatu wieloznacznego jako domyślnego certyfikatu SSL i wielu konkretnych certyfikatów z SNI JAK OCZEKIWANO. Problem jest dobrze znany od 2012 roku, jak widać tutaj: forums.iis.net/t/1192170.aspx . Właśnie napisałem wiadomość e-mail do firmy Microsoft i mam nadzieję, że wkrótce otrzymam opinię.
Tobias J.
Dzięki, Tobiaszu. Wróć tutaj, gdy Microsoft odpowie.
Piedone
2
Prawdopodobnie http.sys odrzuca to żądanie, więc żadne nieudane żądanie nie jest rejestrowane w IIS. Utwórz dziennik śledzenia ETW http.sys: 1) uruchom dziennik śledzenia. uruchom: logman start httptrace -p Microsoft-Windows-HttpService 0xFFFF -o httptrace.etl -ets2) wykonaj żądanie 503 3) zatrzymaj dziennik śledzenia. uruchom: logman stop httptrace -ets4) zapisz dziennik śledzenia do pliku. uruchom: tracerpt.exe httptrace.etl -of XML -o httptrace.xml5) sprawdź przyczynę 503 w pliku xml i opublikuj ją tutaj.
Tobias J.,

Odpowiedzi:

6

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.

działająca konfiguracja IIS

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.

Tobias J.
źródło
Dziękuję za szczegółową odpowiedź. Zaktualizowałem swoje pytanie: jak pamiętam, prawdopodobnie nie poszedłem z tą konfiguracją, ponieważ dostałem ten sam błąd co teraz.
Piedone
4

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).

bariscaglar
źródło
Dzięki, ale jak widać w moim opisie, początkowo próbowałem skonfigurować powiązanie SNI bez portu, ale ponieważ to nie zadziałało, skończyłem z niestandardowym powiązaniem portu.
Piedone
Przez port uważam, że masz na myśli adres IP. Nie możesz mieć powiązania bez portu. Inetmgr na to nie pozwoli. W przypadku powiązań SNI możesz użyć określonego adresu IP lub „Wszystkich nieprzypisanych”, a wynik będzie taki sam. Jest to wiązanie Catch All, dla którego masz certyfikat wieloznaczny, który musi znajdować się na „Wszystkie nieprzypisane”, a nie na konkretnym adresie IP.
bariscaglar
Miałem na myśli port, ale chciałem powiedzieć „port niestandardowy”. Adres IP nie został określony, tak jak mówisz i nadal nie działa, zobacz także link Tobiasza. Istnieją dwa sposoby obejścia tego ograniczenia usług IIS: użyj niestandardowego portu lub adresu IP innego niż inne wiązania: w usługach w chmurze Azure ten ostatni nie jest dostępny, więc wybraliśmy niestandardowy port.
Piedone
bariscaglar jest programistą Microsoft (pracuje nad IIS), z którym miałem bardzo miłą i pomocną rozmowę! Dzięki Baris! Razem przeanalizowaliśmy zachowanie i doszliśmy do wniosku, że opisane zachowanie jest pożądanym zachowaniem http.sys. Ale jest dobre obejście. Zobacz moją odpowiedź, aby poznać szczegóły.
Tobias J.,
Notatka dla każdego, kto czyta, niedawno odkryłem, że jeśli używasz Azure Portal do skonfigurowania usługi dla Pulpitu zdalnego (lub w inny sposób zmienisz konfigurację certyfikatu), może to spowodować automatyczne utworzenie powiązania adresu IP: Port i zerwanie całego SNI . Nie mam rozwiązania tego konkretnego problemu. Zdarza się to po RoleEnvironment.Changed, więc nie mogę go złapać w WebRole.cs.
Mike
1

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/

CamW
źródło
Dzięki, ale jak już wyjaśniłem, nie ma problemu z samym SNI (używam go), ale raczej jak działa dopasowywanie nazw hostów z użyciem symboli zastępczych w IIS.
Piedone
Ten artykuł już nie istnieje, ale znajduje się w Archiwum internetowym: web.archive.org/web/20151020041907/http://www.vic.ms/microsoft/…
Mike