Łańcuch certyfikatów SSL: kolejność, sprawdzanie i naprawa

Czym jest łańcuch certyfikatów SSL?

Łańcuch certyfikatów SSL (nazywany też ł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 ten powyżej, co tworzy weryfikowalną ścieżkę zaufania od Twojego serwera aż do głównego CA, któremu przeglądarki już ufają.

Wyobraź sobie to jako łańcuch poręczeń. Certyfikat Twojego 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 ten pośredni". Twoja przeglądarka już ufa głównemu CA, więc idąc po łańcuchu podpisów, ufa także Twojemu serwerowi.

Gdy wchodzisz na stronę HTTPS, przeglądarka sprawdza ten łańcuch w ciągu milisekund. Jeśli każde ogniwo jest w porządku, strona ładuje się bez ostrzeżenia. Jeśli ogniwa brakuje, wygasło lub nie jest zaufane, zamiast strony zobaczysz ostrzeżenie bezpieczeństwa, na przykład NET::ERR_CERT_AUTHORITY_INVALID.

Trzy rodzaje certyfikatów w łańcuchu

Każdy łańcuch ma trzy rodzaje certyfikatów, choć serwer może wysłać więcej niż jeden pośredni:

Certyfikat główny

Certyfikat główny to punkt zaufania na szczycie łańcucha. Jest samopodpisany, czyli urząd certyfikacji podpisał własny certyfikat. Certyfikaty główne są zainstalowane z góry w przeglądarce i systemie operacyjnym — ten zbiór nazywa się magazynem zaufania.

Własna lista Chrome zawiera około 100 certyfikatów głównych (Chrome Root Store); Mozilla, Apple i Microsoft prowadzą własne listy. Certyfikaty główne utrzymują organizacje takie jak DigiCert, Let's Encrypt (ISRG), Sectigo, GlobalSign i Google Trust Services. Ponieważ klucze główne są bardzo cenne, urzędy certyfikacji trzymają je offline w sprzętowych modułach bezpieczeństwa i używają ich wyłącznie do podpisywania certyfikatów pośrednich.

Certyfikat pośredni

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

Twój serwer WWW musi wysyłać certyfikaty pośrednie razem z certyfikatem leaf podczas handshake TLS. Chrome potrafi pobrać brakujący certyfikat pośredni, a Firefox ma je wczytane z góry, ale aplikacje, klienci API i starsze urządzenia z Androidem nie mają żadnej z tych możliwości, więc dla nich ł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 swoje certyfikaty — najpierw leaf, potem pośrednie.
• Przeglądarka buduje ścieżkę — od leaf w górę do certyfikatu głównego z własnej listy. Jeśli brakuje certyfikatu pośredniego, Chrome pobiera go z adresu zapisanego w certyfikacie (AIA), a Firefox używa własnego, wczytanego z góry zestawu; wielu innych klientów po prostu kończy się błędem.
• Sprawdzane są podpisy — każdy certyfikat musi być podpisany kluczem tego powyżej.
• Sprawdzany jest certyfikat główny — ścieżka musi kończyć się certyfikatem głównym z listy przeglądarki. Nieznany certyfikat główny nie przechodzi weryfikacji.
• Sprawdzana jest ważność — każdy certyfikat musi mieścić się w swoich datach i nie może być unieważniony, a leaf musi obejmować nazwę z paska adresu.

Prawdziwe łańcuchy: co wysyła 12 dużych serwisów

27 października 2026 roku poprosiliśmy 12 największych serwisów o ich łańcuchy (openssl s_client -showcerts, z dwóch lokalizacji). Żaden nie wysłał samego leaf, a kilka dodało certyfikaty podpisane krzyżowo, aby starsze urządzenia mogły mimo wszystko dotrzeć do znanego im certyfikatu głównego. To, co wysyła serwer, może się zmieniać zależnie od wersji TLS, obsługi ECDSA przez klienta i tego, która lokalizacja CDN odpowiada: na przykład facebook.com wysłał przez TLS 1.2 3 certyfikaty.

Co dzieje się po weryfikacji

Jeśli wszystkie kontrole przejdą, połączenie jest nawiązywane. Jeśli którakolwiek zawiedzie, nawet dla certyfikatu pośredniego, przeglądarka pokazuje ostrzeżenie w rodzaju "Połączenie nie jest prywatne" z kodem takim jak NET::ERR_CERT_AUTHORITY_INVALID. (Błędy, które pojawiają się, zanim w ogóle zajrzy się do certyfikatów, czyli w samym handshake TLS, pokazują inne kody: ERR_SSL_PROTOCOL_ERROR lub ERR_SSL_VERSION_OR_CIPHER_MISMATCH.)

Dlatego liczy się cały łańcuch, a nie tylko certyfikat leaf. Wygasły certyfikat pośredni psuje HTTPS tak samo jak wygasły certyfikat serwera, chyba że klient potrafi zbudować inną ścieżkę z pominięciem go.

Dlaczego certyfikaty pośrednie istnieją

Główne CA mogłyby teoretycznie podpisywać każdy certyfikat serwera bezpośrednio, pomijając certyfikaty pośrednie. Istnieją jednak trzy ważne 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żą tylko do podpisywania certyfikatów pośrednich, a nie milionów pojedynczych certyfikatów serwerów. To drastycznie zmniejsza ryzyko kompromitacji klucza głównego.
• Ograniczenie szkód — Jeśli pośredni CA zostanie skompromitowany, ucierpią tylko certyfikaty wydane przez ten certyfikat pośredni. Główny CA może unieważnić skompromitowany certyfikat pośredni i wydać nowy — bez unieważniania wszystkich certyfikatów, jakie kiedykolwiek wystawił.
• Elastyczność operacyjna — Urzędy certyfikacji używają różnych certyfikatów pośrednich do różnych celów: jednego dla certyfikatów DV, innego dla EV, osobnych dla różnych regionów lub algorytmów kluczy (RSA i 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:

# List each certificate the server sends (s: subject, i: issuer)
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | grep -E ' [si]:'

# Then read the verdict
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | grep -m1 'Verify return code'

Metoda 2: podgląd certyfikatu w przeglądarce

Każda duża przeglądarka pokazuje zbudowany przez siebie łańcuch (może się on różnić od wysłanego przez serwer, jeśli przeglądarka sama pobrała brakujący certyfikat pośredni):

• Chrome: kliknij ikonę po lewej stronie adresu → Połączenie jest bezpieczne → Certyfikat jest ważny, a potem otwórz kartę Szczegóły, aby zobaczyć hierarchię certyfikatów
• Edge: kliknij kłódkę → "Connection is secure" → ikona certyfikatu u góry panelu
• Firefox: kliknij kłódkę → "Connection secure" → "More information" → "View Certificate"; każdy certyfikat w łańcuchu ma własną kartę
• Safari (18.4 i nowsze): wybierz w pasku menu Safari > Szczegóły zabezpieczeń połączenia (Apple); na iPhonie dotknij lewej strony pola adresu → "Privacy & Security" → "Connection Security Details"

Metoda 3: sprawdzanie SSL w DNS Robot

Najszybsze sprawdzenie spoza Twojej sieci to nasze Sprawdzanie SSL: pokazuje łańcuch wysyłany przez serwer, to, czy ufają mu listy certyfikatów głównych Mozilli, Chrome, Apple i Microsoftu, ostrzeżenie o niepełnym łańcuchu i daty każdego certyfikatu. Dla stron za Cloudflare odczytuje certyfikat z publicznych logów CT, więc tam łańcuch wysyłany przez serwer nie jest sprawdzany.

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 o błędzie: "unable to get local issuer certificate" (curl, Python, PHP), "unable to verify the first certificate" (Node.js) lub "incomplete certificate chain"

Przyczyna: serwer wysyła tylko certyfikat leaf. Chrome często naprawia to, pobierając certyfikat pośredni samodzielnie (podobnie weryfikator Apple), więc strona może w przeglądarce wyglądać dobrze, podczas gdy curl w Linuksie, Python, Java, wywołania zwrotne płatności i wiele aplikacji zawodzą.

Rozwiązanie: wysyłaj certyfikaty pośrednie razem z leaf. Przy Let's Encrypt wskaż serwerowi fullchain.pem, a nie cert.pem; przy innym urzędzie pobierz jego certyfikat pośredni i umieść go po swoim certyfikacie w jednym pliku:

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

Samopodpisany certyfikat w łańcuchu

Komunikat o błędzie: "self-signed certificate in certificate chain" (błąd OpenSSL 19)

Przyczyna: łańcuch kończy się certyfikatem głównym, któremu klient nie ufa: prywatnym lub firmowym CA albo proxy lub antywirusem, który ponownie podpisuje ruch własnym certyfikatem głównym. Wysłanie certyfikatu głównego, któremu klient ufa, jest nieszkodliwe, tylko zbędne.

Rozwiązanie: dla stron publicznych użyj certyfikatu publicznego CA albo zainstaluj prywatny certyfikat główny u klientów, którzy go potrzebują. Pominięcie certyfikatu głównego w łańcuchu serwera jest schludniejsze, ale tego błędu nie naprawi.

Nieprawidłowa kolejność certyfikatów

Komunikat o błędzie: weryfikacja łańcucha zawodzi u niektórych klientów albo zgłaszają oni, że certyfikat nie jest zaufany.

Przyczyna: certyfikaty w pliku łańcucha są w złej kolejności. TLS 1.3 wymaga, by własny certyfikat serwera był pierwszy, a pozostałe szły po kolei, ale każe klientom radzić sobie także z inną kolejnością (RFC 8446 §4.4.2); starsi lub bardziej rygorystyczni klienci mogą sobie nie poradzić.

Rozwiązanie: umieść certyfikat leaf na początku, a potem każdy certyfikat pośredni, zaczynając od tego, który podpisał Twój leaf.

Wygasły certyfikat w łańcuchu

Komunikat o błędzie: "certificate has expired" — ale data ważności Twojego certyfikatu leaf wygląda dobrze.

Przyczyna: wygasł certyfikat wyżej w łańcuchu. Najsłynniejszy przypadek: DST Root CA X3 firmy IdenTrust, który krzyżowo podpisywał certyfikat główny Let's Encrypt, wygasł 30 września 2021 roku, a urządzenia, które nie ufały ISRG Root X1 (oraz klienci z OpenSSL 1.0.x), zaczęły zawodzić na stronach z Let's Encrypt.

Rozwiązanie: pobierz aktualny certyfikat pośredni od swojego CA i zastąp nim stary. Następnie sprawdź zaktualizowany łańcuch w naszym Sprawdzaniu SSL.

Najlepsze praktyki łańcucha certyfikatów

• Zawsze wysyłaj certyfikaty pośrednie — nie licz na to, że przeglądarki naprawią łańcuch; aplikacje i klienci API tego nie zrobią.
• Certyfikat główny jest opcjonalny — klienci używają własnej kopii, więc wysłanie zaufanego dla nich certyfikatu głównego tylko dodaje bajty; certyfikat główny podpisany krzyżowo dla starszych urządzeń to świadomy wyjątek.
• Zachowaj kolejność — najpierw leaf, potem certyfikaty pośrednie, od tego, który podpisał Twój leaf, w górę.
• Zautomatyzuj odnawianie — certyfikaty wydane od marca 2026 działają najwyżej 200 dni, a w marcu 2027 skrócą się do 100, natomiast Let's Encrypt przechodzi na certyfikaty 64-dniowe w lutym 2027.
• Sprawdzaj po każdym odnowieniu lub przeprowadzce — urząd certyfikacji może zmienić certyfikaty pośrednie między odnowieniami. Potem przepuść stronę przez Sprawdzanie SSL.
• Pilnuj każdej nazwy — www, domena bez prefiksu i każda subdomena mogą być obsługiwane przez różne certyfikaty i łańcuchy. Wyszukiwarka subdomen wypisuje nazwy objęte Twoimi certyfikatami, na podstawie publicznych logów certyfikatów.