Weryfikacja certyfikatu w TLS

Bez weryfikacji certyfikatu można byłoby ustanowić połączenie TLS z atakującym podszywającym się pod serwer (atak man-in-the-middle). Weryfikacja certyfikatu gwarantuje, że komunikują się Państwo z prawdziwym serwerem, który posiada klucz prywatny.

Kluczowe pola to: Subject (właściciel certyfikatu), SubjectAltName (nazwy DNS/adresy IP), Issuer (CA podpisujący certyfikat), Validity (notBefore/notAfter), Public Key, Signature. Przeglądarka sprawdza wszystkie te pola.

Certyfikat serwera → certyfikat pośredniego CA → certyfikat głównego CA. Główny CA jest podpisany własnym kluczem i wstępnie zainstalowany w magazynie zaufania systemu operacyjnego lub przeglądarki. Serwer wysyła swój certyfikat oraz certyfikaty pośrednie w komunikacie Certificate uzgadniania TLS.

Każdy certyfikat jest podpisany przez znajdującego się wyżej w hierarchii wystawcę. Klient weryfikuje: signature(cert_n) za pomocą public_key(cert_{n+1}). Jeśli dowolny podpis jest nieprawidłowy, łańcuch zostaje odrzucony. Główny certyfikat jest zaufany dzięki wstępnej instalacji, a nie dzięki podpisowi.

Klient sprawdza, czy nazwa hosta serwera odpowiada polu Subject lub SubjectAltName certyfikatu (wpisom DNS). Wieloznaczniki (*.example.com) pasują do jednego poziomu nazwy. Od 2000 roku SAN ma pierwszeństwo przed CN przy dopasowywaniu nazwy hosta.

Klient sprawdza notBefore ≤ now ≤ notAfter dla każdego certyfikatu w łańcuchu. Certyfikaty, których ważność wygasła, są odrzucane nawet wtedy, gdy ich podpisy są prawidłowe. Okresy ważności certyfikatów zostały skrócone: przeglądarki ograniczają je obecnie do około 398 dni.

CA publikuje Certificate Revocation List (CRL) — podpisaną listę numerów seryjnych unieważnionych certyfikatów. Klient pobiera adres URL listy CRL (z rozszerzenia CRL Distribution Points certyfikatu) i sprawdza, czy znajduje się na niej numer seryjny.

Online Certificate Status Protocol (OCSP) pozwala klientom zapytać responder OCSP urzędu CA o status pojedynczego certyfikatu. Jest szybszy niż CRL, ale zwiększa opóźnienie. OCSP Stapling polega na tym, że serwer dołącza podpisaną odpowiedź OCSP do uzgadniania TLS.

CT (RFC 6962) wymaga od CA rejestrowania wszystkich wydanych certyfikatów w publicznych dziennikach, do których można tylko dopisywać wpisy. Przeglądarki sprawdzają obecność Signed Certificate Timestamps (SCT) w certyfikacie lub rozszerzeniu TLS. Zapobiega to niezauważonemu nieprawidłowemu wydawaniu certyfikatów.

HTTP Public Key Pinning (HPKP, przestarzałe) oraz przypinanie certyfikatów w aplikacjach mobilnych wiążą konkretny klucz publiczny lub skrót certyfikatu. Jeśli serwer przedstawi inny certyfikat, połączenie zostaje odrzucone nawet wtedy, gdy certyfikat jest ważny — zapobiega to atakom wynikającym z przejęcia CA.

ERR_CERT_AUTHORITY_INVALID: główny certyfikat nie jest zaufany. ERR_CERT_DATE_INVALID: certyfikat wygasł. ERR_CERT_COMMON_NAME_INVALID: niezgodność nazwy hosta. NET::ERR_CERT_REVOKED: OCSP/CRL wskazuje, że certyfikat został unieważniony. Każdy z tych błędów odpowiada niepowodzeniu konkretnego etapu weryfikacji.

Co zapewnia OCSP Stapling?

Weryfikacja certyfikatu w TLS obejmuje weryfikację łańcucha, sprawdzanie podpisów, dopasowanie nazwy, sprawdzanie okresów ważności oraz unieważnienia. Następnie: historyczne ataki na TLS i sposoby ich ograniczania przez TLS 1.3.