Wypisz nazwy hostów, zależności i właścicieli
Wymień każdą nazwę hosta, z której korzystają odwiedzający lub integracje: apex, www, subdomeny, API, hosty zasobów, portale i nazwy regionalne. Dla każdej zanotuj, gdzie kończy się TLS, kto może to zmieniać, zakres certyfikatu i termin ważności, metodę odnawiania oraz zależności, które generują URL-e. Certyfikat musi obejmować żądaną nazwę hosta w polu Subject Alternative Name. Uwzględnij CMS, CDN, menedżer tagów, magazyn obiektów, dostawcę płatności, szablony e-mail, i osadzenia stron trzecich; to one często wprowadzają adresy HTTP po pierwszym wdrożeniu HTTPS.
Wybierz kanoniczny adres z www albo domenę główną (bez subdomeny) i przekieruj drugi wariant bezpośrednio na niego przez HTTPS.
Wdróż certyfikat i aktualne wersje TLS
Skonfiguruj serwer WWW, odwrotne proxy, CDN lub moduł równoważenia obciążenia, który odpowiada na publiczne żądania. Zainstaluj certyfikat wraz z wymaganym łańcuchem certyfikatów, przypisz je do właściwych nazw i zweryfikuj spoza sieci hostingowej. Przeglądarka sprawdza łańcuch, nazwę hosta i daty; widoczne publicznie ostrzeżenie blokuje wydanie. Domyślnie używaj TLS 1.3, a TLS 1.2 pozostaw tylko tam, gdzie jest potrzebny ze względów kompatybilności. Wyłącz SSL oraz TLS 1.0 i 1.1. Stosuj aktualne zalecenia platformy zamiast kopiować przestarzałe listy szyfrów oraz regularnie aktualizuj serwer i bibliotekę TLS.
Ogranicz dostęp do kluczy prywatnych i zanotuj każdy system, który korzysta z danego klucza, aby jego wymiana objęła wszystkie te systemy.
Przekieruj HTTP raz i ustal HTTPS jako kanoniczne
Zwracaj trwałe przekierowanie po stronie serwera — zwykle 301 lub 308 — z każdego adresu HTTP na odpowiadający mu adres HTTPS. Unikaj łańcuchów przekierowań: zwiększają opóźnienia i liczbę punktów awarii. Publikuj kanoniczne adresy HTTPS w linkach wewnętrznych, znacznikach canonical, mapach witryny, danych strukturalnych, metatagach społecznościowych, e-mailach i bezwzględnych linkach generowanych przez aplikację. Przetestuj stronę główną, podstronę położoną głębiej w strukturze, adres URL z parametrami zapytania, trasy błędów i warianty nazw hostów. Gdy TLS kończy się na proxy, skonfiguruj zaufane nagłówki przekazywanego protokołu, aby aplikacja nie wpadła w pętlę między HTTP a HTTPS.
HTTP może być dostępny tylko dla przekierowania lub zakończenia wyzwania certyfikatu, a nie do obsługi oddzielnej publicznej strony.
Znajdź i napraw mieszane treści u źródła
Mieszane treści to strona HTTPS żądająca zasobu przez HTTP lub inny niebezpieczny protokół. Przeglądarki mogą podnosić niektóre media do HTTPS, ale blokują wiele ryzykownych żądań, w tym skrypty, arkusze stylów, ramki, wywołania fetch i czcionki. Zastąp każde odwołanie przetestowanym adresem HTTPS, względnym URL-em dla własnych treści lub zatwierdzoną alternatywą. Prześledź reprezentatywne szablony i obserwuj narzędzia deweloperskie podczas wykonywania kluczowych ścieżek. Sprawdź CSS, JavaScript, bloki CMS, manifesty zasobów, wpisy w menedżerze tagów, pliki do pobrania i osadzenia dostawców. Strona zabezpieczona nie powinna oferować pobierania przez HTTP.
Automatyczne podnoszenie przez przeglądarkę może pozostawić niedostępną lub nieobsługiwaną zależność zewnętrzną; popraw przechowywany URL.
Zautomatyzuj odnawianie i przećwicz odzyskiwanie certyfikatu
Traktuj odnowienie jak zautomatyzowane wdrożenie, a nie przypomnienie w kalendarzu. Musi ono odnowić, wdrożyć na wszystkich warstwach serwujących i bezpiecznie przeładować usługę. Testuj ten sam sposób walidacji przed wygaśnięciem produkcyjnym. Let’s Encrypt, na przykład, zaleca odnawianie swoich 90-dniowych certyfikatów co 60 dni; stosuj się do cyklu życia wydanego przez twojego wystawcę i platformę. Zachowaj w inwentarzu nazwy certyfikatów, konto wystawcy, metodę wyzwania, automatyzację, lokalizację klucza, cele wdrożenia i kontakty awaryjne. Po wdrożeniu zweryfikuj daty z publicznego punktu końcowego.
W przypadku nieudanego odnowienia sprawdź DNS, trasowanie wyzwania, uprawnienia, dostęp do wystawcy, limity liczby żądań oraz wdrożenie między CDN a serwerem źródłowym.
Używaj HSTS dopiero gdy środowisko HTTPS jest gotowe
HTTP Strict Transport Security, czyli HSTS, to nagłówek odpowiedzi HTTPS, który informuje przeglądarki, by przy kolejnych odwiedzinach używały HTTPS dla danego hosta. Przeglądarki nie oferują wtedy odwiedzającym możliwości obejścia błędów certyfikatu. Wysyłaj ten nagłówek tylko przez HTTPS i zachowaj przekierowanie HTTP, ponieważ HSTS jest zapamiętywany po otrzymaniu bezpiecznej odpowiedzi, chyba że domena znajduje się na liście wstępnego ładowania. Zacznij od ograniczonej wartości max-age i wydłużaj ją po potwierdzeniu poprawnego odnawiania certyfikatów i działania wymaganych tras. Nie dodawaj includeSubDomains, dopóki każda obecna i przyszła subdomena nie będzie mogła obsłużyć ważnego HTTPS. Preload nie jest częścią specyfikacji HSTS i wymaga osobnej oceny długoterminowych zobowiązań.
max-age=0 działa tylko po tym, jak przeglądarka dotrze do ważnej odpowiedzi HTTPS; nie naprawi niedostępnego bezpiecznego hosta.
Wdrażaj, testuj i cofnij bez osłabiania transportu
Zachowaj znany-dobry (known-good) certyfikat, konfigurację edge i przekierowań przed zmianą. Zdefiniuj, kto zatwierdza cofnięcie, stosuj etapowanie tam, gdzie to możliwe, i zmieniaj jedną klasę kontroli naraz. Natychmiast sprawdź publiczne punkty końcowe z więcej niż jednej sieci, podążaj za przekierowaniami, sprawdź certyfikat i wykonaj ważne działania odwiedzających. Testuj przeglądarki i grupy klientów istotne dla twojej publiczności. Dla płatności lub procesów regulowanych poproś dostawcę płatności i kwalifikowanego specjalistę ds. bezpieczeństwa o przegląd wymagań. Jeśli zmiana zepsuje HTTPS, przywróć zwalidowaną bezpieczną konfigurację; nie udostępniaj stron klienta przez HTTP jako obejścia.
Zarejestruj nazwę hosta, czas, klienta, błąd, zmianę i wynik, żeby następne odnowienie lub migracja były łatwiejsze do zdiagnozowania.