{"id":13570,"date":"2026-10-15T18:40:00","date_gmt":"2026-10-15T16:40:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=13570"},"modified":"2026-10-09T23:06:13","modified_gmt":"2026-10-09T21:06:13","slug":"lancuchy-certyfikatow-dlaczego-strona-otwiera-sie-w-przegladarce-a-zawodzi","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/pl\/it-networks-pl\/tutorials-pl-it-networks-pl\/lancuchy-certyfikatow-dlaczego-strona-otwiera-sie-w-przegladarce-a-zawodzi\/","title":{"rendered":"\u0141a\u0144cuchy certyfikat\u00f3w: dlaczego strona otwiera si\u0119 w przegl\u0105darce, a zawodzi w curl"},"content":{"rendered":"

Uzgadnianie TLS wygl\u0105da jak pojedyncze tak albo nie, ale obejmuje sprawdzenie \u015bcie\u017cki zaufania. Serwer przedstawia certyfikat, a klient musi zbudowa\u0107 od niego \u015bcie\u017ck\u0119 do korzenia, kt\u00f3remu ju\u017c ufa. Sprawdzenie ko\u0144czy si\u0119 powodzeniem albo nie, zale\u017cnie od tego, kt\u00f3ry klient je wykonuje.<\/p>\n

W\u0142a\u015bnie to zaskakuje. Ten sam serwer w tej samej sekundzie bywa uznany przez Chrome i odrzucony przez curl.<\/p>\n

\n\"Niepe\u0142ny
Jeden niepe\u0142ny \u0142a\u0144cuch, dwa werdykty – r\u00f3\u017cnic\u0105 jest pobranie, kt\u00f3re wykonuje tylko jeden z dw\u00f3ch.<\/figcaption><\/figure>\n

Co jest przesy\u0142ane w uzgadnianiu<\/h2>\n

Serwer wysy\u0142a w\u0142asny certyfikat, zwany ko\u0144cowym, i zwykle jeden lub dwa powy\u017cej. Certyfikat ko\u0144cowy niesie nazwy host\u00f3w, dla kt\u00f3rych obowi\u0105zuje, klucz publiczny i podpis. Ten podpis nie pochodzi od korzenia, lecz od certyfikatu po\u015bredniego, kt\u00f3ry z kolei zosta\u0142 podpisany przez korze\u0144.<\/p>\n

Sam korze\u0144 nigdy nie jest wysy\u0142any. Le\u017cy w magazynie zaufania systemu operacyjnego albo przegl\u0105darki, kilkaset sztuk, i jest jedyn\u0105 cz\u0119\u015bci\u0105, kt\u00f3r\u0105 klient ma ju\u017c u siebie.<\/p>\n

Klient potrzebuje zatem wszystkiego mi\u0119dzy certyfikatem ko\u0144cowym a tym korzeniem. Je\u015bli serwer nie wysy\u0142a certyfikatu po\u015bredniego, powstaje luka, a luka oznacza brak dowodu.<\/p>\n

Ogniwo, kt\u00f3re ginie<\/h2>\n

Niemal ka\u017cdy urz\u0105d certyfikacji dostarcza dwa pliki: sam certyfikat oraz pakiet z\u0142o\u017cony z certyfikatu i po\u015bredniego. W Let’s Encrypt nazywaj\u0105 si\u0119 cert.pem<\/code> i fullchain.pem<\/code>. Te nazwy nie s\u0105 ozdob\u0105.<\/p>\n

Wpisanie cert.pem<\/code> tam, gdzie nale\u017cy fullchain.pem<\/code>, to najcz\u0119stszy b\u0142\u0105d konfiguracji TLS w og\u00f3le, a pow\u00f3d jest oczywisty: strona otwiera si\u0119 potem bez zarzutu. Nic nie ostrzega, nic nie trafia do dziennika, a certyfikat jest naprawd\u0119 wa\u017cny.<\/p>\n

Luka istnieje wy\u0142\u0105cznie dla klient\u00f3w, kt\u00f3rzy odmawiaj\u0105 samodzielnego jej domkni\u0119cia.<\/p>\n

Dlaczego przegl\u0105darka wybacza<\/h2>\n

W certyfikacie tkwi pole o nazwie Authority Information Access. Zapisany jest w nim mi\u0119dzy innymi adres: miejsce, z kt\u00f3rego da si\u0119 pobra\u0107 wystawiaj\u0105cy certyfikat po\u015bredni. Przegl\u0105darki z niego korzystaj\u0105. Gdy \u0142a\u0144cuchowi brakuje ogniwa, pobieraj\u0105 brakuj\u0105cy certyfikat spod tego adresu, uzupe\u0142niaj\u0105 \u015bcie\u017ck\u0119 i pokazuj\u0105 k\u0142\u00f3dk\u0119.<\/p>\n

Niekt\u00f3re przegl\u0105darki przechowuj\u0105 dodatkowo w pami\u0119ci certyfikaty po\u015brednie widziane na innych stronach. Utrudnia to odtworzenie problemu: serwer z niepe\u0142nym \u0142a\u0144cuchem certyfikat\u00f3w mo\u017ce pozornie dzia\u0142a\u0107 poprawnie na dw\u00f3ch komputerach, ale na ka\u017cdym z innego powodu.<\/p>\n

curl, OpenSSL i wi\u0119kszo\u015b\u0107 bibliotek HTTP w Pythonie, PHP, Go i Javie tego nie robi\u0105. Odczytuj\u0105 to samo pole i je pomijaj\u0105, poniewa\u017c pod\u0105\u017canie za nim zamienia jedno uzgadnianie w dwa obiegi sieciowe i wprowadza w \u015brodek po\u0142\u0105czenia, kt\u00f3re ma by\u0107 bezpo\u015brednie, zale\u017cno\u015b\u0107 od obcego hosta. Ta odmowa jest zamierzona.<\/p>\n

Powstaje z tego obraz awarii o bardzo wyra\u017anym kszta\u0142cie: witryna dzia\u0142a, a ruch mi\u0119dzy maszynami nie. Operator p\u0142atno\u015bci wywo\u0142uj\u0105cy webhook, sonda monitoruj\u0105ca, aplikacja, partner odpytuj\u0105cy API – wszyscy zg\u0142aszaj\u0105 unable to get local issuer certificate<\/code>, podczas gdy przegl\u0105darka nie pokazuje niczego.<\/p>\n

\n\"Dwa
\n<\/figure>\n

Co dwana\u015bcie witryn naprawd\u0119 wysy\u0142a<\/h2>\n

Dwana\u015bcie znanych adres\u00f3w zmierzono 2 wrze\u015bnia 2026, odczytuj\u0105c wy\u0142\u0105cznie to, co serwer zaoferowa\u0142 w uzgadnianiu.<\/p>\n

Sze\u015b\u0107 wys\u0142a\u0142o trzy certyfikaty, sze\u015b\u0107 cztery. Ani jedna nie wys\u0142a\u0142a samego certyfikatu ko\u0144cowego. Okres wa\u017cno\u015bci by\u0142 u wszystkich dwunastu taki sam: 90 dni, tyle przyznaj\u0105 wystawcy zautomatyzowani i na tyle ustali\u0142a si\u0119 bran\u017ca. Pozosta\u0142a wa\u017cno\u015b\u0107 mie\u015bci\u0142a si\u0119 mi\u0119dzy 31 a 88 dniami, mediana wynios\u0142a 70 – taki rozrzut daje automatyczne odnowienie po dw\u00f3ch trzecich okresu.<\/p>\n

Jedena\u015bcie z dwunastu wynegocjowa\u0142o TLS 1.3, jedna zosta\u0142a przy 1.2. \u017badna nie przyj\u0119\u0142a TLS 1.0. Dziewi\u0119\u0107 u\u017cy\u0142o klucza ECDSA zamiast RSA. Osiem certyfikat\u00f3w pochodzi\u0142o od Let’s Encrypt, trzy od Google Trust Services, jeden od Sectigo.<\/p>\n

Znacznie mocniej ni\u017c cokolwiek innego waha\u0142a si\u0119 liczba nazw w certyfikacie: jedna na dolnym ko\u0144cu, 41 przy wikipedia.org. Ta liczba nie jest znakiem jako\u015bci, a jedynie wskaz\u00f3wk\u0105, jak zorganizowany jest ca\u0142y zas\u00f3b.<\/p>\n

Nazwy, a nie Common Name<\/h2>\n

Druga usterka wygl\u0105da z zewn\u0105trz podobnie. Certyfikat jest kompletny i wa\u017cny, tylko nie ma w nim danego hosta.<\/p>\n

Aktualne przegl\u0105darki ca\u0142kowicie ignoruj\u0105 Common Name i por\u00f3wnuj\u0105 wy\u0142\u0105cznie Subject Alternative Names. Certyfikat dla example.com<\/code>, w kt\u00f3rym brakuje www.example.com<\/code>, obejmuje dok\u0142adnie jeden z dw\u00f3ch adres\u00f3w, a przekierowanie mi\u0119dzy nimi zawodzi, zanim si\u0119 zacznie.<\/p>\n

Symbole wieloznaczne obejmuj\u0105 jeden poziom i ani jednego wi\u0119cej. *.example.com<\/code> pasuje do www.example.com<\/code>, ale ani do example.com<\/code>, ani do a.b.example.com<\/code>. Obie po\u0142owy tego zdania regularnie kosztuj\u0105 kogo\u015b awari\u0119.<\/p>\n

Odczyt bez przegl\u0105darki<\/h2>\n

R\u00f3\u017cnicy, o kt\u00f3r\u0105 chodzi, nie da si\u0119 zobaczy\u0107 w przegl\u0105darce w\u0142a\u015bnie dlatego, \u017ce przegl\u0105darka j\u0105 naprawia. Potrzebny jest klient, kt\u00f3ry tego nie robi.<\/p>\n

openssl s_client -connect example.com:443 -servername example.com < \/dev\/null\ncurl -vI https:\/\/example.com\/<\/code><\/pre>\n
W wyniku OpenSSL blok dotycz\u0105cy \u0142a\u0144cucha certyfikat\u00f3w wypisuje to, co wys\u0142a\u0142 serwer. Pojedynczy wpis oznacza brak certyfikatu po\u015bredniego, niezale\u017cnie od tego, czy wiersz weryfikacji poni\u017cej melduje ok – lokalnie zapami\u0119tany certyfikat po\u015bredni potrafi i jego uczyni\u0107 myl\u0105cym. Wiarygodne jest policzenie tego, co dotar\u0142o.<\/p>\n
Ten sam odczyt bez wiersza polece\u0144 daje Inspektor certyfikatu i uzgadniania TLS<\/a> w sekcji Toolbox: otwiera uzgadnianie, weryfikuje raz z magazynem zaufania i raz bez, wypisuje \u0142a\u0144cuch dok\u0142adnie tak, jak wys\u0142a\u0142 go serwer, a nast\u0119pnie pr\u00f3buje osobno ka\u017cdej wersji TLS. Luka pojawia si\u0119 jako \u0142a\u0144cuch o d\u0142ugo\u015bci jeden, obok weryfikacji, kt\u00f3ra zawiod\u0142a z powodu wartego przeczytania.<\/p>\n
\n
Pytania i odpowiedzi<\/h2>\n
Czy korze\u0144 powinien by\u0107 cz\u0119\u015bci\u0105 \u0142a\u0144cucha, kt\u00f3ry wysy\u0142a serwer?<\/h3>\n
Nie. Klient i tak musi ju\u017c ufa\u0107 korzeniowi, wi\u0119c do\u0142\u0105czony korze\u0144 niczego nie dowodzi i jedynie dok\u0142ada bajt\u00f3w do ka\u017cdego uzgadniania; RFC 8446 wprost pozwala go pomin\u0105\u0107. Liczy si\u0119 wy\u0142\u0105cznie to, \u017ceby obecny by\u0142 ka\u017cdy certyfikat po\u015bredni mi\u0119dzy certyfikatem ko\u0144cowym a korzeniem, a w\u0142a\u015bnie to zawiera fullchain.pem.<\/p>\n
\u0141a\u0144cuch dzia\u0142a\u0142 miesi\u0105cami, a teraz nadawca webhooka nagle zg\u0142asza unable to get local issuer certificate. Co mo\u017ce by\u0107 przyczyn\u0105?<\/h3>\n
Je\u015bli na serwerze nic nie zmieniano, w gr\u0119 wchodz\u0105 przede wszystkim dwie przyczyny, po jednej z ka\u017cdej strony po\u0142\u0105czenia:<\/p>\n
    \n
  1. Zmieni\u0142 si\u0119 certyfikat po\u015bredni. Urz\u0119dy certyfikacji od czasu do czasu przechodz\u0105 na nowe certyfikaty po\u015brednie. Konfiguracja \u0142\u0105cz\u0105ca cert.pem z plikiem po\u015brednim zapisanym raz r\u0119cznie wysy\u0142a po kolejnym odnowieniu ogniwo, kt\u00f3re nie pasuje ju\u017c do certyfikatu ko\u0144cowego, a \u015bcie\u017cka ma wtedy t\u0119 sam\u0105 luk\u0119 co zupe\u0142nie bez certyfikatu po\u015bredniego. fullchain.pem jest przy ka\u017cdym odnowieniu zapisywany na nowo z pasuj\u0105cym certyfikatem po\u015brednim i tego problemu nie ma.<\/li>\n
  2. Magazyn zaufania klienta jest przestarza\u0142y. Je\u015bli po odnowieniu \u0142a\u0144cuch ko\u0144czy si\u0119 na innym korzeniu, mo\u017ce go brakowa\u0107 w starych systemach operacyjnych albo w obrazach kontener\u00f3w, kt\u00f3rych dawno nie przebudowano. Komunikat jest ten sam, cho\u0107 serwer wysy\u0142a wszystko poprawnie.<\/li>\n<\/ol>\n
    Kt\u00f3ra z tych przyczyn zachodzi, rozstrzyga ponowne liczenie: je\u015bli openssl s_client pokazuje, \u017ce docieraj\u0105 certyfikat ko\u0144cowy i po\u015bredni, a aktualny system weryfikuje \u0142a\u0144cuch, problem le\u017cy w magazynie zaufania nadawcy i pomo\u017ce tylko aktualizacja jego listy urz\u0119d\u00f3w certyfikacji.<\/p>\n<\/div>\n
    \n
    \u0179r\u00f3d\u0142a<\/h2>\n