Az „SSL” kifejezést a webes biztonság kapcsán gyakran halljuk, ám a valóságban a HTTPS-kapcsolatokat ma a TLS (Transport Layer Security) protokoll védi. A biztonságos kapcsolat létrehozása nem csupán ajánlás: 2026-ban a böngészők minden HTTP oldalon figyelmeztetéseket jelenítenek meg, így a HTTPS alapelvárás.
Cikkünkben bemutatjuk a különböző SSL/TLS tanúsítványtípusokat – DV, OV, EV, wildcard és SAN –, segít a választási szempontok megértésében, valamint áttekinthető üzemeltetési és biztonsági checklistet kínál a weboldalak védelméhez.
Alapfogalmak: mit hitelesít és mit titkosít a HTTPS?
SSL vs TLS: a pontos terminológia
Bár a köznyelvben SSL-t mondunk, a valóságban a HTTPS-kapcsolatokat TLS protokoll biztosítja. A TLS 1.3 célja a lehallgatás, módosítás és hamisítás kockázatának csökkentése, miközben gyorsabb és biztonságosabb adatátvitelt biztosít a modern weben.
PKI és bizalmi lánc röviden
A tanúsítványok mögött a PKI (Public Key Infrastructure) áll, amely a következő szereplőkből épül fel:
- Kliens – a böngésző vagy más felhasználói alkalmazás
- Szerver – a weboldal, amely a tanúsítványt használja
- CA (Certificate Authority) – a tanúsítvány kibocsátója
- Root és intermediate lánc – a böngésző „trust store”-a ellenőrzi a teljes láncot
A helyes láncküldés kritikus: ha hiányzik vagy hibás a chain, a böngésző figyelmezteti a felhasználót a nem megbízható tanúsítvány miatt.
Mi van egy tanúsítványban, amit érdemes ellenőrizni?
Tanúsítvány ellenőrzéskor a következőket érdemes figyelembe venni:
- CN (Common Name) vs SAN (Subject Alternative Name) – hostnév-egyezés
- Kibocsátó – CA neve
- Lejárat – mikor jár le a tanúsítvány
- Kulcstípus és aláírási algoritmus – biztonsági szint
- Lakat ikon félreértelmezése – csak a titkosított csatornát jelzi, nem garantálja az üzleti háttér hitelességét
Amennyiben érdekli Önt az információbiztonság témaköre, látogasson el weboldalunkra!
Az SSL/TLS tanúsítvány szerepe a webbiztonságban
A három alapbiztonsági ígéret
A TLS három alapvető biztonsági célt szolgál:
Bizalmasság: a titkosítás megakadályozza a lehallgatást
Sértetlenség: az adatokat nem lehet módosítani közben
Hitelesítés: a szerver valóban az, akinek mondja magát
Amit NEM old meg (gyakori tévhitek)
A TLS nem véd meg:
- feltört szerverektől
- sebezhető pluginoktól
- rossz jogosultságkezeléstől
- adatszivárgástól
Ezért a HTTPS mellett fontos az IT biztonság és a rendszeres audit is.
Böngészői jelzések és bizalom 2026-tól
A Chrome 2026 áprilisától az Enhanced Safe Browsing felhasználóknál kiterjeszti az „Always Use Secure Connections” figyelmeztetést minden HTTP oldalra. Októbertől ez alapértelmezetté válik. HTTP aloldalak vagy redirect-ek esetén ez konverzió- és reputációveszteséget jelenthet, így a teljes HTTPS-re váltás kritikus.
SSL tanúsítványtípusok: a 3 legfontosabb csoportosítás
Ellenőrzési szint szerint: DV, OV, EV
DV (Domain Validation) – csak a domain feletti kontrollt igazolja, gyors és automatizálható
OV (Organization Validation) – domain + szervezeti adatok ellenőrzése, magasabb bizalom
EV (Extended Validation) – kiterjesztett ellenőrzés, UI-ban kevésbé látható, főleg compliance vagy brand policy miatt alkalmazott
Lefedettség szerint: single-domain, wildcard, SAN (multi-domain)
- Single-domain – egy FQDN (pl. www.example.com)
- Wildcard – egy szintnyi aldomain (pl. *.example.com), költség- és üzemeltetés előny
- SAN / UCC – több különböző hostnév egy tanúsítványban (pl. api.example.com + example.net)
Kibocsátó és felhasználás szerint: public CA, belső CA, self-signed, mTLS
- Public CA – publikus weboldalakhoz, böngésző-tröszt
- Belső CA – intranet, vállalati PKI, zero trust környezet
- Self-signed – publikus weben nem alkalmas, bizalmi lánc hiánya
- Client certificate + mTLS – B2B API-k, admin felületek, kritikus belső rendszerek
Melyiket válaszd? Gyakorlati döntési keretrendszer
Kockázat, bizalom és „identity” igény
A DV tanúsítványok elegendőek egyszerű tartalomoldalakhoz, blogokhoz vagy portfóliókhoz, míg az OV magasabb bizalmat nyújt B2B és érzékeny ügyféladatokat kezelő felületeken. Az EV főként compliance vagy brand policy okokból lehet indokolt, a böngészős kiemelésre pedig nem érdemes építeni.
Lefedettségi döntés (wildcard vs SAN)
A wildcard gyors skálázást tesz lehetővé sok aldomain esetén, de a privát kulcs kompromittálása nagy kockázatot jelent, míg a SAN több domain és API elkülönített kezelését biztosít, így komplex infrastruktúrákhoz ideális.
Üzemeltetési realitás: rövidebb érvényességi idők 2026-tól
2029. március 15-től max. 200 nap
2030. március 15-től max. 100 nap
2031. március 15-től max. 47 nap
Automatizálás (ACME), lejáratfigyelés és tanúsítvány-inventár nélkül nő a leállás esélye.
Gyors összehasonlító táblázat
| Típus | Mit igazol? | Jellemző use-case | Előny | Kockázat/korlát |
| DV | domain kontroll | tartalomoldal, landing | gyors, automatizálható | nem ellenőrzi a céget |
| OV | cég + domain | B2B, ügyfélportál | magasabb bizalom | adminisztratívabb |
| EV | szigorú cégellenőrzés | szabályozott iparág, brand policy | erős identity | böngésző UI-ban kevésbé látványos |
| Wildcard | *.domain | sok aldomain | egyszerűbb menedzsment | kulcs-kompromittálás nagyobb hatás |
| SAN | több hostnév | több domain/API | rugalmas lefedés | tervezést igényel |
Biztonságos HTTPS bevezetés és üzemeltetés: „auditálható” checklist
TLS-konfiguráció alapelvek
A TLS 1.3 alkalmazása javasolt, míg a TLS 1.2 csak erős beállításokkal, a régi protokollokat pedig érdemes tiltani; a privát kulcs védelme, rotációja és a hozzáférés-szabályozás kulcsfontosságú a biztonságos működéshez.
Kényszerített HTTPS: redirect + HSTS
A HTTP→HTTPS átirányítás (301) mellett fontos a kanonikus URL-ek és a belső linkek tisztítása, míg a HSTS segít a kényszerített HTTPS érvényesítésében, de rossz beállításnál „önzárást” okozhat, ezért a preload lista használatát érdemes megfontolni.
Mixed content és „nem teljesen biztonságos” figyelmeztetések
A HTTP erőforrások betöltése HTTPS oldalon csökkenti a felhasználói bizalmat, ezért ajánlott a statikus erőforrásokat HTTPS-re átírni, Content Security Policy-t (CSP) alkalmazni és a CDN beállításokat ellenőrizni.
Visszavonás, OCSP és Certificate Transparency
A Certificate Transparency közel kötelező infrastruktúrája segíti a tanúsítványok átláthatóságát, a Chrome ezt ellenőrzi, míg az OCSP stapling és a visszavonás gyakorlati kezelése biztosítja a hitelesítés valós idejű ellenőrzését.
Automatizált megújítás (ACME)
Az ACME szabvány, például a Let’s Encrypt révén, lehetővé teszi a tanúsítványok automatizált megújítását, ideértve a staging→prod folyamatot, a megújítási ablakot, a rollback tervet és a folyamatos monitorozást.
Gyakori hibák és hibaelhárítási minták
Tipikus böngészőhibák okai
- Lejárt tanúsítvány
- Hostnév-egyezési hiba (SAN)
- Hiányzó intermediate lánc
- Rossz szerveróra
„Nem biztonságos” jelzés HTTPS mellett is
- Mixed content, gyenge TLS beállítás, hibás átirányítási lánc, nem egységes kanonizáció (www vs non-www)
Hogyan ellenőrizd gyorsan (mini-útmutató)
- Böngésző tanúsítvány-részletek, fejlesztői konzol
- Szerver oldali logok
- Rendszeres külső TLS-szkennelés
Ha a tanúsítványkezelés, TLS-hardening, monitorozás és incidens-megelőzés egyszerre cél, egy IT-biztonsági partner segíthet a folyamatok és felelősségi körök kialakításában. Az mi IT-biztonsági szolgáltatásaink ehhez adnak kiindulópontot. Olvasson kiberbiztonsági alapokról és legjobb gyakorlatokról, és merüljön el a témában!
Az embereket ez is érdekli
Mi a különbség az SSL és a TLS között?
A TLS a modern, szabványos protokoll; az „SSL” elnevezés történelmi maradvány.
DV, OV, EV: melyik „biztonságosabb”?
A titkosítás erőssége független az ellenőrzési szinttől. A különbség abban van, hogy a CA mit igazol: domain vagy szervezet.
Biztonságos-e a Let’s Encrypt?
Igen, nyilvános CA, automatizálásra optimalizált. Biztonságos működéshez fontos a helyes TLS-konfiguráció és az automatizált megújítás.
Mi az a wildcard/SAN, és mikor melyiket érdemes választani?
Wildcard sok aldomainhez kényelmes, SAN több domain/API lefedésére alkalmas.
Mi az a mixed content és hogyan javítható?
HTTPS oldalon HTTP erőforrások betöltése. Javítás: erőforrások HTTPS-re váltása, CSP és CDN beállítások.
Miért kell 2026-tól gyakrabban megújítani a tanúsítványokat?
Iparági szabályozás (CA/B Forum) – érvényességi idők 200/100/47 napra rövidülnek, a gyorsabb rotáció és automatizálás érdekében.
GYIK
Mi a különbség az SSL és a TLS között?
A TLS a modern, szabványos protokoll, amely a HTTPS kapcsolatok biztonságát garantálja, míg az „SSL” elnevezés történelmi maradvány, ami miatt a gyakorlatban gyakran még mindig így hivatkozunk a tanúsítványokra.
A DV/OV/EV közül melyik ad erősebb titkosítást?
A tanúsítványok ellenőrzési szintje (DV, OV, EV) nem határozza meg a titkosítás erősségét; a biztonság a protokolltól, a kulcstípustól és a konfigurációtól függ.
Biztonságos a Let’s Encrypt tanúsítvány?
Igen, a Let’s Encrypt nyilvános CA-ként megbízható, a biztonság kulcsa azonban a helyes TLS-konfiguráció és a tanúsítványok automatizált megújítása.
Miért rövidül a tanúsítványok érvényessége 2026-tól?
A CA/B Forum szabályozásai miatt az érvényességi idő fokozatosan csökken, ezzel ösztönözve a gyorsabb rotációt és csökkentve a lejárat miatti szolgáltatáskimaradások kockázatát.
Mi az a wildcard tanúsítvány, és mikor rossz választás?
A wildcard kényelmes megoldás sok aldomain esetén, de ha a privát kulcs kompromittálódik, egyszerre több szolgáltatás biztonsága kerülhet veszélybe.
Mit jelent a „mixed content” és miért baj?
A „mixed content” akkor fordul elő, amikor HTTPS oldalon HTTP erőforrások töltődnek be, ami csökkenti a felhasználói bizalmat és akár blokkolhatja az oldal bizonyos részeit.
Összegzés
A „megfelelő tanúsítvány” kiválasztása: helyes típus + helyes lefedettség + helyes TLS/HSTS konfiguráció + életciklus-menedzsment. Következő lépések: tanúsítvány-inventár kialakítása, ACME automatizálás, rendszeres TLS audit, böngészőváltozások figyelése 2026-ban.