Tanúsítványlánc-hibák: amikor csak bizonyos eszközökön hibás a HTTPS

Scheo · 2026-09-26 · olvasási idő ~10 perc · Szerző: Schmidt Péter

Egy HTTPS-oldal attól megbízható, hogy a böngésző vagy a robot fel tudja építeni a bizalmi láncot a szervered tanúsítványától egy általa ismert gyökértanúsítványig. Ha ebből a láncból hiányzik egy szem, vagy valamelyik szem lejárt, ugyanaz az oldal az egyik eszközön hibátlanul betölt, a másikon figyelmeztetést ad vagy el sem indul. Ebben a cikkben megnézzük, miért van ez így, hogyan találod meg a hibát negyedóra alatt, és mit állíts be, hogy ne a látogatóidtól tudd meg.

A cikkben háromféle állítást különítek el. A hivatalosan igazolt rész szabványból, tanúsítványkiadói vagy böngészőgyártói dokumentációból származik. A saját tapasztalat az, amit weboldalak üzemeltetése és hibakeresése közben rendszeresen látunk. A szakmai feltételezés logikus következtetés, amelyet nyilvános dokumentáció nem erősít meg egyértelműen.

Mi az a tanúsítványlánc, és mikor számít hibásnak?

A tanúsítványlánc a szerver saját tanúsítványától a köztes tanúsítványokon át egy megbízható gyökértanúsítványig vezető aláírási sor. Akkor hibás, ha a kliens ezt a sort nem tudja végigjárni.

A gyakorlatban három szintről beszélünk. A levéltanúsítvány (leaf) a te domainedre szól. Ezt egy köztes tanúsítvány (intermediate) írta alá, amelyet a kiadó gyökértanúsítványa (root) hitelesített. A gyökér a böngészők és az operációs rendszerek beépített tárolójában van, a köztes tanúsítvány viszont általában nincs ott.

Hivatalosan igazolt. A TLS szabvány szerint a köztes tanúsítványokat a szervernek kell elküldenie a kézfogás során. A gyökeret nem szükséges küldeni, mert azt a kliensnek már ismernie kell. Ha a szerver csak a saját tanúsítványát küldi, a kliensnek nincs miből összeraknia a láncot.

Miért működik a fejlesztő gépén, és miért nem egy régebbi telefonon vagy egy robotnál?

A modern asztali böngészők gyakran maguktól pótolják a hiányzó köztes tanúsítványt, a régebbi eszközök, a parancssori eszközök és a legtöbb robot viszont nem.

Ha a szerver csak a levéltanúsítványt küldi, a Chrome a tanúsítvány AIA (Authority Information Access) mezőjéből letöltheti a hiányzó elemet. A Firefox előre betölti az ismert köztes tanúsítványokat. Ha pedig korábban jártál egy olyan oldalon, amely ugyanazt a köztes tanúsítványt helyesen küldte, az a gyorsítótárból is előkerülhet. Hivatalosan igazolt, hogy a Chrome és a Firefox ilyen pótló mechanizmusokat használ, a részletek platformonként eltérnek.

A fejlesztő így azt látja, hogy minden rendben van. Közben egy HTTP-könyvtárra épülő robot (curl, Python requests, Node.js, Go), egy régebbi Android vagy egy alkalmazásba ágyazott böngésző nem tölt le semmit, egyszerűen hibával megáll. Maga a tanúsítvány érvényes, csak a szerver hiányosan mutatja be.

Melyek a leggyakoribb tanúsítványlánc-hibák?

A négy tipikus hiba a hiányzó köztes tanúsítvány, a lejárt vagy a kliens által nem ismert gyökér, a rossz kiszolgálási sorrend és az olyan tanúsítvány, amely nem érvényes arra a névre, amelyen az oldalt megnyitották.

Hiányzó köztes tanúsítvány

Ez messze a leggyakoribb. Saját tapasztalat. Tipikusan akkor jön elő, amikor valaki kézzel telepít egy megvásárolt tanúsítványt, és a tárhelypanel CA bundle mezőjét üresen hagyja. Saját szerveren a klasszikus eset az, amikor a konfiguráció a Certbot által készített cert.pem fájlra mutat a fullchain.pem helyett. Az OpenSSL ilyenkor jellemzően az unable to verify the first certificate hibát adja.

Lejárt vagy ismeretlen gyökértanúsítvány

Az eszköz tárolójában lévő gyökér is lejárhat, a régi eszköz pedig sokszor már nem kap frissítést. Hivatalosan igazolt. A Let's Encrypt korábbi keresztaláírásában szereplő DST Root CA X3 gyökér 2021. szeptember 30-án lejárt, és ez régebbi rendszereken (régi macOS és iOS verziók, OpenSSL 1.0.x alapú szerverek) hirtelen kapcsolódási hibákat okozott. A tanulság általános. Egy régi okostévé, egy kasszarendszer-integráció vagy egy vállalati proxy olyan gyökértárat használhat, amelyben az újabb gyökér még nincs benne, így az ő szemszögükből a teljesen szabályos lánc is megbízhatatlan.

Rossz kiszolgálási sorrend és felesleges elemek

A helyes sorrend a levéltanúsítvány, utána a köztes tanúsítvány vagy tanúsítványok, a gyökér felé haladva. Hivatalosan igazolt. A TLS 1.2 szabvány ezt a sorrendet írja elő. A TLS 1.3 megengedőbb, de a levéltanúsítványnak ott is az első helyen kell állnia. A legtöbb kliens elviseli a kisebb rendetlenséget, a szigorúbb könyvtárak viszont nem. Gyakori hiba az is, hogy egy régi, már lejárt köztes tanúsítvány bent marad a csomagban, vagy valaki egy másik kiadó köztes tanúsítványát másolja be egy korábbi telepítésből.

Aldomainre vagy másik névre nem érvényes tanúsítvány

A tanúsítvány csak azokra a nevekre érvényes, amelyek a SAN (Subject Alternative Name) listájában szerepelnek. A *.pelda.hu helyettesítő tanúsítvány pontosan egy szintet fed le. Jó a shop.pelda.hu névre, de nem jó magára a pelda.hu névre, és a teszt.shop.pelda.hu névre sem. Saját tapasztalat, hogy a www-s és a www nélküli változat közül gyakran csak az egyik szerepel a tanúsítványban. Az átirányítás ilyenkor nem segít, mert a kliens már a kézfogásnál, az átirányítás előtt hibát kap.

Miért a botok jelzik előbb a hibát, mint a látogatók?

A robotok ritkán pótolják a hiányzó köztes tanúsítványt, a látogatók böngészői viszont igen, így a hiba először a naplókban, a figyelőeszközökben és a linkelőnézeteknél látszik.

Saját tapasztalat. Hiányzó köztes tanúsítványnál a sorrend jellemzően ugyanaz. Először egy elérhetőség-figyelő vagy egy szerverek közötti integráció kezd hibázni (fizetési visszahívás, számlázó, készletszinkron, webhook). Aztán a közösségi médiában megosztott link előnézete marad üresen, és csak ezután érkezik egy-egy látogatói panasz régebbi telefonról. Addigra hetek is eltelhetnek, mert aki asztali gépen ránéz az oldalra, nem lát semmi rendelleneset.

Szakmai feltételezés. Arról, hogy az egyes keresőrobotok és AI-crawlerek pótolják-e a hiányzó köztes tanúsítványt, nincs részletes nyilvános leírás. Mivel ezek szerveroldali HTTP-klienseket használnak, jó eséllyel szigorúbbak, mint egy asztali böngésző. Ha a robot nem tudja felépíteni a TLS-kapcsolatot, az oldalt egyáltalán nem tölti le, ami hátráltathatja a feltérképezést és az AI-válaszokban való megjelenést is. Ezt érdemes a szervernaplóban és a Search Console feltérképezési statisztikáiban ellenőrizni, nem feltételezni. A teljes lánc kiszolgálása önmagában semmilyen helyezést nem garantál, csak azt biztosítja, hogy a technikai akadály ne álljon útban.

Hogyan ellenőrizd a tanúsítványláncot lépésről lépésre?

Futtass egy független külső tesztet, utána parancssorból ellenőrizd a láncot, a neveket és a lejáratot. A saját böngésződ zöld lakatja nem bizonyíték.

1. Független tesztoldal. A Qualys SSL Labs SSL Server Test ingyenes, és külön jelzi a lánc problémáit. Figyeld a Chain issues sort. Az Incomplete hiányzó köztes tanúsítványt jelent, az Extra download azt, hogy a kliensnek magának kellene letöltenie egy elemet. A Certification Paths és a kliens-szimulációs rész megmutatja, melyik régebbi rendszer bukik el.
2. Nyers lánc parancssorból. Futtasd le ezt: openssl s_client -connect pelda.hu:443 -servername pelda.hu -showcerts. A -servername kapcsoló fontos, mert osztott tárhelyen enélkül könnyen egy másik oldal tanúsítványát kapod. A Certificate chain blokkban a 0-s sorszám a te tanúsítványod, az 1-es a köztes. Ha csak a 0 van ott, hiányzik a köztes tanúsítvány. A kimenet végén a Verify return code: 0 (ok) a jó eredmény, a 21-es kód jellemzően hiányzó köztes tanúsítványt jelez.
3. Lejárat, kiadó és nevek. Egy sorban lekérdezheted, meddig érvényes a tanúsítvány és milyen nevekre szól: echo | openssl s_client -connect pelda.hu:443 -servername pelda.hu 2>/dev/null | openssl x509 -noout -subject -issuer -enddate -ext subjectAltName. Az -ext kapcsolóhoz OpenSSL 1.1.1 vagy újabb kell.
4. Szigorú kliens próbája. Linuxon vagy macOS-en a curl -sv https://pelda.hu -o /dev/null parancs jól mutatja, mit lát egy robot, mert a curl nem tölt le hiányzó köztes tanúsítványt. Ha itt unable to get local issuer certificate hibát kapsz, miközben a böngésző rendben mutatja az oldalt, szinte biztosan a köztes tanúsítvány hiányzik.
5. Minden név külön. Ismételd meg a vizsgálatot a www-s és a www nélküli változatra és minden aldomainre. A levelezést is nézd meg, IMAP-hoz ezzel: openssl s_client -connect mail.pelda.hu:993 -servername mail.pelda.hu, kimenő levelezéshez ezzel: openssl s_client -starttls smtp -connect mail.pelda.hu:587 -servername mail.pelda.hu.
6. Naplók átnézése. Keress TLS- vagy certificate-hibát a figyelőeszközök, a fizetési és számlázó integrációk és a webhookok naplóiban. Ha ott hetek óta van hiba, megvan a magyarázat a furcsa kiesésekre is.

Hogyan javítsd a hibát a leggyakoribb tárhelypaneleken?

A javítás szinte mindig ugyanaz. A szervernek együtt kell elküldenie a levéltanúsítványt és a hozzá tartozó köztes tanúsítvány(oka)t, helyes sorrendben, minden használt névre. A menüpontok neve verziótól és nyelvi beállítástól függően eltérhet, az alábbiak a jellemző útvonalak.

cPanel

Az SSL/TLS menüben a Manage SSL sites (SSL-oldalak kezelése) résznél látod a telepített tanúsítványt. Kézi telepítésnél a Certificate Authority Bundle (CABUNDLE) mezőbe a kiadótól kapott köztes tanúsítvány kerül. Az Autofill by Certificate gomb sokszor kitölti, de ellenőrizd, hogy valóban a kiadód aktuális köztes tanúsítványa került-e oda. Ha AutoSSL-t használsz, az SSL/TLS Status oldalon futtasd újra, és nézd meg, melyik név maradt ki.

Plesk

A Websites & Domains alatt az SSL/TLS Certificates résznél kezeled a tanúsítványokat. Let's Encrypt esetén az SSL It! bővítményben az újrakiadás általában rendbe teszi a láncot. Kézi feltöltésnél a CA certificate mezőt ne hagyd üresen, oda a köztes tanúsítvány kerül. Ellenőrizd azt is, hogy a www-s alias és a levelezés (mail.) is be van-e jelölve a védendő nevek között.

DirectAdmin

Az SSL Certificates menüben a kézi tanúsítvány beillesztése alatt külön link szolgál a CA-tanúsítvány megadására. A felirat gyakran CA Root Certificate, ami félrevezető, mert ide a köztes tanúsítvány kerül, nem a gyökér. A mentés után a webszerver újratöltése automatikus, de a külső tesztet ettől függetlenül futtasd le újra.

Saját szerver (nginx, Apache)

Nginx alatt az ssl_certificate /etc/letsencrypt/live/pelda.hu/fullchain.pem; sor a helyes, a cert.pem itt hibát okoz. Apache 2.4.8-tól a SSLCertificateFile direktívának szintén a teljes láncot tartalmazó fájlra kell mutatnia, régebbi verzióknál a köztes tanúsítvány a SSLCertificateChainFile direktívába kerül. Ha kézzel fűzöd össze, a sorrend számít: cat pelda_hu.crt koztes.crt > fullchain.crt. Utána nginx -t vagy apachectl configtest, majd újratöltés.

Ha CDN vagy proxy (például Cloudflare) áll az oldal előtt, két tanúsítványod van, egy a peremhálózaton és egy a saját szervereden. A látogató az elsőt látja, a CDN a másodikat, és bármelyiknél lehet lánchiba. Javítás után az SSL Labs tesztet a gyorsítótár törlésével futtasd újra, különben a régi eredményt kapod vissza.

Hogyan előzd meg, hogy újra előforduljon?

Figyeltesd a lejáratot és a lánc teljességét külső eszközzel, kezeld listaként az összes nevet és szolgáltatást, és minden változtatás után futtass új tesztet.

• Automatikus megújítás figyelése. Az, hogy be van kapcsolva, még nem jelenti, hogy működik. Saját szerveren a certbot renew --dry-run parancs, tárhelypanelen az AutoSSL vagy a Let's Encrypt bővítmény naplója mutatja, sikeres volt-e az utolsó kör. DNS-változás, új átirányítás vagy tárhelyköltözés után ez gyakran csendben elakad.
• Lejárati riasztás saját eszközből. Hivatalosan igazolt, hogy a Let's Encrypt 2025-ben megszüntette a lejárat előtti e-mail-értesítéseket, így erre külső figyelő kell. Jól bevált gyakorlat két riasztás, például 21 és 7 nappal a lejárat előtt.
• Rövidülő érvényesség. Hivatalosan igazolt. A CA/Browser Forum döntése alapján a nyilvános TLS-tanúsítványok maximális érvényessége 2026 márciusától 200 nap, és 2029-re fokozatosan 47 napra csökken. Kézi megújítással ez hosszú távon nem tartható fenn.
• Láncellenőrzés a lejárat mellett. A figyelő ne csak a dátumot nézze, hanem egy szigorú klienssel (curl-lel vagy openssl-lel) a lánc teljességét is. Egy kiadói köztesváltás után ugyanis a lejárat rendben lehet, a lánc mégis hibás.
• Névlista vezetése. Írd össze a fő domaint, a www-s változatot és minden aktív aldomaint (shop, blog, api, staging), és mindegyiket külön ellenőrizd. A helyettesítő tanúsítvány a fő domaint nem fedi le.
• Levelezés külön. A levelezőszerver tanúsítványa sokszor más szolgáltatásban, más megújítással él. Az IMAP (993), a POP3 (995) és az SMTP (465, 587) portokat is vedd fel a figyelésbe.
• Origin tanúsítvány a CDN mögött. A proxy mögötti szerver tanúsítványa akkor is lejárhat, ha a látogató a peremhálózat érvényes tanúsítványát látja.
• Teszt minden változtatás után. Tárhelyváltás, panelfrissítés, kiadóváltás vagy új aldomain után futtasd le a független tesztet és a curl-próbát.
• Integrációk naplója. Havonta egyszer nézz rá a szerverek közötti kapcsolatok hibanaplójára. Saját tapasztalat, hogy a lánchibát ezek jelzik a legkorábban.

Források és további olvasnivalók

• IETF RFC 8446, The Transport Layer Security (TLS) Protocol Version 1.3
• IETF RFC 5246, The Transport Layer Security (TLS) Protocol Version 1.2
• IETF RFC 5280, Internet X.509 Public Key Infrastructure Certificate and CRL Profile
• Let's Encrypt dokumentáció, Chains of Trust és a DST Root CA X3 lejáratáról szóló közlemény
• Let's Encrypt, a lejárati e-mail-értesítések megszüntetéséről szóló közlemény
• CA/Browser Forum, Baseline Requirements és az SC-081 szavazás
• Qualys SSL Labs, SSL Server Test dokumentáció
• OpenSSL dokumentáció, s_client és x509 parancsok
• Mozilla Security Blog, Intermediate CA preloading
• Google Search Central, HTTPS és a feltérképezési statisztikák jelentés