Co dokładnie sprawdza to narzędzie
Nasz serwer nawiązuje z podanym adresem połączenie szyfrowane, dokładnie tak jak zrobiłaby to przeglądarka, i odczytuje certyfikat, który serwer przedstawia w trakcie uzgadniania. Wszystkie dane pochodzą z tego jednego połączenia. Nie ma tu żadnej bazy ani zewnętrznego rejestru, więc wynik nie może być nieaktualny. Sam certyfikat wiąże nazwę domeny z kluczem publicznym serwera i to ten związek weryfikuje przeglądarka, zanim pokaże stronę.
Połączenie nawiązujemy dwa razy, za pierwszym razem bez weryfikacji, żeby pokazać nawet certyfikat wadliwy, bo inaczej przy wygasłym certyfikacie nie dowiedziałbyś się nawet, kiedy stracił ważność. Drugi raz łączymy się z pełną weryfikacją, dokładnie taką, jaką stosuje przeglądarka. Różnica między tymi dwoma próbami odpowiada na pytanie, czy odwiedzający zobaczy ostrzeżenie.
Dni do wygaśnięcia i skąd wzięły się progi
Próg trzydziestu dni ma źródło w harmonogramie automatów. Najpopularniejsze programy do automatycznego odnawiania certyfikatów zaczynają próby właśnie trzydzieści dni przed końcem ważności, przy typowym okresie ważności wynoszącym 90 dni. Certyfikat z mniejszym zapasem sygnalizuje więc, że automat już próbował i mu się nie udało, najczęściej z powodu zmienionej konfiguracji serwera, przeniesienia witryny, zablokowanego portu 80 albo wygaśnięcia uprawnień do zapisu w katalogu weryfikacyjnym.
Siedem dni to granica, po której przestaje wystarczać reakcja „przy najbliższej okazji”. Odnowienie wymaga zwykle dostępu do serwera i przeładowania usługi, a przy zepsutym automacie dochodzi jeszcze szukanie przyczyny. Po przekroczeniu daty ważności przeglądarki pokazują pełnoekranowe ostrzeżenie, którego nie da się pominąć jednym kliknięciem, a część aplikacji mobilnych i integracji po prostu przestaje działać bez żadnego komunikatu.
Sprawdzanie certyfikatów SSL raz na miesiąc wystarcza przy działającym automacie, a przy ręcznym odnawianiu ustaw przypomnienie w kalendarzu na trzydzieści dni przed datą z wiersza „Ważny do”.
Łańcuch certyfikatów i najczęstszy błąd konfiguracji
Przeglądarka ufa certyfikatowi Twojego serwera nie dlatego, że go zna, tylko dlatego, że potrafi zbudować ścieżkę od niego do jednego z certyfikatów głównych, które ma wbudowane. Ta ścieżka, nazywana ścieżką certyfikacji, prowadzi przez certyfikaty pośrednie i serwer musi wysłać je razem ze swoim. Certyfikatu głównego wysyłać nie ma po co, bo klient i tak ma go u siebie.
Najczęstszy błąd instalacji to wgranie samego certyfikatu serwera, bez pośrednich. Na komputerze zwykle nic się nie stanie, bo przeglądarki potrafią dobrać brakujący element z własnej pamięci albo pobrać go z adresu podanego w certyfikacie. Problem wychodzi gdzie indziej, w aplikacji mobilnej albo w bibliotece do wysyłania żądań. Objaw jest wtedy mylący: „u mnie działa, a integracja zgłasza błąd certyfikatu”. Dlatego pokazujemy pełny łańcuch i ostrzegamy, gdy ma tylko jeden element.
Zgodność nazwy strony internetowej i certyfikaty wildcard
Certyfikat obowiązuje dla konkretnych nazw wypisanych w rozszerzeniu nazw alternatywnych, w skrócie SAN. Pole „nazwa pospolita” (CN) ma dziś znaczenie wyłącznie historyczne, a rozstrzyga lista. Jeśli wpisanej nazwy na niej nie ma, przeglądarka odmówi, choćby certyfikat był świeży i wystawiony przez zaufane centrum.
Gwiazdka obejmuje dokładnie jeden poziom. Zapis *.example.com pasuje do sklep.example.com, ale już nie do a.b.example.com ani do samego example.com. Dlatego certyfikaty SSL typu wildcard wystawia się zwykle razem z osobnym wpisem dla domeny głównej. Brak tego wpisu to druga najczęstsza przyczyna błędu nazwy. Pierwszą jest zwykłe pominięcie wersji z „www” albo bez niego.
Wersja protokołu i szyfry, którymi serwer szyfruje ruch
Sama nazwa SSL, czyli Secure Sockets Layer, pochodzi od protokołu zastąpionego przez TLS już w 1999 roku i formalnie wycofanego w 2015. Ruch szyfruje dziś Transport Layer Security, a określenie „certyfikat SSL” zostało w powszechnym użyciu jako nazwa zwyczajowa i tak też podpisujemy wynik. Wersja protokołu w raporcie mówi, jak stary jest sposób szyfrowania połączenia. Standardem jest TLS 1.3, w pełni akceptowalny pozostaje TLS 1.2. Wersje 1.0 i 1.1 zostały wycofane w 2020 roku i przeglądarki odmawiają ich użycia, więc serwer, który nie potrafi nic nowszego, jest praktycznie nieosiągalny.
Algorytm podpisu certyfikatu to osobna sprawa. Podpisy oparte na SHA-1 i MD5 są uznane za złamane i odrzucane od lat. Jeśli jeszcze gdzieś się pojawiają, to na urządzeniach z własnym, nieodnawianym certyfikatem. Dzisiejszy standard to SHA-256, coraz częściej z kluczem na krzywych eliptycznych, który przy tym samym poziomie bezpieczeństwa jest zauważalnie szybszy od klasycznego RSA.
Poziomy weryfikacji, czyli co wystawca sprawdził przed wydaniem certyfikatu
Wystawca widoczny w raporcie mówi, kto poręczył za certyfikat, ale nie mówi, jak dokładnie sprawdzał wnioskodawcę. Poziom najniższy i najczęstszy to DV, od Domain Validation. Wystawca potwierdza wtedy wyłącznie kontrolę nad domeną, zwykle przez plik umieszczony na serwerze albo wpis w DNS, i cała procedura trwa kilka minut. Wyżej stoją OV, czyli Organization Validation, i EV, czyli Extended Validation. Tam dochodzi weryfikacja podmiotu w rejestrach, a dane firmy trafiają do pola podmiotu w certyfikacie.
Praktyczna różnica jest jednak mniejsza, niż sugerują opisy, bo wszystkie trzy poziomy szyfrują połączenie identycznie, tym samym protokołem i tym samym zestawem szyfrów, a zielony pasek z nazwą firmy, który kiedyś wyróżniał EV w pasku adresu, zniknął z przeglądarek około 2019 roku. W naszym raporcie poziom weryfikacji rozpoznasz po tabeli łańcucha. Jeśli w wierszu podmiotu widnieje tylko nazwa domeny, masz do czynienia z DV. Nazwa firmy razem z krajem oznacza OV albo EV. Certyfikat odpowiada zresztą za jeden element bezpieczeństwa strony internetowej, za szyfrowanie transportu i potwierdzenie tożsamości serwera. O jakości samej aplikacji nie mówi nic.