- A HTTPS megléte alapkövetelmény, a hiánya viszont mérhető veszteség: a böngésző figyelmeztetése az űrlapok előtt állítja meg a látogatót.
- A lejárt tanúsítvány nem lassú romlás, hanem egyik pillanatról a másikra teljes elérhetetlenség, ezért az automatikus megújítás és a lejárat-figyelés kötelező.
- A vegyes tartalom (HTTPS oldalon HTTP-s kép, script, iframe) csendben rontja a lakat ikont és blokkolhat funkciókat.
- Néhány biztonsági fejléc (HSTS, X-Content-Type-Options, Referrer-Policy) percek alatt beállítható, és valós támadási felületet szűkít.
- Az AI-válaszmotorok és a crawlerek számára a hibás tanúsítvány egyszerűen csak elérhetetlen oldalt jelent, így a tartalmad ki sem kerül a válaszokba.
A biztonsági beállítások ritkán kerülnek elő egy marketinges megbeszélésen. Amíg működik minden, senki nem beszél róla, amikor pedig elromlik, már nem marketingkérdés, hanem üzemzavar. Pedig a titkosítás, a tanúsítvány és a hozzá kapcsolódó fejlécek pontosan olyan bizalmi jelek, mint a kirakat tisztasága vagy a telefonon felvett hívás: nem hoznak új vevőt, de a hiányuk elvisz jó néhányat.
Miért alapelvárás ma a HTTPS, és miért nem versenyelőny?
Röviden: a HTTPS ma belépőjegy. Attól, hogy titkosított a kapcsolat, senki nem kerül előrébb, viszont ha hiányzik vagy hibás, azzal jó eséllyel veszítesz látogatót, kitöltött űrlapot és bizalmat.
Hivatalosan igazolt: a Google 2014-ben jelentette be, hogy a HTTPS gyenge, könnyű súlyú rangsorolási jelként számít, és azóta is fenntartja, hogy a biztonságos kapcsolat elvárás. A böngészők ennél sokkal keményebbek: a Chrome és a Firefox évek óta kiírja a nem biztonságos jelzést a HTTP-s oldalak címsorába, jelszó- és bankkártyamezőknél pedig külön figyelmeztetést is ad.
A gyakorlati különbség itt keletkezik. A keresőben egy hajszálnyi jelről beszélünk, a látogató fejében viszont egy pirosan villogó figyelmeztetésről. Saját tapasztalat: a magyar kkv-oldalakon szinte kivétel nélkül a második okoz kárt. Egy székesfehérvári fogtechnikai labor időpontkérő űrlapja, egy debreceni szerviz árajánlatkérője vagy egy egri panzió foglalási oldala mind olyan pont, ahol a látogató személyes adatot ad meg. Ha ott figyelmeztetést lát, nem elemzi a technikai hátteret, egyszerűen kilép.
Ezért érdemes átkeretezni a kérdést. Nem azt kell kérdezned, hogy mit nyersz a HTTPS-szel, hanem azt, hogy mit veszítesz nélküle, illetve rosszul beállított változatával.
Mit lát pontosan a látogató, ha baj van a tanúsítvánnyal?
Röviden: nem finom jelzést kap, hanem egy teljes képernyős figyelmeztető oldalt, amin tovább kell kattintania, hogy egyáltalán lássa a tartalmadat.
A tanúsítványhibáknak több tipikus formája van, és mindegyik máshogy néz ki a felhasználó oldaláról:
- Lejárt tanúsítvány: teljes képernyős figyelmeztetés, a látogatók túlnyomó része itt visszafordul.
- Névegyezési hiba: a tanúsítvány a
pelda.hunévre szól, de a látogató awww.pelda.hucímet nyitja meg (vagy fordítva). Ilyenkor a fél forgalom hibába fut, a másik fele meg észre sem veszi a problémát. - Hiányos tanúsítványlánc: asztali böngészőben működik, mobilon vagy régebbi eszközön viszont hibát dob. Ez a legalattomosabb, mert a tulajdonos a saját gépén nem látja.
- Önaláírt tanúsítvány: tesztkörnyezetben rendben van, éles oldalon soha nem elfogadható.
Saját tapasztalat: a névegyezési és a láncproblémák hónapokig elélnek észrevétlenül, mert a cégvezető a saját, korábban már megnyitott verziót használja, ahol a böngésző gyorsítótára elfedi a hibát. Érdemes rendszeresen inkognitó ablakból, mobilhálózatról is megnézni az oldalt.
Hogyan kezeli a kereső és az AI-válaszmotor a biztonsági jeleket?
Röviden: a keresőrobot és az AI-crawler számára a hibás tanúsítvány nem bizalmi kérdés, hanem elérhetetlenség. Amit nem tud letölteni, azt nem is idézi.
Hivatalosan igazolt: a Google Search Central dokumentációja szerint a HTTPS a keresőbarát oldal alapkövetelményei közé tartozik, és a Search Console külön jelzi az indexelési hibákat, ha a robot nem éri el a tartalmat. A Googlebot bizonyos esetekben elnézőbb a tanúsítványhibákkal, mint a böngésző, de erre építeni nem szabad.
Szakmai feltételezés: az AI-válaszmotorok és az ügynöki böngészést végző eszközök jó eséllyel szigorúbbak, mint a klasszikus keresőrobot. Ezek jellemzően szabványos HTTP-kliensekre épülnek, amelyek alapértelmezetten megtagadják a kapcsolatot érvénytelen tanúsítvány esetén, és nincs mellettük ember, aki rákattintana a folytatásra. Ez a feltételezés a kliensek működéséből következik, nem hivatalos nyilatkozatból, de a következtetés praktikus: ha az oldalad tanúsítványa hibás, a tartalmad valószínűleg egyszerűen kimarad az AI-válaszokból.
Ugyanez igaz a lassú, összevissza átirányított HTTPS-re is. Ha a http://pelda.hu címről három ugrással jutsz el a https://www.pelda.hu címre, azzal minden robotnak és minden mobilos látogatónak fizetsz egy kis adót.
Mi az a vegyes tartalom, és miért marad benn hónapokig?
Röviden: vegyes tartalom akkor keletkezik, ha a HTTPS-en kiszolgált oldal HTTP-n keresztül tölt be képet, betűtípust, scriptet vagy beágyazott térképet. A böngésző ilyenkor vagy leveszi a biztonságos jelölést, vagy egyenesen blokkolja az elemet.
A klasszikus magyar kkv-forgatókönyv: az oldal 2016-ban készült HTTP-n, később a tárhelyszolgáltató bekapcsolta a HTTPS-t, de az adatbázisban maradtak a régi, http:// kezdetű képhivatkozások. A főoldal rendben van, mert azt átnézte valaki, a 2018-as blogbejegyzésekben viszont ott maradtak a régi útvonalak.
WordPress-oldalon a keresés és csere az adatbázisban működik a legmegbízhatóbban, de csak akkor, ha a szerializált mezőket is helyesen kezeli az eszköz (a WP-CLI search-replace parancsa ilyen). Átmeneti hálóként a szerver oldalán is felteheted ezt a fejlécet:
Content-Security-Policy: upgrade-insecure-requests
Ez arra utasítja a böngészőt, hogy a HTTP-s hivatkozásokat automatikusan HTTPS-en próbálja letölteni. Fontos: ez tüneti kezelés. Ha az adott erőforrás csak HTTP-n érhető el (például egy régi, elhagyott külső szolgáltatóé), akkor a kép egyszerűen nem fog betöltődni, csak most már csendben.
Saját tapasztalat: a vegyes tartalom leggyakoribb rejtett forrásai a beágyazott térképek, a régi YouTube-beágyazások, a külső betűtípus-hivatkozások és a webshopokban a szállítmányozói nyomkövető szkriptek. Érdemes a böngésző fejlesztői konzoljában (F12) végigkattintani az öt legfontosabb oldaltípust: főoldal, szolgáltatásoldal, blogbejegyzés, termékoldal, kapcsolat.
Mi történik, ha lejár a tanúsítvány, és hogyan előzöd meg?
Röviden: a lejárat nem fokozatos romlás, hanem egyik percről a másikra bekövetkező teljes leállás. Az oldal él, a szerver válaszol, a látogató mégis figyelmeztető képernyőt lát.
A Let's Encrypt tanúsítványok jellemzően 90 napig érvényesek, és automatikus megújításra tervezték őket. A hiba szinte mindig ott keletkezik, hogy a megújítás valamiért elakad (megváltozott a webszerver konfigurációja, elköltözött az oldal, blokkolva lett a megújítási útvonal), és erről senki nem kap értesítést.
Amit érdemes beállítani egy kkv-oldalon:
- Ellenőrizd, hogy a tárhelyszolgáltatód automatikusan újít-e, és hogy hova küldi a hibaüzenetet. Ha egy már nem használt céges címre, az annyi, mintha sehova nem küldené.
- Állíts be külső lejárat-figyelést, ami legalább 14 nappal a lejárat előtt szól. Erre több ingyenes uptime-figyelő szolgáltatás is alkalmas.
- Írd fel, hol lakik a tanúsítvány. Ha az oldal Cloudflare mögött van, ott is van tanúsítvány, és a szerveren is, a kettő lejárata külön él.
- Parancssorból bármikor ellenőrizheted:
curl -vI https://pelda.hu, a kimenetben ott lesz a tanúsítvány érvényességi ideje és a kibocsátó.
Szakmai feltételezés: a lejárat okozta kiesés SEO-hatása jellemzően átmeneti, ha néhány órán belül javítod, mert a keresők ismételten próbálkoznak. Napokig tartó kiesésnél viszont már reális az indexelési visszaesés kockázata. Ez a tapasztalati mintázatokból levont következtetés, nem hivatalos állásfoglalás.
Milyen biztonsági fejlécek érik meg egy magyar kkv-oldalon?
Röviden: néhány fejléc szinte kockázatmentesen bekapcsolható és valós támadási felületet szűkít, a szigorú tartalombiztonsági szabályzat viszont már gondos tesztelést kíván.
Nginx alatt egy visszafogott, de értelmes alapkészlet így néz ki:
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;add_header X-Content-Type-Options "nosniff" always;add_header Referrer-Policy "strict-origin-when-cross-origin" always;add_header X-Frame-Options "SAMEORIGIN" always;
Mit csinálnak ezek?
- Strict-Transport-Security (HSTS): megmondja a böngészőnek, hogy ezt a domaint a jövőben csak HTTPS-en nyithatja meg. Ezzel megszűnik az első, védtelen HTTP-kérés. Figyelem: az
includeSubDomainsminden aldomainre vonatkozik, tehát csak akkor tedd be, ha a levelezőfelület, a webmail vagy a régi tesztaloldal is HTTPS-en él. - X-Content-Type-Options: megakadályozza, hogy a böngésző kitalálja egy fájl típusát. Feltöltéses oldalakon (önéletrajz, tervrajz, fotó) ez valós védelem.
- Referrer-Policy: szabályozza, mennyi információ szivárog át a hivatkozó címből másik oldalra. Egy nyíregyházi könyvelőirodánál ez adatvédelmi kérdés is: az ügyfélportál URL-je ne kerüljön ki külső szolgáltatóhoz.
- X-Frame-Options: megakadályozza, hogy más az oldaladat keretbe ágyazva jelenítse meg és félrevezető kattintásokat gyűjtsön.
A teljes Content-Security-Policy ennél nagyságrenddel bonyolultabb, mert minden külső szkriptet (analitika, hirdetéskövetés, chatablak, betűtípus) engedélyezni kell benne. Saját tapasztalat: érdemes először Content-Security-Policy-Report-Only módban futtatni néhány hétig, mert így csak jelentést kapsz, blokkolás nélkül. Aki ezt kihagyja, annak jellemzően a hirdetési konverziómérése áll le először, és ezt hetekig nem veszi észre senki.
Hogyan nézed át a saját oldalad fél óra alatt?
Röviden: hét lépés, technikai előképzettség nélkül is végigvihető, és a többsége böngészőből elvégezhető.
- Nyisd meg inkognitó ablakban a
http://pelda.hu,http://www.pelda.hu,https://pelda.huéshttps://www.pelda.hucímeket. Mind a négynek egyetlen ugrással ugyanoda kell érkeznie. - Kattints a címsor lakat ikonjára, és nézd meg a tanúsítvány érvényességét meg a kibocsátót.
- Nyisd meg a fejlesztői konzolt (F12), és keress sárga vagy piros vegyes tartalom figyelmeztetést az öt legfontosabb oldaltípuson.
- Ellenőrizd a fejléceket:
curl -sI https://pelda.hu, és nézd meg, ott van-e a HSTS meg a többi sor. - Próbáld ki az oldalt mobilhálózatról, más eszközön is, a tanúsítványlánc hibái itt bukkannak fel.
- A Search Console Oldalak jelentésében nézd meg, van-e olyan URL, ami HTTP-s változatban indexelt maradt.
- Írd be a naptárba a tanúsítvány lejárati dátumát, és állíts be egy külső figyelőt is.
Ez a lista nem garantál sérthetetlen oldalt, és nem helyettesíti a rendszeres frissítéseket sem. Arra viszont jó, hogy kizárd azokat a hibákat, amelyek a legtöbb magyar kkv-oldalon éveken át ott ülnek anélkül, hogy bárki tudna róluk.
Mit jelez mindez összességében a látogatónak?
Röviden: azt, hogy valaki figyel az oldalra. A biztonsági jelek közvetett bizonyítékok arról, hogy a cég működik, karbantart és nem hagyta magára a saját webhelyét.
Egy lejárt tanúsítvány vagy egy elmaradt frissítés önmagában nem árulja el, hogy jó szakember vagy-e. Amit a látogató mégis kiolvas belőle, az egy arányosítás: ha az alapokat nem tartod karban, vajon a megrendelt munkát karbantartod-e. Ez nem logikus következtetés, de emberi, és a vásárlási döntés így működik.
A jó hír, hogy ez a terület véges. A tartalom írása sosem ér véget, a biztonsági alapok viszont egyszer rendbe tehetők, és utána már csak figyelést igényelnek.
Források és további olvasnivalók
- Google Search Central: HTTPS és biztonságos webhelyek dokumentáció
- Google Search Console súgó: Oldalak indexelése jelentés
- Mozilla Developer Network (MDN): Mixed content, Strict-Transport-Security, Content-Security-Policy, Referrer-Policy
- Let's Encrypt hivatalos dokumentáció: tanúsítvány-életciklus és automatikus megújítás
- OWASP: Secure Headers Project, Transport Layer Security Cheat Sheet
- W3C: Content Security Policy Level 3 specifikáció
- Mozilla Observatory: webhely biztonsági fejléc-ellenőrző
Gyakori kérdések
Ha van HTTPS-em, előrébb kerülök a Google-ben?
Nem így működik. A Google hivatalosan gyenge, könnyű súlyú jelként kezeli a HTTPS-t, tehát önmagában nem hoz érdemi helyezésjavulást. A hiánya viszont látogatót visz el, mert a böngésző figyelmeztetést ír ki, különösen űrlapok és bankkártyamezők mellett.
Elég az ingyenes Let's Encrypt tanúsítvány, vagy fizetőset kell venni?
Titkosítási szempontból nincs különbség: a böngésző ugyanúgy elfogadja mindkettőt, és a látogató ugyanazt a lakat ikont látja. A különbség a hitelesítés mélységében és a szolgáltatói támogatásban van. Egy tipikus magyar kkv-oldalon a Let's Encrypt teljesen megfelelő, feltéve hogy az automatikus megújítás valóban működik.
Honnan tudom, hogy van-e vegyes tartalom az oldalamon?
Nyisd meg az oldalt Chrome-ban, nyomj F12-t, és nézd meg a Console fület. A vegyes tartalom figyelmeztetései itt jelennek meg, jellemzően mixed content szöveggel. Érdemes végigmenni a főoldalon, egy szolgáltatásoldalon, egy régi blogbejegyzésen és a kapcsolat oldalon is, mert a hiba általában a régi tartalmakban ül.
Mi történik, ha bekapcsolom a HSTS-t, aztán valamiért vissza kell állnom HTTP-re?
A HSTS-t a böngésző eltárolja a beállított időtartamra, ezért a visszaállás nehézkes: a korábbi látogatók böngészője továbbra is HTTPS-t fog erőltetni. Ha bizonytalan vagy, indíts rövid, néhány órás max-age értékkel, teszteld, és csak utána emeld egy évre.
Az AI-válaszmotorok is látják, ha rossz a tanúsítványom?
Hivatalos nyilatkozat erről nincs, ezért ez szakmai feltételezés: az AI-crawlerek szabványos HTTP-klienseket használnak, amelyek alapértelmezetten megtagadják a kapcsolatot érvénytelen tanúsítvány esetén, és nincs mellettük ember, aki továbbkattintana. Vagyis a hibás tanúsítvány jó eséllyel egyszerűen elérhetetlenné teszi a tartalmadat számukra.
Milyen gyakran kell ellenőrizni ezeket a beállításokat?
A tanúsítvány lejáratát érdemes automatikus figyelővel követni, ott nincs értelme kézi ellenőrzésnek. A vegyes tartalmat és a fejléceket elég negyedévente, illetve minden nagyobb oldalátalakítás, sablonváltás vagy tárhelyköltözés után átnézni, mert ezek jellemzően ilyenkor romlanak el.
Források és további olvasnivalók
Ezen az oldalon a hivatalosan igazolt információt elsődleges forrásokból építjük fel; a saját tapasztalatot és a szakmai becslést mindig külön jelöljük a szövegben.