SSL: ważność certyfikatu

Ważność certyfikatu SSL to parametr monitoringu stron internetowych, który sprawdza, czy certyfikat przedstawiany przez serwer w uzgadnianiu TLS przejdzie weryfikację klienta: czy nie wygasł, czy jest wystawiony dla odwiedzanej nazwy domeny i czy da się z niego zbudować ścieżkę zaufania do urzędu certyfikacji. Wynikiem jest certyfikat poprawny, certyfikat nieważny albo brak wyniku, gdy uzgadnianie się nie odbyło. Certyfikat X.509 wiąże tożsamość z kluczem publicznym, a jego okres ważności to czas od daty notBefore do notAfter włącznie ^[1].

Jak działa

W TLS 1.3 klient wysyła ClientHello, zwykle z rozszerzeniem server_name wskazującym nazwę serwera, a serwer odpowiada komunikatami ServerHello, Certificate, CertificateVerify i Finished ^[3]. CertificateVerify to podpis całego uzgadniania kluczem prywatnym odpowiadającym kluczowi publicznemu z certyfikatu ^[3]. Certyfikat serwera musi stać na pierwszym miejscu listy, a każdy następny powinien poświadczać poprzedni ^[3]. Gdy weryfikacja zawiedzie, klient może zakończyć połączenie alertem, np. certificate_expired dla wygasłego certyfikatu albo unknown_ca dla nieznanego urzędu ^[3].

RYS. 1.1Uzgadnianie TLS 1.3 z weryfikacją certyfikatu

Weryfikacja ścieżki według RFC 5280 przechodzi przez kolejne certyfikaty od kotwicy zaufania: sprawdza podpis kluczem wystawcy, to, czy okres ważności obejmuje bieżący czas, status unieważnienia i zgodność nazwy wystawcy z podmiotem certyfikatu nadrzędnego ^[1]. Osobnym krokiem jest dopasowanie nazwy: klient porównuje nazwę z adresu z nazwami DNS zapisanymi w rozszerzeniu subjectAltName ^[2]. Porównanie odbywa się etykieta po etykiecie, bez rozróżniania wielkości liter ^[2]. Brak dopasowania powinien przerwać połączenie błędem złego certyfikatu ^[2].

RYS. 1.2Kroki walidacji certyfikatu

Standardy i specyfikacje

• RFC 5280 definiuje certyfikat X.509, okres ważności, algorytm walidacji ścieżki i rozszerzenie Authority Information Access, którego metoda caIssuers wskazuje, skąd pobrać certyfikat wystawcy i może pomóc zbudować ścieżkę ^[1]. Certyfikat samopodpisany to taki, w którym wystawca i podmiot są tą samą jednostką, a podpis weryfikuje klucz z tego samego certyfikatu ^[1].
• RFC 9525 zastąpił RFC 6125. Pole Common Name nie może już służyć do identyfikacji usługi, bo jest tekstem bez typu ^[2]. Symbol wieloznaczny może stanowić wyłącznie całą skrajnie lewą etykietę i pasuje tylko do jednej etykiety ^[2].
• Baseline Requirements CA/Browser Forum (wersja 2.3.0) skracają maksymalny okres ważności certyfikatów publicznych: 398 dni dla wystawionych przed 15 marca 2026, 200 dni od tej daty, 100 dni od 15 marca 2027 i 47 dni od 15 marca 2029 ^[4].
• RFC 8555 (ACME) automatyzuje weryfikację kontroli nad domeną i wystawianie certyfikatów; klient ACME okresowo pobiera od urzędu nowe certyfikaty ^[5].

Zagrożenia i skutki

Wygaśnięcie. Chromium zgłasza wtedy błąd CERT_DATE_INVALID (kod -201): certyfikat według zegara klienta jeszcze nie obowiązuje albo wygasł ^[8]. Przyczyną może być źle skonfigurowany serwer, ale też podstawiony stary certyfikat albo błędny zegar klienta ^[8]. Let's Encrypt wystawia certyfikaty na 90 dni, żeby ograniczyć szkody po kradzieży klucza i wymusić automatyzację; zalecał odnawianie co 60 dni ^[6]. Zgodnie z wymogami CA/Browser Forum ten okres skróci się do 45 dni do 2028 roku, a stały 60-dniowy cykl odnowienia przestanie wystarczać ^[7].

Zła nazwa. Błąd CERT_COMMON_NAME_INVALID (kod -200) oznacza, że certyfikat nie pasuje do nazwy hosta, np. przez atak z przekierowaniem ruchu albo serwer podający niewłaściwy certyfikat ^[8]. Z reguł RFC 9525 wynika, że example.com i www.example.com to dwie różne nazwy, a wieloznaczne *.example.com nie obejmuje samej domeny bez prefiksu ^[2].

Nieznany wystawca. CERT_AUTHORITY_INVALID (kod -202) oznacza podpis urzędu, któremu klient nie ufa; jedną z przyczyn jest certyfikat samopodpisany, który nie chroni przed aktywnym atakującym ^[8].

Niekompletny łańcuch. RFC 8446 zakłada, że łańcuchy bywają niekompletne, a implementacje mogą uzupełnić brakujące certyfikaty ^[3]. Robią to różnie. Firefox nie pobiera ich przez AIA, lecz ma wstępnie załadowane certyfikaty pośrednie z bazy CCADB, m.in. dlatego, że pobieranie ujawniałoby urzędowi historię przeglądania ^[9]. W 2016 roku deweloperzy Chromium odnotowali, że Android nie pobiera certyfikatów pośrednich, a znaczna część błędów certyfikatów wynika z serwerów pomijających te certyfikaty ^[10]. Ta sama strona może więc działać w jednej przeglądarce i dawać błąd w innej albo w kliencie spoza przeglądarki.

Przykłady

Sytuacja	Co widzi klient	Typowa przyczyna
Certyfikat wygasły	CERT_DATE_INVALID, alert certificate_expired [8] [3]	minęła data notAfter [1]
Certyfikat na inną nazwę	CERT_COMMON_NAME_INVALID [8]	serwer podaje nie ten certyfikat [8]
Działa bez www, błąd z www	brak dopasowania nazwy [2]	certyfikat obejmuje tylko jedną formę adresu [2]
Certyfikat samopodpisany	CERT_AUTHORITY_INVALID, alert unknown_ca [8] [3]	wystawca i podmiot to ta sama jednostka [1]
Brak certyfikatu pośredniego	błąd zależny od klienta [9] [10]	serwer wysyła sam certyfikat końcowy [3]
Certyfikat tylko z Common Name	brak nazwy w subjectAltName [2]	nazwa tylko w polu Common Name [2]