Jak sprawdzić, czy strona internetowa ma ważny certyfikat SSL

Potwierdź dokładnego hosta, którego chcesz zweryfikować

Zacznij od dokładnego adresu, a nie od nazwy marki w twojej głowie. Certyfikat dla www.example.com nie jest tym samym, co certyfikat dla example.com, a subdomena taka jak shop.example.com może mieć swój własny certyfikat, swojego własnego wystawcę i swoje własne problemy.

To wydaje się oczywiste, ale to tam wiele kontroli się myli. Odwiedzający może trafić na przekierowanie, alias marketingowy lub subdomenę kraju, a certyfikat musi pasować tylko do hosta, który przeglądarka faktycznie widzi.

Dokładnie wpisz pełny adres URL. Jeśli strona używa zarówno www, jak i non-www, przetestuj oba. Jeśli sprawdzasz obszar logowania lub hosta API, zweryfikuj również tę dokładną nazwę hosta, ponieważ jeden host może być w porządku, podczas gdy inny może zawieść.

To ma jeszcze większe znaczenie na stronie korporacyjnej z wieloma punktami wejścia, gdzie strona główna, obszar wsparcia i domena aplikacji mogą zachowywać się inaczej. Jeden pominięty subdomen może stworzyć fałszywe poczucie bezpieczeństwa.

Szybka uwaga: wyglądająca na bezpieczną kłódka na jednej stronie nie dowodzi, że cała rodzina domen jest zabezpieczona. Dowodzi tylko, że jedna odpowiedź na jednym hoście przedstawiła jakiś certyfikat.

Sprawdź łańcuch certyfikatów, a nie tylko kłódkę

Kłódka to tylko pierwszy wskazówka. Przeglądarka może pokazywać HTTPS, podczas gdy łańcuch certyfikatów jest niekompletny, źle uporządkowany lub oparty na wystawcy, któremu przeglądarka nie ufa.

Otwórz szczegóły certyfikatu w swojej przeglądarce i sprawdź pełny łańcuch: certyfikat witryny, wszelkie certyfikaty pośrednie i ścieżkę zaufania głównego. Jeśli brakuje jednego certyfikatu pośredniego, niektóre przeglądarki mogą nadal odzyskać połączenie, ale inne będą narzekać, a niektórzy klienci odrzucą połączenie całkowicie.

Dlatego pytanie, jak sprawdzić, czy strona internetowa ma ważny certyfikat SSL, nie jest pytaniem na jedno kliknięcie. Musisz zobaczyć, co serwer wysyła, a nie tylko to, co sugeruje ikona kłódki.

W praktyce niekompletny łańcuch często pojawia się po odnowieniu lub migracji serwera. Sam certyfikat może być aktualny, ale łańcuch wysyłany przez serwer jest błędny, więc użytkownicy i tak otrzymują ostrzeżenia.

Użyj szczegółów certyfikatu przeglądarki, narzędzia do sprawdzania SSL lub narzędzia wiersza poleceń, jeśli masz dostęp. Strona, która działa w jednej przeglądarce, może nadal nie działać w innej, jeśli serwer pomija certyfikat pośredni.

Przykład z rzeczywistego świata: strona za CDN może prezentować ważny certyfikat liścia na krawędzi, ale uszkodzony łańcuch na starym ścieżce źródłowej. Odwiedzający widzi problem tylko na mniej powszechnej trasie.

Sprawdź, czy certyfikat pasuje do nazwy hosta

Certyfikat musi nazywać hosta, który przeglądarka odwiedza. Nowoczesne certyfikaty używają pola SAN, a ta lista ma większe znaczenie niż stare pole CN, chociaż ludzie wciąż najpierw zerkają na CN.

Sprawdź, czy wpisy SAN zawierają dokładną domenę i subdomenę, które testowałeś. Jeśli certyfikat wymienia example.com i www.example.com, to może być w porządku dla obu. Jeśli wymienia tylko example.com, to www.example.com może nadal nie działać.

Nie zakładaj, że znaki wieloznaczne rozwiązują wszystko. Znak wieloznaczny, taki jak *.example.com, zazwyczaj obejmuje jeden poziom głębokości, więc shop.example.com może być objęty, podczas gdy api.shop.example.com nie jest.

Aliasy to powszechna pułapka. Zespół marketingowy może promować go.example.com, ale certyfikat obejmuje tylko example.com i www.example.com. Strona się ładuje, kłódka pojawia się na chwilę, a potem przeglądarka zgłasza błąd nazwy.

Oto przydatny nawyk: dopasuj to, co użytkownicy wpisują, co przekierowuje na co i jakie są rzeczywiste nazwy certyfikatów. Trzy ciągi. Jedno sprawdzenie.

Jeśli zarządzasz witryną, która polega na kilku domenach wejściowych, to dobre miejsce, aby połączyć przegląd certyfikatu z pracą nad bezpieczeństwem witryny. Niedopasowanie certyfikatu to nie tylko irytacja w przeglądarce; może to przerwać procesy logowania, procesy płatności i wszystko, co jest związane z zaufaniem.

Zweryfikuj datę wygaśnięcia i status odnowienia

Każdy certyfikat ma datę rozpoczęcia i datę zakończenia. Sprawdź obie. Jeśli certyfikat już wygasł, ostrzeżenie przeglądarki nie jest tajemnicą, a jeśli wygasa jutro, to nadal jest problemem dla użytkowników, którzy otwierają witrynę po północy.

Spójrz na okno ważności w przeglądarce certyfikatów. Niektóre narzędzia pokazują „nie wcześniej niż” i „nie później niż”. Te dwie linie informują, czy certyfikat jest teraz aktywny i czy odnowienie jest już przeterminowane.

Odnowienie nie zawsze jest natychmiastowe. Witryna może być w trakcie wdrażania, z starym certyfikatem nadal widocznym na jednym serwerze i nowym na innym. Może to prowadzić do niespójnych wyników podczas okna przejściowego.

Krótki okres ważności nie jest sam w sobie wadą, ale podnosi stawkę. Jeśli zadanie automatycznego odnawiania zawiedzie raz, strona może przejść z dobrego stanu do zablokowanego z bardzo małym ostrzeżeniem.

Pamiętaj o dacie, gdy sprawdzasz podejrzany certyfikat. Certyfikat, który wygasa za 2 dni, zasługuje na szybszą uwagę niż taki, który ma jeszcze miesiące ważności, ponieważ rozwiązanie może być po prostu odnawianiem, które jeszcze się nie rozpropagowało.

Dla zespołów, które już korzystają z platformy analityki i monitorowania stron internetowych, połączenie sprawdzania certyfikatów z powiadomieniami o dostępności pomaga wychwycić awarię odnawiania, zanim zrobią to użytkownicy. Tutaj liczy się czas, a nie teoria.

Zwróć uwagę na problemy z zaufaniem ze strony organu wydającego

Certyfikat może być ważny na papierze, a mimo to wywoływać ostrzeżenie o zaufaniu. Zwykle wskazuje to na wydającą go jednostkę certyfikującą, łańcuch zaufania lub urządzenie, które nie ma odpowiedniego certyfikatu głównego.

Otwórz informacje o wystawcy i potwierdź, że CA jest rozpoznawane przez nowoczesne przeglądarki i systemy operacyjne. Jeśli wystawca wydaje się nieznany lub certyfikat był samopodpisany, przeglądarka może odmówić zaufania, nawet gdy HTTPS pojawia się w pasku adresu.

Certyfikaty samopodpisane są powszechne w narzędziach wewnętrznych, serwerach testowych i prywatnych stronach administracyjnych. Są również częstym źródłem zamieszania, gdy ktoś kopiuje to samo ustawienie na stronę publiczną.

Ostrzeżenia przeglądarki warto czytać linia po linii. Jedno ostrzeżenie może wspominać o nieufnym wystawcy. Inne może wspominać o problemie z łańcuchem. Trzecie może mówić, że certyfikat nie jest przeznaczony dla hosta.

Te wiadomości są różne. Traktuj je inaczej.

Jeśli sprawdzasz publiczną stronę, która powinna być zaufana domyślnie, ostrzeżenie przeglądarki oznacza, że ścieżka zaufania jest gdzieś przerwana. Może to się zdarzyć po źle przeprowadzonej migracji, złej konfiguracji proxy lub certyfikacie zainstalowanym z niewłaściwym pakietem pośrednim.

Zaufana jednostka nie oznacza oczywiście „bezpiecznej treści”. Oznacza to tylko, że przeglądarka akceptuje ścieżkę certyfikatu jako legitymacyjną. To węższe twierdzenie i to jedyne twierdzenie, jakie może mieć certyfikat.

Sprawdź, czy na stronie występuje mieszana zawartość

Ważny certyfikat SSL nie ratuje strony, która nadal ładuje niebezpieczne zasoby. Mieszana zawartość występuje, gdy główna strona używa HTTPS, ale obrazy, skrypty, czcionki lub ramki pochodzą z adresów URL HTTP.

Otwórz narzędzia dewelopera i odśwież stronę. Szukaj ostrzeżeń o zablokowanych lub zaktualizowanych zasobach. Strona może nadal ładować się wizualnie, podczas gdy skrypt cicho zawodzi, ponieważ przeglądarka zablokowała niebezpieczny plik.

To jest praktyczny problem bezpieczeństwa, a nie kosmetyczny. Jeden niebezpieczny skrypt może osłabić ochronę, którą certyfikat ma zapewnić.

Powszechnymi winowajcami są stare adresy URL obrazów, widgety zewnętrzne, tagi analityczne i osadzone odtwarzacze wideo. Jeden stary link HTTP w szablonie może zanieczyścić dziesiątki stron.

Jeśli prowadzisz portal treści dotyczący inwestycji, ta kontrola ma jeszcze większe znaczenie, ponieważ uszkodzony skrypt wykresu lub widget z notowaniami może sprawić, że strona będzie wyglądać na wiarygodną, podczas gdy w rzeczywistości cicho zawodzi. Ikona kłódki nie opowie ci tej historii.

Mieszana zawartość również pomaga wyjaśnić, dlaczego użytkownicy czasami zgłaszają „strona jest bezpieczna na moim laptopie, ale nie na moim telefonie”. Certyfikat może być w porządku; zasoby strony nie są.

Porównaj zachowanie na komputerze stacjonarnym i urządzeniach mobilnych

Wykonaj tę samą kontrolę w co najmniej 2 środowiskach: w jednej przeglądarce na komputerze stacjonarnym i w jednej przeglądarce mobilnej lub urządzeniu. Certyfikat może przejść na nowoczesnym komputerze stacjonarnym i nie przejść na starszym telefonie, szczególnie jeśli magazyn zaufania jest przestarzały.

Ta różnica ma znaczenie. Łańcuch certyfikatów, który wygląda akceptowalnie w Chrome na laptopie, może nadal wywołać ostrzeżenie w Safari na starszym iPhonie lub w przeglądarce z przestarzałymi certyfikatami głównymi.

Sprawdź główny host i jedną subdomenę. Jeśli strona przekierowuje z www na non-www, powtórz test po przekierowaniu. Niepowodzenie na przekierowanym hoście to nadal niepowodzenie.

Kontrole urządzeń ujawniają również dziwności związane z ciasteczkami i sesjami. Czasami ostrzeżenie przeglądarki pojawia się dopiero po zalogowaniu, ponieważ inny host jest wywoływany, gdy użytkownik osiąga bezpieczny obszar.

Prostota jest tutaj najlepsza. Otwórz stronę, sprawdź zamek, potwierdź nazwę hosta i porównaj szczegóły certyfikatu na obu urządzeniach. Pięć minut może zaoszczędzić zgłoszenie do wsparcia później.

Zespoły, które już polegają na wsparciu strony internetowej po uruchomieniu, zazwyczaj dobrze znają ten wzór: raport przeglądarki od klienta rzadko jest taki sam jak wynik z maszyny dewelopera.

Wiedz, kiedy eskalować sprawę do właściciela strony lub dostawcy hostingu

Zgłoś sprawę, gdy certyfikat jest wygasły, nazwa hosta się nie zgadza, łańcuch jest przerwany lub przeglądarka wyświetla ostrzeżenie o zaufaniu, którego nie możesz wyjaśnić ustawieniami lokalnego urządzenia. To nie są odkrycia „może później”.

Gdy zgłaszasz problem, dołącz dokładny host, znacznik czasu, nazwę przeglądarki, widoczną wiadomość o błędzie oraz zrzut ekranu szczegółów certyfikatu. Jeśli to możliwe, dołącz wpisy SAN, nazwę wystawcy i datę wygaśnięcia.

Zachowaj raport konkretny. Powiedz „shop.example.com nie działa na iPhone Safari z niezgodnością nazwy hosta” zamiast „SSL jest zepsuty”. Pierwsze zdanie daje komuś ścieżkę do naprawy.

Jeśli zarządzasz stroną dla klienta, powiedz im, czy problem dotyczy jednego hosta, czy kilku. Ta różnica może zdecydować, czy naprawa należy do DNS, load balancera, serwera WWW, czy dostawcy certyfikatów.

Dostawcy hostingu często potrzebują dokładnych dowodów, aby działać szybko. Niejasna skarga może krążyć między zespołami przez dzień. Precyzyjna może być dopasowana do odnowienia, brakującego pośredniego lub złego wdrożenia w ciągu kilku minut.

Dla zespołów pracujących nad wewnętrzną platformą lub publicznym produktem, najczystsze przekazanie to takie, które zawiera host, typ niepowodzenia i ścieżkę przeglądarki. To wystarczy, aby oddzielić problem certyfikatu od problemu strony, co oszczędza wszystkim zgadywania.

Ostatnia kontrola pomaga w upartym przypadku: porównaj certyfikat na stronie na żywo z tym na serwerze źródłowym lub hoście stagingowym, jeśli masz dostęp. Niezgodne wdrożenie może pozostawić jedno środowisko naprawione, a drugie nadal nie działające, a przeglądarka interesuje się tylko hostem, do którego dotarła.