SNI na serwerze WWW

SNI, czyli Server Name Indication, to rozszerzenie protokołu TLS, które pozwala na wystawianie i przypisywanie certyfikatów do wielu hostów funkcjonujących pod tym samym adresem IP. Dzięki temu można zabezpieczyć wiele stron po HTTPS na jednym serwerze. W praktyce wygląda to tak. Zakładamy, że mamy dwie domeny – mojadomena1.com i mojadomena2.com. Strony są hostowane na jednym serwerze posiadający jeden adres IP. Chcemy je zabezpieczyć po HTTPS. Musimy zatem wystawić dla nich certyfikat. Możemy to zrobić używając Let’s Encrypt.

W przypadku IIS program automatycznie wykryje przypisane hosty i wystawi certyfikat na mojadomena1.com. Ona będzie widniała prawdopodobnie na certyfikacie. Ale będzie mogła również korzystać z niego mojadomena2.com. Kiedy łączymy się z stroną serwer musi wiedzieć jaką stronę otworzyć. W końcu obydwie są pod tym samym adresem IP i porcie 80. Tutaj właśnie wkracza SNI. On dokładnie mówi, która domena do jakiej strony jest przypisana i przekierowuje użytkownika na właściwą.

SNI – Obsługa po stronie serwera i klienta

Aby SNI prawidłowo działało musi być wspierane zarówno po stronie serwera jak i użytkownika. Użytkownik w tym wypadku musi posiadać kompatybilną przeglądarkę internetową, która ma zaimplementowane SNI. Obecnie już większość to ma także nie ma się tutaj czego obawiać. Sprawa wygląda gorzej po stronie serwera. Systemy Linux uzależnione są od pakietów. Wystarczy zaktualizować Apache lub NGNIX, a SNI będzie już obsługiwane. Gorzej wygląda w przypadku Windows Server.

IIS jest w większym stopniu uzależnione od systemu operacyjnego. Im nowszy tym nowsza wersja usługi. IIS ma zaimplementowane SNI, ale dopiero od wersji 8.0. Czyli wymagana wersja systemu to minimum Windows Server 2012. Administratorzy starszych wersji będą mieć problem. SNI jest niezbędne jeśli chcemy hostować strony z certyfikatym na tym samym adresie IP i pod tym samym portem. Najczęściej 80. Windows Server 2008 R2 i Windows 7 to ostatnie systemy, które posiadają IIS 7.5 bez wsparcia SNI. Istnieje obejście tego problemu w postaci zmiany oprogramowania na przykład na Apache, ale nie zawsze jest to możliwe. Szczególnie jeśli hostujemy strony napisane w ASP.NET. W tej sytuacji pozostaje zmiana numerów portów dla każdej strony, albo aktualizacja całego systemu.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *