Czym jest łańcuch certyfikatów SSL? Jak działa

Czym jest łańcuch certyfikatów SSL?

Łańcuch certyfikatów SSL (nazywany również łańcuchem zaufania lub ścieżką certyfikacji) to uporządkowana lista certyfikatów cyfrowych, która łączy certyfikat SSL/TLS Twojej strony z zaufanym głównym Urzędem Certyfikacji (CA). Każdy certyfikat w łańcuchu jest podpisany cyfrowo przez certyfikat nad nim, tworząc weryfikowalną ścieżkę zaufania od serwera do głównego CA, któremu przeglądarki już ufają.

Pomyśl o tym jak o łańcuchu rekomendacji. Certyfikat serwera mówi „Jestem example.com”. Pośredni CA mówi „Poręczam za certyfikat example.com”. Główny CA mówi „Poręczam za tego pośrednika”. Twoja przeglądarka już ufa głównemu CA, więc śledząc łańcuch podpisów, ufa również Twojemu serwerowi.

Gdy odwiedzasz dowolną stronę HTTPS, Twoja przeglądarka śledzi ten łańcuch w milisekundach. Jeśli każde ogniwo jest poprawne, widzisz ikonę kłódki. Jeśli jakiekolwiek ogniwo brakuje, wygasło lub jest nieprawidłowe, otrzymujesz ostrzeżenie bezpieczeństwa.

Trzy ogniwa w każdym łańcuchu certyfikatów

Większość łańcuchów certyfikatów SSL ma dokładnie trzy poziomy. Zrozumienie każdego z nich jest niezbędne do rozwiązywania problemów z HTTPS.

Certyfikat Główny

Certyfikat główny to kotwica zaufania na szczycie łańcucha. Jest samopodpisany, co oznacza, że Urząd Certyfikacji podpisał własny certyfikat. Certyfikaty główne są preinstalowane w przeglądarce i systemie operacyjnym — ta kolekcja nazywana jest magazynem zaufania (trust store).

Istnieje około 150 głównych CA, którym domyślnie ufają główne przeglądarki. Organizacje takie jak DigiCert, Let's Encrypt (ISRG), Sectigo i GlobalSign operują certyfikatami głównymi. Ponieważ klucze główne są tak krytyczne, CA przechowują je w sprzętowych modułach bezpieczeństwa (HSM) wewnątrz fizycznie zabezpieczonych, odizolowanych od sieci sejfów.

Certyfikat Pośredni

Certyfikaty pośrednie znajdują się między certyfikatem głównym a certyfikatem serwera. Główny CA podpisuje certyfikat pośredni, a pośredni CA podpisuje certyfikaty końcowe (serwera). Większość CA używa jednego lub dwóch certyfikatów pośrednich.

Twój serwer musi wysyłać certyfikaty pośrednie wraz z certyfikatem leaf podczas handshake TLS. W przeciwieństwie do certyfikatów głównych, pośrednie nie są preinstalowane w przeglądarkach — jeśli serwer ich nie wyśle, łańcuch się zrywa.

Certyfikat Leaf (Certyfikat Serwera)

Certyfikat leaf (nazywany także certyfikatem końcowym lub certyfikatem serwera) to certyfikat zainstalowany na serwerze. Zawiera nazwę domeny, klucz publiczny, okres ważności oraz informacje o wydawcy (pośrednim CA, który go podpisał).

To pierwszy certyfikat, który przeglądarka otrzymuje podczas handshake TLS. Następnie przeglądarka podąża w górę łańcucha, weryfikując każdy podpis aż do dotarcia do zaufanego certyfikatu głównego.

Jak działa łańcuch zaufania

Gdy przeglądarka łączy się ze stroną przez HTTPS, handshake TLS uruchamia proces weryfikacji łańcucha, który odbywa się w milisekundach:

• Serwer wysyła certyfikaty — Serwer wysyła certyfikat leaf plus wszystkie certyfikaty pośrednie do przeglądarki.

• Przeglądarka buduje łańcuch — Przeglądarka układa certyfikaty w kolejności: leaf → pośredni(e) → główny. Identyfikuje główny sprawdzając magazyn zaufania.

• Weryfikacja podpisów — Zaczynając od leaf, przeglądarka weryfikuje, że podpis cyfrowy każdego certyfikatu został utworzony kluczem prywatnym następnego certyfikatu w łańcuchu.

• Sprawdzenie głównego — Przeglądarka potwierdza, że certyfikat główny na szczycie łańcucha istnieje w wbudowanym magazynie zaufania. Jeśli główny nie jest rozpoznany, weryfikacja kończy się niepowodzeniem.

• Sprawdzenia ważności — Dla każdego certyfikatu w łańcuchu przeglądarka sprawdza: nie wygasł, nie unieważniony (przez CRL lub OCSP), i domena certyfikatu leaf zgadza się z URL.

Co dzieje się po weryfikacji

Jeśli wszystkie sprawdzenia przejdą pomyślnie, przeglądarka nawiązuje szyfrowane połączenie i wyświetla ikonę kłódki. Jeśli jakiekolwiek sprawdzenie nie powiedzie się — nawet na certyfikacie pośrednim — przeglądarka wyświetla ostrzeżenie jak „Twoje połączenie nie jest prywatne” lub „NET::ERR_CERT_AUTHORITY_INVALID”.

Dlatego liczy się cały łańcuch, nie tylko certyfikat leaf. Wygasły certyfikat pośredni zepsuje HTTPS tak samo skutecznie jak wygasły certyfikat serwera.

Dlaczego certyfikaty pośrednie istnieją

Główne CA mogłyby teoretycznie podpisywać każdy certyfikat serwera bezpośrednio, pomijając pośrednie. Ale istnieją trzy kluczowe powody, dla których tego nie robią:

• Izolacja bezpieczeństwa — Klucze prywatne głównego CA są przechowywane offline w HSM wewnątrz fizycznie zabezpieczonych sejfów. Są używane tylko do podpisywania pośrednich, nie milionów indywidualnych certyfikatów serwerów. To drastycznie zmniejsza ryzyko kompromitacji klucza głównego.

• Ograniczenie szkód — Jeśli pośredni CA zostanie skompromitowany, dotknięte są tylko certyfikaty tego pośrednika. Główny CA może unieważnić skompromitowany pośredni i wydać nowy — bez unieważniania wszystkich kiedykolwiek wydanych certyfikatów.

• Elastyczność operacyjna — CA używają różnych pośrednich do różnych celów: jednego dla certyfikatów DV, innego dla EV, oddzielnych dla różnych regionów lub algorytmów kluczy (RSA vs ECDSA).

Jak sprawdzić łańcuch certyfikatów SSL

Istnieją trzy sposoby inspekcji łańcucha certyfikatów strony, od narzędzi wiersza poleceń po sprawdzenia w przeglądarce.

Metoda 1: OpenSSL (Wiersz poleceń)

Polecenie openssl to najbardziej szczegółowy sposób inspekcji łańcucha certyfikatów. Uruchom to w terminalu:

openssl s_client -connect example.com:443 -showcerts 2>/dev/null | grep -E 's:|i:'

Metoda 2: Przeglądarka certyfikatów

Każda główna przeglądarka pozwala na inspekcję łańcucha certyfikatów bez specjalnych narzędzi:

• Kliknij ikonę kłódki w pasku adresu przeglądarki

• Wybierz „Połączenie jest bezpieczne” → „Certyfikat jest ważny”

• Otwórz zakładkę „Ścieżka certyfikacji” (Chrome/Edge) lub „Szczegóły” (Firefox)

• Zobaczysz pełny łańcuch od głównego (góra) do leaf (dół)

Metoda 3: DNS Robot Sprawdzanie SSL

Najszybszym sposobem sprawdzenia łańcucha certyfikatów jest narzędzie online. Nasze Sprawdzanie SSL wyświetla pełny łańcuch, szczegóły wydawcy, daty ważności i status weryfikacji — jednym kliknięciem. Wpisz dowolną domenę i zobacz pełny łańcuch natychmiast.

Typowe błędy łańcucha certyfikatów i jak je naprawić

Problemy z łańcuchem certyfikatów są jedną z najczęstszych przyczyn błędów HTTPS. Oto błędy, które najprawdopodobniej napotkasz, i jak rozwiązać każdy z nich.

Brakujący certyfikat pośredni

Komunikat błędu: "unable to verify the first certificate" lub "incomplete certificate chain"

Przyczyna: Serwer wysyła tylko certyfikat leaf bez pośredniego. Przeglądarki desktopowe czasem obchodzą to, używając pośrednich z cache z poprzednich wizyt, ale przeglądarki mobilne i klienci API prawie zawsze zawodzą.

Rozwiązanie: Pobierz certyfikat pośredni z dokumentacji CA i dodaj go do pliku certyfikatu serwera. W Nginx połącz je w jeden plik:

cat your-domain.crt intermediate.crt > fullchain.crt

Samopodpisany certyfikat w łańcuchu

Komunikat błędu: "self-signed certificate in certificate chain"

Przyczyna: Certyfikat główny został niepotrzebnie włączony do łańcucha wysyłanego przez serwer, lub certyfikat jest naprawdę samopodpisany i nie pochodzi od zaufanego CA.

Rozwiązanie: Usuń certyfikat główny z pliku łańcucha serwera. Serwer powinien wysyłać tylko leaf + pośredni(e). Przeglądarki już mają główny w magazynie zaufania — wysyłanie go jest niepotrzebne i może powodować ten błąd.

Nieprawidłowa kolejność certyfikatów

Komunikat błędu: Weryfikacja łańcucha może po cichu zawieść lub wygenerować ostrzeżenia „certyfikat niezaufany”.

Przyczyna: Certyfikaty w pliku łańcucha są w złej kolejności.

Rozwiązanie: Prawidłowa kolejność to zawsze: najpierw certyfikat leaf, potem pośredni(e) od najbliższego leaf do najbliższego głównego. Nigdy nie dołączaj certyfikatu głównego.

Wygasły certyfikat w łańcuchu

Komunikat błędu: "certificate has expired" — ale data wygaśnięcia certyfikatu leaf wygląda prawidłowo.

Przyczyna: Certyfikat pośredni w łańcuchu wygasł. Jest to rzadsze, ale może wystąpić, gdy CA rotują swoje pośrednie.

Rozwiązanie: Pobierz aktualny certyfikat pośredni od CA i zastąp stary. Następnie użyj naszego Sprawdzania SSL, aby zweryfikować zaktualizowany łańcuch.

Najlepsze praktyki łańcucha certyfikatów

• Zawsze instaluj pośrednie — Nigdy nie zakładaj, że przeglądarka sama sobie poradzi. Zawsze konfiguruj serwer do wysyłania pełnego łańcucha (leaf + pośrednie).

• Nie wysyłaj głównego — Przeglądarki już mają certyfikaty główne. Włączanie głównego marnuje przepustowość i może powodować błędy u niektórych klientów.

• Zachowaj prawidłową kolejność — Najpierw leaf, potem pośrednie, bez głównego. Niektóre serwery są wymagające co do kolejności; inne tolerują ją, ale mogą być wolniejsze w weryfikacji.

• Monitoruj wygaśnięcie — Certyfikaty pośrednie też wygasają. Ustaw alerty lub użyj automatycznego zarządzania certyfikatami (jak certbot z Let's Encrypt).

• Weryfikuj po zmianach — Po odnowieniu certyfikatu lub zmianie hostingu zawsze sprawdź łańcuch narzędziem jak nasze Sprawdzanie SSL. To co działało przed odnowieniem może nie działać po, jeśli CA zmienił swój pośredni.

• Użyj OCSP Stapling — Włącz OCSP stapling na serwerze, aby przeglądarki mogły szybciej weryfikować status unieważnienia certyfikatu bez kontaktowania CA bezpośrednio.