Jak działa certyfikat SSL i przed czym naprawdę chroni TLS

Certyfikat SSL to poświadczenie, które wiąże klucz publiczny serwera z nazwą strony i pozwala przeglądarce sprawdzić, że rozmawia z właściwym hostem. Samo szyfrowanie i ochronę danych w drodze zapewnia protokół TLS. Certyfikat nie naprawia błędów aplikacji ani złych uprawnień - potwierdza tożsamość, nic więcej.

Nie znajdziesz tu cennika ani porównania dostawców. Zobaczysz, co dokładnie dzieje się między przeglądarką a serwerem, na przykładzie sklepu, który stracił weekend przez jeden wygasły plik - a potem sprawdzisz własny certyfikat dwiema komendami.

Certyfikat, SSL i TLS to trzy nazwy, ale nie jedna rzecz

SSL to utrwalona, potoczna nazwa całego mechanizmu - sam protokół SSL wyszedł z użycia lata temu. Współczesne połączenie HTTPS chroni jego następca, protokół TLS. Gdy dostawca sprzedaje ci „certyfikat SSL", kupujesz certyfikat, którego użyje TLS.

Certyfikat nie jest ani protokołem, ani szyfrowaniem. To dokument elektroniczny, który serwer przedstawia na początku połączenia: zawiera klucz publiczny, nazwy, dla których został wydany, dane wystawcy i okres ważności. Klucz prywatny zostaje na serwerze i nigdy nie jest częścią tego, co dostaje przeglądarka.

Szyfrowanie działa osobno. Po sprawdzeniu certyfikatu klient i serwer uzgadniają klucze sesji i dopiero nimi TLS chroni poufność oraz integralność przesyłanych danych. Certyfikat otwiera drzwi do tej wymiany, ale sam niczego dalej nie szyfruje.

Sklep, któremu wygasł certyfikat w sobotę

Weź mały sklep internetowy z częściami rowerowymi. To fikcyjny przykład złożony z typowych awarii wokół certyfikatów, nie opis konkretnej firmy. Stroną opiekuje się Paweł, który zna panel hostingu, ale serwerem zajmuje się dorywczo, między zamówieniami.

W sobotę rano klienci zaczęli dzwonić, że „strona jest niebezpieczna". Przeglądarka pokazywała ostrzeżenie o wygasłym certyfikacie. Paweł wszedł do panelu i zobaczył status „certyfikat aktywny" - automat odnowił plik dwa tygodnie wcześniej. Problem w tym, że serwer WWW nigdy nie wczytał nowego pliku i dalej podawał stary, po terminie. Panel mówił prawdę o dysku, przeglądarka mówiła prawdę o połączeniu - a liczy się tylko to drugie.

Miesiąc później sklep dostał drugi adres, panel.sklep-przyklad.pl, na tym samym certyfikacie wildcard. Wszystko działało do dnia, w którym Paweł dodał adres testowy panel.dev.sklep-przyklad.pl - i przeglądarka znów pokazała błąd. Wildcard *.sklep-przyklad.pl obejmuje jeden poziom nazw, więc panel tak, ale panel.dev już nie. Nikt wcześniej nie sprawdził, jakie nazwy certyfikat naprawdę obejmuje.

Trzecia sprawa wyszła po włączeniu CDN. Test z zewnątrz pokazywał świeży certyfikat i zieloną kłódkę, więc temat uznano za zamknięty. Tyle że ten certyfikat należał do CDN i opisywał odcinek od przeglądarki do jego serwerów brzegowych. Odcinek dalej, od CDN do serwera sklepu, był osobnym połączeniem ze starym certyfikatem, którego nikt już nie pilnował.

Żadna z tych awarii nie wynikła z braku certyfikatu. Wszystkie wynikły z tego, że nikt nie sprawdzał certyfikatu tam, gdzie widzi go klient, i nikt nie miał zapisanego obowiązku, żeby to robić. Do tych trzech historii wrócisz niżej - najpierw zobacz, co przeglądarka sprawdza za każdym razem, gdy otwierasz stronę.

Co dzieje się po wpisaniu adresu z HTTPS?

Przeglądarka nie uznaje strony za właściwą tylko dlatego, że serwer przesłał jakikolwiek certyfikat. Sprawdza poświadczenie względem nazwy z adresu i buduje ścieżkę zaufania do znanego sobie urzędu certyfikacji.

Połączenie przebiega w sześciu krokach:

1. Klient rozpoznaje adres serwera i rozpoczyna połączenie.
2. Podczas negocjacji TLS przekazuje nazwę hosta przez SNI - dzięki temu jeden adres IP może obsługiwać wiele stron z różnymi certyfikatami.
3. Serwer przedstawia certyfikat oraz certyfikaty pośrednie potrzebne do zbudowania łańcucha.
4. Klient sprawdza nazwę hosta, okres ważności, podpisy i ścieżkę do zaufanego urzędu.
5. Obie strony uzgadniają klucze sesji.
6. Rusza zaszyfrowana wymiana danych.

Każdy z tych kroków psuje się inaczej i daje inny komunikat w przeglądarce. Niezgodna nazwa wygląda inaczej niż wygasły certyfikat, a problem z negocjacją protokołu prowadzi do osobnej diagnostyki ERR_SSL_PROTOCOL_ERROR.

Co certyfikat potwierdza, a czego nie?

Kłódka przy adresie informuje o stanie połączenia z konkretnym hostem. Nie ocenia uczciwości właściciela strony, jakości kodu ani tego, co stanie się z twoimi danymi po zapisaniu ich w aplikacji. Strona wyłudzająca dane może mieć poprawny certyfikat - i coraz częściej ma, bo certyfikat DV dostaje każdy, kto kontroluje domenę.

Certyfikat nie zatrzyma błędu w aplikacji, złośliwego skryptu na prawidłowej domenie ani użytkownika z nadmiernymi uprawnieniami. Kontrola dostępu, rejestrowanie zdarzeń i aktualizacje to osobne obowiązki, których kłódka nie załatwia.

Czym różnią się DV, OV i EV?

Różnią się tym, co urząd certyfikacji sprawdza przed wydaniem - nie siłą szyfrowania. Przy DV urząd weryfikuje tylko, czy wnioskodawca kontroluje domenę. Przy OV dodatkowo potwierdza dane i adres organizacji, które trafiają do certyfikatu. EV podlega osobnej procedurze CA/Browser Forum EV Guidelines, obejmującej weryfikację tożsamości podmiotu i upoważnienia jego przedstawicieli.

Połączenie z certyfikatem DV jest zaszyfrowane dokładnie tak samo jak z EV. Płacisz za procedurę sprawdzenia tożsamości, nie za lepszą kryptografię.

Osobną decyzją jest zakres nazw. Wildcard *.example.com obejmuje jeden poziom: www.example.com i api.example.com tak, ale domeny bazowej example.com ani nazwy panel.dev.example.com już nie - dokładnie na tym wyłożył się Paweł ze sklepu. Certyfikat wielodomenowy wymienia za to konkretne nazwy w polu SAN. W obu wypadkach otwórz certyfikat i przeczytaj rzeczywistą listę nazw, zamiast zakładać, co obejmuje. Porównanie wariantów darmowych i płatnych opisujemy osobno - tu zostajesz przy mechanizmie.

Jak sprawdzić własny certyfikat?

Zacznij od przeglądarki. Kliknij kłódkę albo ikonę informacji o połączeniu i odczytaj cztery rzeczy:

1. nazwy hostów objęte certyfikatem,
2. wystawcę i łańcuch certyfikatów,
3. początek i koniec okresu ważności,
4. miejsce, w którym przeglądarka zgłasza błąd walidacji, jeśli go zgłasza.

Układ tego panelu zmienia się między wersjami przeglądarek, ale znaczenie pól nie - wynika z formatu certyfikatu X.509, nie z interfejsu.

Z terminala tę samą kontrolę wykonasz przez openssl s_client, z osobnymi opcjami dla SNI, weryfikacji nazwy i przerwania po błędzie:

openssl s_client \
  -connect HOST:443 \
  -servername HOST \
  -verify_hostname HOST \
  -verify_return_error \
  -brief </dev/null

Uruchom polecenie z komputera, z którego połączenie ma być sprawdzane, i zastąp HOST badaną nazwą we wszystkich trzech miejscach. -servername wysyła nazwę jako SNI, -verify_hostname porównuje ją z certyfikatem, a -verify_return_error przerywa połączenie po błędzie walidacji zamiast go przemilczeć. Wynik Verification: OK razem z Verified peername: HOST oznacza, że walidacja przeszła względem magazynu zaufanych certyfikatów twojego systemu.

Pola certyfikatu odczytasz drugą komendą:

openssl s_client -connect HOST:443 -servername HOST </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

Dostaniesz nazwę podmiotu, wystawcę, daty i pełną listę SAN pierwszego przesłanego certyfikatu. Ta komenda niczego nie weryfikuje - tylko pokazuje zawartość. Pełną interpretację wyników i dobór własnego magazynu zaufania znajdziesz w instrukcji sprawdzenia certyfikatu poleceniem OpenSSL.

Jak czytać wynik tych kontroli?

Najpierw nazwa. Host z adresu musi pasować do jednej z nazw SAN - nazwa organizacji ani wystawcy tego nie zastąpi. Gdy SAN nie obejmuje hosta, klient ma podstawę odrzucić połączenie i zrobi to.

Potem łańcuch. Certyfikat serwera bywa podpisany przez urząd pośredni, a dopiero ten przez urząd główny znany klientowi. Walidacja według RFC 5280 wymaga zbudowania pełnej ścieżki - jeśli serwer nie przesłał certyfikatu pośredniego, a klient nie ma go skąd wziąć, budowanie ścieżki kończy się błędem, choć sam certyfikat jest poprawny.

Okres ważności mówi tylko tyle, że poświadczenie mieści się w przedziale czasu. Nie mówi, że kolejne odnowienie się wykona ani że usługa wczyta nowy plik - to była pierwsza sobota Pawła. Dlatego sprawdzaj certyfikat widoczny z internetu, nie plik na dysku.

Na końcu ustal, kto ten certyfikat przedstawia. Jeśli ruch przechodzi przez CDN, wynik opisuje jego serwery brzegowe, a odcinek do twojego serwera aplikacji jest osobnym połączeniem z własnym certyfikatem - to była trzecia historia sklepu. Oba odcinki oceniaj oddzielnie, bo awaria i osoba odpowiedzialna mogą siedzieć w różnych systemach.

Co się psuje i gdzie szukać przyczyny?

To rozdzielenie oszczędza ci naprawiania serwera aplikacji, gdy użytkownik łączy się z certyfikatem na CDN - i odwrotnie: pomaga wykryć, że pierwszy odcinek działa, a niezabezpieczone połączenie zostało między proxy a aplikacją na serwerze.

Kto odpowiada za odnowienie?

Certyfikat ma opiekuna nawet wtedy, gdy dostawca odnawia go automatycznie. Automat może zgłosić błąd - ktoś musi ten alarm odebrać, sprawdzić certyfikat widoczny z internetu i potwierdzić, że usługa po zmianie działa. W sklepie Pawła automat zadziałał bez zarzutu; zawiodło to, że nikt nie miał w obowiązkach kroku „sprawdź, co serwer naprawdę podaje".

Bez przypisanej osoby powstaje prosta awaria organizacyjna: alarm poszedł, nikt go nie obsłużył. Dla klientów skutek jest taki sam jak przy leżącym serwerze - nie otworzą logowania, formularza ani koszyka. Instrukcję wydania i automatyzacji odnowienia opisujemy osobno; po każdej zmianie testuj usługę z zewnątrz, nie obecność pliku na dysku.

Pytania o certyfikat SSL i TLS

Czy certyfikat SSL jest potrzebny?

Jest, jeśli strona ma udostępniać HTTPS - a dziś to warunek zaufania przeglądarki do logowania, formularzy, paneli i API. Klient używa certyfikatu do sprawdzenia tożsamości serwera, zanim prześle jakiekolwiek dane. To wymaganie techniczne protokołu; ocena obowiązku prawnego konkretnej firmy to osobna sprawa i wymaga właściwego aktu prawnego, nie parametrów certyfikatu.

Czym różni się SSL od TLS?

SSL to nazwa starszych, wycofanych protokołów, która przetrwała jako potoczne określenie certyfikatu strony. TLS to protokół chroniący współczesne połączenia HTTPS. Kupując „certyfikat SSL", dostajesz certyfikat, którego serwer użyje w połączeniu TLS - różnica jest językowa, nie handlowa.

Co oznacza brak certyfikatu SSL na stronie?

Serwer nie zapewnia prawidłowo uwierzytelnionego HTTPS dla danej nazwy. Przyczyną bywa brak konfiguracji na porcie 443, brak certyfikatu dla tego hosta albo podawanie niewłaściwego poświadczenia. Brak certyfikatu i błędny certyfikat to różne sytuacje - w drugiej serwer coś przedstawia, ale klient nie może tego zaakceptować z powodu nazwy, terminu albo łańcucha.

Czy certyfikat SSL chroni stronę przed atakiem?

Chroni sam transport - dane w drodze między klientem a punktem zakończenia TLS są zaszyfrowane i zabezpieczone przed niezauważoną zmianą. Nie usuwa podatności aplikacji, nie ogranicza uprawnień użytkowników i nie chroni danych po odszyfrowaniu na końcu połączenia. Stronę wyłudzającą dane też stać na poprawny certyfikat, a co robić, gdy ktoś w firmie poda na takiej stronie hasło, opisujemy w procedurze reakcji na phishing.

Dlaczego przeglądarka pokazuje błąd, skoro panel mówi, że certyfikat jest aktywny?

Panel opisuje plik na dysku albo stan w systemie dostawcy, a przeglądarka - to, co serwer naprawdę przedstawił w połączeniu. Po odnowieniu usługa musi wczytać nowy plik; bez tego dalej podaje stary. Rozstrzyga zawsze test z zewnątrz, na przykład openssl s_client z weryfikacją nazwy.

Podstawa techniczna

• TLS - RFC 8446, https://www.rfc-editor.org/rfc/rfc8446.
• Certyfikaty X.509 i walidacja ścieżki - RFC 5280, https://www.rfc-editor.org/rfc/rfc5280.
• Sprawdzanie tożsamości usługi względem nazwy - RFC 6125, https://www.rfc-editor.org/rfc/rfc6125.
• SNI, czyli przekazanie nazwy serwera podczas negocjacji - RFC 6066, https://www.rfc-editor.org/rfc/rfc6066.
• Procedury walidacji DV i OV - CA/Browser Forum Baseline Requirements, wersja 2.2.9, https://cabforum.org/working-groups/server/baseline-requirements/requirements/.
• Procedura EV - CA/Browser Forum Extended Validation Guidelines, wersja 2.0.3, https://cabforum.org/working-groups/server/extended-validation/guidelines/.
• Opcje s_client i weryfikacji - dokumentacja OpenSSL 3.6, https://docs.openssl.org/3.6/man1/openssl-s_client/ oraz https://docs.openssl.org/3.6/man1/openssl-verification-options/.
• Port HTTPS - IANA Service Name and Transport Protocol Port Number Registry, https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml.