Błąd protokołu SSL w farmie internetowej Auzre ze wspólną konfiguracją i scentralizowanymi certyfikatami

[Przepraszam, jeśli to pytanie jest trochę długie, istnieje wiele dodatkowych informacji na wypadek, gdyby było ono ponownie]

Przegląd

Mam problem z protokołem SSL w farmie z równoważeniem obciążenia 4 maszyn wirtualnych na platformie Azure. Jeśli żądanie HTTPS trafi do pierwszego serwera w farmie, wszystko jest w porządku. Jeśli dojdzie do którejkolwiek z pozostałych 3, połączenie nie powiedzie się. Chrome wyświetli błąd protokołu SSL, IE i Firefox po prostu stwierdzą, że strony nie można wyświetlić.

Ustawić

Mam cztery maszyny wirtualne z systemem Windows Server 2012 na platformie Azure (małe wystąpienie jako tylko testowanie). Maszyny wirtualne są w tej samej usłudze w chmurze i zestawie dostępności. Punkty końcowe zrównoważone obciążeniem zostały dodane dla portów 80 i 443 (bezpośredni powrót serwera NIE jest na nich włączony). Wszystkie cztery maszyny zostały skonfigurowane za pomocą tego samego skryptu PowerShell, z dwoma wyjątkami skonfigurowanymi w ten sposób.

Konfiguracja IIS każdego serwera jest skonfigurowana do używania konfiguracji udziału, która jest replikowana przez DFS do każdego serwera z pierwszego serwera w grupie. Zostało to ręcznie skonfigurowane dla każdego serwera i działa dobrze.

DFS służy również do replikacji folderu webs z pierwszego serwera na inne.

Odkryłem także „nową” funkcję scentralizowanych certyfikatów po napisaniu skryptu wdrażania, więc został on ręcznie zainstalowany i skonfigurowany również na czterech serwerach. Korzystam z udziału na oddzielnym serwerze do przechowywania plików certyfikatów.

Żądanie certyfikatu zostało wygenerowane na pierwszym serwerze, a ja skorzystałem z SSL.com, aby uzyskać 90-dniowy darmowy protokół SSL dla adresu subdomain.domain.com. Dodałem rekord CNAME dla subdomainDNS, aby domain.comwskazywał na cloudappadres platformy Azure .

Zaimportowałem certyfikat SSL na pierwszy serwer, a następnie wyeksportowałem go ponownie jako subdomain.domain.com.pfx(z hasłem) i skopiowałem go do udziału plików certyfikatów. Podczas sprawdzania scentralizowanych certyfikatów na wszystkich czterech serwerach, wystawiają certyfikat w porządku bez ikon błędów wskazujących, że hasło w konfiguracji było nieprawidłowe itp.

Na koniec zmieniłem powiązania serwera 1, aby dodać https z nazwą hosta subdomain.domain.comi zaznaczone opcje Wymagaj wskazania nazwy serwera i Użyj scentralizowanego magazynu certyfikatów . Sprawdzanie innych serwerów pokazuje powiązania propagowane zgodnie z oczekiwaniami.

Problem

Dodałem podstawową stronę, która po prostu wypluwa nazwę serwera, przez który żądanie zostało obsłużone. Jeśli mam powłokę dostępu do kilku okien przeglądarki IE http://subdomain.domain.com, wydrukują one różne nazwy serwerów, co pokazuje, że konfiguracja usług IIS i pliki sieciowe są wdrażane poprawnie, a funkcja równoważenia obciążenia platformy Azure robi to samo. Co naprawdę uważam za naprawdę fajne.

Jednak spada to, gdy próbuję tego za pośrednictwem HTTPS. Tylko żądania trafiające na pierwszy serwer są udane, reszta z nich ulega awarii i nagrywa z „Ta strona nie może zostać wyświetlona” lub „Błąd protokołu SSL” w zależności od przeglądarki, z którą testuję. Na serwerze 1 strona wyświetla się poprawnie, certyfikat jest widoczny i nie ma błędów certyfikatu.

Jestem pewien, że jest to gdzieś problem z konfiguracją serwerów, ale po prostu nie mogę powiedzieć, co to jest. Większość tego, co gram, jest dla mnie czymś nowym, ponieważ w przeszłości używaliśmy fizycznych nieklastrowych serwerów Windows 2003 z IIS6.

Jeszcze bardziej kłopotliwe jest to, że zamknąłem cztery maszyny wirtualne na noc, a kiedy ponownie uruchomiłem usługę dziś rano, serwer 2 najwyraźniej teraz odpowiada na żądania SSL oprócz serwera 1. Mimo to powiedziałem, wczoraj również całkowicie zamknąłem i nadal działał tylko serwer 1.

Pliki dziennika IIS nie pokazują nieudanych żądań SSL, tylko kilka 200 dla portu 80 i połączenie 200 i 304 dla portu 443 na serwerze 1 i 2.

Zrobiłem należytą staranność przy wyszukiwaniu w Google, ale nic nie rzuca światła. Wręcz przeciwnie, z tego, co mogę powiedzieć, to, co zrobiłem, powinno działać.

Jakakolwiek rada, która pomoże rozwiązać ten problem, zostanie przyjęta z wdzięcznością.

Chciałem udostępnić kilka kroków, które powinny rozwiązać większość problemów ze scentralizowanym magazynem certyfikatów w usługach IIS. Centralny magazyn certyfikatów (CCS) tworzy fałszywe powiązanie certyfikatu, którego używa do kierowania żądań certyfikatów SSL do CCS. Jeśli to powiązanie nie jest obecne lub istnieje wiele powiązań na tym samym adresie IP, będziesz otrzymywać błędy przeglądarki, gdy klienci będą próbowali połączyć się ze stronami internetowymi z obsługą SSL.

Rozważ następującą konfigurację; serwer IIS z 172.16.0.41włączonym adresem IP i scentralizowanym magazynem certyfikatów zawiera dwie domeny; www.adomain.coma www.bdomain.com. Pakiety certyfikatów PFX są instalowane w centralnym magazynie certyfikatów IIS dla każdej domeny.

Zazwyczaj występują dwa błędy;

PROBLEM 1

Gdy przeglądarki łączą się z witryną, niewłaściwy certyfikat jest udostępniany. Na przykład wizyta www.adomain.compo raz pierwszy powoduje wyświetlenie poprawnego certyfikatu, jednak podczas odwiedzania przeglądarki www.bdomain.comcertyfikat www.adomain.comjest zwracany, co powoduje, że przeglądarka zgłasza błąd nieprawidłowego certyfikatu.

ROZWIĄZANIE

Przyczyną tego problemu jest zwykle to, że wiele witryn jest powiązanych z tym samym adresem IP i co najmniej jedna z nich nie włączyła Wymagaj identyfikacji nazwy serwera . Bez tego ustawienia włączonego dla wszystkich stron internetowych współużytkujących ten sam adres IP i PORT, IIS nie jest w stanie określić, który certyfikat ma być obsługiwany, dlatego wydaje się, że zastosowanie ma zasada pierwszego w wygranych .

Oznacza to, że kolejne żądania kierowane do innych witryn hostowanych na tym samym serwerze IIS zwracają niewłaściwy certyfikat.

Kroki do rozwiązania

1. Upewnij się, że każda witryna jest ustawiona na Require Server Name Identification. Zrób to, klikając każdą stronę w Menedżerze IIS, wybierając Wiązania ...-> Wybierz wiązanie HTTPS-> Wybierz Edytuj-> Sprawdź Require Server Name Identificationi upewnij się, że Use Centralized Certificate Storejest również zaznaczone.

2. Sprawdź powiązania na serwerze. Z poziomu komendy z podwyższonym poziomem uprawnień wykonaj polecenienetsh http show sslcert

Wiązanie dla CCS powinno być obecne:

SSL Certificate bindings:
------------------------- 

Central Certificate Store    : 443
Certificate Hash             : (null)
Application ID               : {4dc3e181-e14b-4a21-b022-59fc669b0914}
Certificate Store Name       : (null)
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check                  : Enabled
Revocation Freshness Time    : 0
URL Retrieval Timeout        : 0
Ctl Identifier               : (null)
Ctl Store Name               : (null)
DS Mapper Usage              : Disabled
Negotiate Client Certificate : Disabled

Uwaga: powiązanie z (null)funkcją skrótu certyfikatu wskazuje na obecność przejścia CCS przez wiązanie. Jeśli istnieją inne powiązania nasłuchujące na adresie IP serwera i porcie SSL ( 172.16.0.41:443w naszym scenariuszu), należy je usunąć.

2. Aby usunąć powiązania, wpisz netsh http delete sslcert <binding>. W naszym scenariuszu byłoby to netsh http delete sslcert 172.16.0.41:443i powiązanie powinno zostać usunięte. (null)Wiążące passthrough CCS nie powinny zostać usunięte. Jeśli to wiązanie nie jest obecne, patrz PROBLEM 2 poniżej.

3. Zresetuj iis za pomocą iisreseti połącz się z każdą domeną na serwerze WWW. Prawidłowy certyfikat powinien zostać udostępniony. Można również sprawdzić powiązania, powtarzając krok 2 i upewniając się, że nie istnieją żadne specyficzne IP:PORTpowiązania z portem SSL i adresem IP serwera WWW.

PROBLEM 2

Nawet po potwierdzeniu, że scentralizowany magazyn certyfikatów jest włączony, ma widoczność na certyfikatach i wszystkie strony internetowe muszą z niego korzystać, gdy przeglądarka łączy się z witryną, zgłasza błąd Page Cannot be displayedlub invalid encryptionbłąd. Planowana witryna nie wyświetla się.

W IE (Edge) zazwyczaj objawia się to jako sugestia sprawdzenia, czy odpowiednie typy szyfrowania są włączone w przeglądarce.

iisresetLub restart serwera nie rozwiąże problemu.

ROZWIĄZANIE

To wydaje się być błędem w tworzeniu powiązania tranzytowego CCS. Nie jest tworzony na serwerze internetowym, gdy funkcja CCS jest włączona, więc przychodzące żądania certyfikatu są po cichu usuwane.

Kroki do rozwiązania

1. Najpierw sprawdź, czy centralny magazyn certyfikatów został włączony i może zobaczyć wszystkie certyfikaty na swojej ścieżce. Aby to zrobić, zaznacz IISManagerwęzeł serwera-> Certyfikaty scentralizowane (w sekcji Zarządzanie) -> Edytuj ustawienia funkcji.

2. Sprawdź, czy wszystkie strony internetowe korzystające ze wspólnych certyfikatów są powiązane z CCS. Zrób to, klikając każdą stronę w Menedżerze IIS, wybierając Wiązania ...-> Wybierz wiązanie HTTPS-> Wybierz Edytuj-> Sprawdź Require Server Name Identificationi upewnij się, że Use Centralized Certificate Storejest również zaznaczone.

3. Sprawdź, czy powiązanie CCS zostało utworzone. Uruchom netsh http show sslcert. Jeśli wyniki są puste lub (null)certyfikat przekazywania nie jest obecny (patrz krok 2 w PROBLEMIE 1, aby zobaczyć, jak wygląda powiązanie CCS), powiązanie CCS nie zostało włączone.

   SSL Certificate bindings:
   -------------------------
   

4. W Menedżerze IIS, wybierając jedną stronę internetową, która korzysta z CCS, kliknij Wiązania ...-> Wybierz wiązanie HTTPS-> Wybierz Edytuj-> i odznacz Use Centralized Certificate Store i odznacz Require Server Name Identification .

Z SSL certificaterozwijanego menu wybierz domyślny WMSVCcertyfikat serwera i kliknij OK. Pozostaw Site Bindingsokno otwarte.

5. Wróć do wiersza polecenia z podwyższonym poziomem uprawnień i uruchom netsh http show sslcert. Powinno to dać takie powiązanie:

   SSL Certificate bindings:
   ------------------------- 
   IP:port                      : 172.16.0.41:443
   Certificate Hash             : 64498c920fecb31b8f7ccbdac2fa2baa2ec4f19a
   Application ID               : {4dc3e181-e14b-4a21-b022-59fc669b0914}
   Certificate Store Name       : My
   Verify Client Certificate Revocation : Enabled
   Verify Revocation Using Cached Client Certificate Only : Disabled
   Usage Check                  : Enabled
   Revocation Freshness Time    : 0
   URL Retrieval Timeout        : 0
   Ctl Identifier               : (null)
   Ctl Store Name               : (null)
   DS Mapper Usage              : Disabled
   Negotiate Client Certificate : Disabled
   

6. Powrócić do Site Bindingsokna i cofnąć zmiany od kroku 4. Włączanie Require Server Name Indicationi Use Centralized Certificate Storei kliknij OK.

7. Wróć do wiersza polecenia z podwyższonym poziomem uprawnień i uruchom netsh http show sslcertponownie, a jeśli bogowie się do ciebie uśmiechną, powiązanie Centralnego Sklepu Certyfikatów powinno pęknąć, zastępując obecne wiązanie:

     SSL Certificate bindings:
     -------------------------
   
     Central Certificate Store    : 443
     Certificate Hash             : (null)
     Application ID               : {4dc3e181-e14b-4a21-b022-59fc669b0914}
     Certificate Store Name       : (null)
     Verify Client Certificate Revocation : Enabled
     Verify Revocation Using Cached Client Certificate Only : Disabled
     Usage Check                  : Enabled
     Revocation Freshness Time    : 0
     URL Retrieval Timeout        : 0
    Ctl Identifier               : (null)
    Ctl Store Name               : (null)
    DS Mapper Usage              : Disabled
    Negotiate Client Certificate : Disabled
   

Jeśli widzisz powyższy certyfikat wiążący z (null)wycenionym Certificate Hash, zadziałał i przejście CSS powinno być teraz włączone.

8. Uruchom przeglądarkę i spróbuj połączyć się z domenami na serwerze za pośrednictwem bezpiecznego gniazda (HTTPS) i wszystko powinno być w porządku.

Ważne notatki

• Musisz powtórzyć ten proces na każdym serwerze internetowym w swojej farmie internetowej. Powinno być wykonalne za pomocą programu PowerShell, aby zautomatyzować i sprawdzić proces.

• Po utworzeniu powiązania tranzytowego zostanie ono zachowane na czas nieokreślony (chyba że wyłączysz obsługę Centralnego Certyfikatu w węźle).

Tak na marginesie; ten link zawiera informacje o tym, jak działa CCS na poziomie technicznym i jest wart przeczytania: https://blogs.msdn.microsoft.com/kaushal/2012/10/11/central-certificate-store-ccs-with-iis -8-windows-server-2012 /

Mam nadzieję że to pomogło.