Az SSL beállítás ott szokott elcsúszni, hogy a tanúsítvány telepítése után mindenki fellélegzik, pedig a munka fele még hátravan. A böngésző lakat ikonja csak annyit jelez, hogy a kapcsolat titkosított. Azt nem mondja meg, hogy az oldal minden eleme, minden URL-változata és minden átirányítása következetesen HTTPS-en él-e. A négy klasszikus hiba (vegyes tartalom, lejárt tanúsítvány, párhuzamos www és nem-www, átirányítási hurok) az esetek nagy részét lefedi, és mindegyik jól körülhatárolható lépésekkel javítható.
Mit jelent valójában a helyes SSL beállítás?
Rövid válasz: az SSL beállítás akkor kész, ha az oldal minden aloldala és minden beágyazott erőforrása HTTPS-en tölt be, a domain minden változata egyetlen kanonikus címre mutat egy átirányítási lépésben, a tanúsítvány érvényes és automatikusan megújul, a tanúsítványlánc pedig hiánytalan.
Ez négy különálló feltétel, és külön-külön kell teljesülniük. A gyakorlatban azt látom, hogy a tanúsítvány maga ritkán hibás (saját tapasztalat), sokkal inkább a körülötte lévő konfiguráció: a CMS-ben tárolt régi URL-ek, a szerver és a tartalomkezelő egymást felülíró átirányításai, vagy egy elfelejtett aldomain.
Érdemes tudni, hogy a tanúsítványlánc hiánya asztali böngészőben gyakran észrevétlen marad, mert a Chrome és a Firefox sok esetben pótolni tudja a hiányzó köztes tanúsítványt. Mobilon, régebbi eszközön vagy szerver-szerver hívásnál (például egy fizetési szolgáltató visszahívásánál) viszont azonnal hibát dob. Ezért nem elég a saját gépeden megnézni, hogy jónak tűnik.
Miért marad hiányos a lakat, ha a tanúsítvány rendben van?
Rövid válasz: szinte biztosan vegyes tartalom (mixed content) van az oldalon, vagyis egy HTTPS-en betöltött lapon marad legalább egy http:// kezdetű erőforrás-hivatkozás.
A böngészők a beágyazott aktív tartalmat (JavaScript, CSS, iframe) HTTPS-oldalon alapból blokkolják, a képeket és médiát pedig sok esetben automatikusan HTTPS-re próbálják emelni. Ez utóbbi nem megoldás, csak elfedi a problémát: ha az erőforrás nem érhető el HTTPS-en, a kép egyszerűen eltűnik.
A diagnózis a leggyorsabb a böngésző fejlesztői eszközeivel: nyisd meg a konzolt, töltsd újra az oldalt, és keresd a mixed content figyelmeztetéseket. Ha sok aloldalról van szó, futtass egy teljes bejárást valamelyik crawlerrel, és szűrj a HTTP-s erőforrásokra.
A javítás WordPress esetén jellemzően adatbázis-szintű, mert a régi URL-ek bele vannak sülve a bejegyzésekbe és a widgetekbe. WP-CLI-vel érdemes először szárazon futtatni:
wp search-replace 'http://pelda.hu' 'https://pelda.hu' --all-tables --dry-run
Ha a találatok száma és eloszlása logikus, futtasd le a --dry-run nélkül, de csak friss adatbázis-mentés után. A szerializált adatokat tartalmazó mezők miatt kézi kereséssel és cserérével könnyű tönkretenni a beállításokat, a WP-CLI ezt helyesen kezeli.
Amit gyakran kihagynak: a téma és a bővítmények fájljaiban hardkódolt hivatkozások, a hirdetéskövető kódok, a beágyazott térképek és videók, valamint a régi e-mail sablonok. Ezekre a keresés az adatbázisban nem talál rá, a fájlokban kell keresni:
grep -rn "http://" wp-content/themes/ wp-content/plugins/
Külső, harmadik féltől származó erőforrásnál, ami tényleg nem elérhető HTTPS-en, nincs jó trükk: vagy találsz HTTPS-t támogató alternatívát, vagy leszedeted a szolgáltatóval. A vegyes tartalom megkerülése nem opció, a böngészők egyre szigorúbbak (hivatalos információ: a Chrome és a Firefox dokumentációja is ezt az irányt rögzíti).
Hogyan előzöd meg a lejárt tanúsítványt?
Rövid válasz: automatikus megújítással, plusz egy attól független lejárat-figyelővel, mert a megújító automatizmus is el tud némulni anélkül, hogy bárki észrevenné.
A Let's Encrypt tanúsítványok 90 napig érvényesek, és a megújítás jellemzően a lejárat előtt 30 nappal indul. Ha a cron feladat hibára fut, még marad egy hónapod, de csak akkor, ha valaki értesül róla. A leggyakoribb okok, amikbe futni szoktam (saját tapasztalat): a HTTP-01 hitelesítéshez szükséges /.well-known/acme-challenge/ útvonalat elnyeli egy túl mohó átirányítási szabály vagy egy biztonsági bővítmény; a domain DNS-e időközben máshova mutat; vagy a szerveren a certbot csomag frissítés után elfelejtette a régi konfigurációt.
Gyakorlati lépések:
- Ellenőrizd a megújítás működését szárazon:
certbot renew --dry-run. Ez a valós megújítás minden lépését végigjátssza, csak nem cseréli a tanúsítványt. - Nézd meg, hogy a HTTPS-átirányítási szabály kivételt tesz-e az ACME útvonalra.
- Állíts be külső lejárat-figyelést. Egy egyszerű, naponta futó ellenőrzés is elég:
echo | openssl s_client -connect pelda.hu:443 -servername pelda.hu 2>/dev/null | openssl x509 -noout -enddate - Vedd sorra az összes aldomaint és a levelezéshez használt neveket is. A lejárat leggyakrabban azon a hoston üt be, amiről mindenki elfeledkezett.
Ha tárhelyszolgáltató kezeli a tanúsítványt, akkor is kérdezd meg, hogy a megújítás automatikus-e, és kap-e valaki riasztást hibánál. A szakmai feltételezésem az, hogy a lejárt tanúsítványos esetek nagy része nem technikai hiba, hanem hiányzó értesítési lánc.
www vagy nem-www: melyiket válaszd, és mi a tényleges hiba?
Rövid válasz: az önmagában nem hiba, hogy melyiket választod, a hiba az, ha mindkettő önállóan, átirányítás nélkül elérhető marad. Válassz egyet, és minden más változat egy lépésben oda mutasson.
Négy URL-változat létezik ugyanarra a nyitóoldalra: HTTP és HTTPS, www-vel és anélkül. A helyes állapot az, hogy három közülük 301-es állandó átirányítással a negyedikre visz. Ellenőrizd mind a négyet:
curl -sIL http://pelda.hu -o /dev/null -w '%{url_effective} %{num_redirects}\n'
A num_redirects érték ideális esetben 1, legfeljebb 2. Ha 3 vagy több, felesleges lánc van a rendszerben (erről bővebben a redirect láncokról szóló írásunkban).
Apache esetén tipikus, működő megoldás a .htaccess fájlban, egyetlen szabállyal a HTTPS-re és a kanonikus hostra:
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\.pelda\.hu$ [NC]
RewriteRule ^(.*)$ https://pelda.hu/$1 [R=301,L]
Nginx-en külön server blokkban érdemes elintézni: az egyik blokk a 80-as porton és a www-s néven hallgat, és return 301 https://pelda.hu$request_uri; sorral továbbküld, a másik szolgálja ki a tartalmat. Ez tisztább, mint a feltételes megoldás, és gyorsabb is.
Fontos, hogy a döntés után a CMS beállításaiban is a kanonikus cím szerepeljen (WordPressnél a WordPress-cím és az oldalcím mezőben), a sitemap, a kanonikus címkék, a belső linkek és a Search Console property is ezt kövesse. A Google hivatalosan azt közli, hogy a HTTPS enyhe rangsorolási jel, de ez önmagában nem javít a pozíciókon, és nem garantál semmit. Az inkonzisztens URL-változatok viszont valóban meg tudják osztani a jeleket.
Mitől alakul ki átirányítási hurok, és hogyan bontod ki?
Rövid válasz: majdnem mindig attól, hogy két rendszer egymásnak feszül: a szerver HTTPS-re irányít, egy másik réteg pedig visszaküld HTTP-re, mert nem látja, hogy a kapcsolat már titkosított volt.
A leggyakoribb forgatókönyv a fordított proxy vagy CDN mögötti oldal (Cloudflare, terheléselosztó, konténeres környezet). A proxy HTTPS-en fogadja a kérést, de HTTP-n adja tovább a háttérszervernek. A CMS csak annyit lát, hogy a kérés HTTP, ezért átirányít HTTPS-re, a proxy pedig újra ugyanoda ér: kész a hurok. WordPressnél ezt a wp-config.php elején, a szerkesztést tiltó sor előtt lehet feloldani:
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') { $_SERVER['HTTPS'] = 'on'; }
Cloudflare-nél a másik klasszikus a Flexible SSL mód: a látogató és a Cloudflare között HTTPS van, a Cloudflare és a szerver között viszont HTTP. Ha a szerveren is él a HTTPS-átirányítás, azonnal hurok keletkezik. A megoldás a Full (strict) mód, érvényes szervertanúsítvánnyal.
A hibakereséshez ne a böngészőt használd, mert a gyorsítótár és a HSTS félrevezet. Ehelyett:
curl -sIL https://pelda.hu/valamelyik-aloldalés nézd végig, hova lép a kérés fejlécről fejlécre;- kapcsolj ki minden gyorsítótárazó és biztonsági bővítményt egyesével, mert ezek is beleírnak az átirányításokba;
- nézd meg, hogy a szerverkonfiguráció és a CMS nem ugyanazt a szabályt fogalmazza-e meg kétszer. Ha a szerver már intézi a HTTPS-átirányítást, a bővítménynek nem kell.
Alapelv: a HTTPS-átirányítás egyetlen helyen éljen, lehetőleg a legkülső rétegben.
Mikor érdemes bekapcsolni a HSTS-t?
Rövid válasz: csak akkor, ha az oldal és minden aldomainje már stabilan, hibátlanul fut HTTPS-en, mert a HSTS a böngészőben tárolódik, és nehezen vonható vissza.
A Strict-Transport-Security fejléc arra utasítja a böngészőt, hogy adott ideig kizárólag HTTPS-en keresse az oldalt. Ez megszünteti az első kérésnél lévő átirányítási lépést is, tehát mérhetően gyorsít. Kezdd rövid élettartammal, és csak működés után emeld:
Strict-Transport-Security: max-age=300
Ha néhány nap alatt semmi nem borult, mehet fel hosszabb értékre, és jöhet az includeSubDomains. Az előre betöltési listára (preload) való feliratkozást csak akkor javaslom, ha biztosan minden aldomain HTTPS-képes, és belátható ideig az is marad, mert a listáról lekerülni lassú folyamat.
Ellenőrzőlista: mit nézz át élesítés után?
- Mind a négy URL-változat (HTTP, HTTPS, www, nem-www) egy lépésben a kanonikus címre érkezik.
- A tanúsítványlánc hiánytalan, mobilon és külső ellenőrzővel is zöld.
- Nincs vegyes tartalom egyetlen sablontípuson sem (nyitólap, kategória, termék vagy cikk, űrlapos oldal, kosár).
- A
/.well-known/acme-challenge/útvonal nincs átirányítva vagy blokkolva. - A megújítás szárazon lefut, és valaki kap riasztást, ha hibázik.
- A sitemap, a kanonikus címkék, a belső linkek és a hreflang hivatkozások HTTPS-t és a kanonikus hostot használják.
- A Search Console property a végleges változatra van beállítva, és a sitemap újra be lett küldve.
- A webanalitika, a hirdetési konverziókövetés és a beágyazott külső szkriptek HTTPS-en töltenek.
- Az űrlapok, a fizetési visszahívások és a webhookok tesztelve vannak éles környezetben.
- A robots.txt elérhető HTTPS-en, és nem tilt le semmit véletlenül.
Hogyan függ össze mindez a keresőkkel és az AI-válaszmotorokkal?
Rövid válasz: a hibás SSL beállítás elsősorban elérési probléma, és ami nem tölt be megbízhatóan, azt nehezebben dolgozza fel bármilyen automatizált olvasó, legyen az keresőrobot vagy AI-asszisztens.
A Google hivatalosan a HTTPS-t rangsorolási jelként tartja számon, de kicsi súllyal. Sokkal fontosabb a közvetett hatás: a hurokban ragadt aloldalt nem lehet indexelni, a tanúsítványhibás oldalt a látogatók nagy része elhagyja, a kettéhasadt www és nem-www változat pedig megosztja a hivatkozásokat és a mérési adatokat.
Az AI-válaszmotorok és a tartalmat lekérő ügynökök esetében a szakmai feltételezésem az, hogy a tolerancia még kisebb: ezek jellemzően egyszerű HTTP-klienssel dolgoznak, ritkábban követnek hosszú átirányítási láncot, és a hibás tanúsítványt sokszor egyszerűen hibaként kezelik, böngészős kivételkezelés nélkül. Egy tiszta SSL beállítás nem hoz látogatót önmagában, de a hiányzó SSL beállítás jó eséllyel el tud venni belőle.
Források és további olvasnivalók
- Google Search Central: HTTPS as a ranking signal, valamint a Site Moves with URL Changes dokumentáció
- Let's Encrypt hivatalos dokumentáció: Challenge Types és Certbot User Guide
- Mozilla Developer Network (MDN): Mixed content, Strict-Transport-Security
- MDN HTTP Observatory és a Mozilla SSL Configuration Generator
- Cloudflare Learning Center: SSL/TLS encryption modes
- W3C: Securing the Web (TAG finding)
- OWASP Cheat Sheet Series: Transport Layer Security
- A lakat ikon csak a kapcsolat titkosítását jelzi, nem azt, hogy az oldal minden eleme HTTPS-en tölt be.
- Egy oldalnak egyetlen kanonikus címe legyen: vagy www, vagy nem-www, és minden más változat egy lépésben oda irányítson.
- Az átirányítási hurok szinte mindig két rendszer (szerver és CMS vagy CDN) egymásnak feszülő szabályából ered.
- A lejárt tanúsítvány megelőzhető automatikus megújítással és független lejárat-figyeléssel, mert az automatizmus is el tud némulni.
- A HSTS erős védelem, de nehezen visszavonható, ezért csak stabil, teljesen HTTPS-re állt oldalon érdemes bekapcsolni.
Gyakori kérdések
Miért írja a böngésző, hogy nem biztonságos, ha a tanúsítvány érvényes?
Ilyenkor szinte biztosan vegyes tartalom van az oldalon: a lap HTTPS-en tölt be, de legalább egy beágyazott elem (kép, szkript, stíluslap, iframe) még http:// kezdetű hivatkozással szerepel. A böngésző konzoljában a mixed content figyelmeztetések megmutatják, pontosan melyik erőforrásról van szó.
Melyiket válasszam, a www-set vagy a www nélküli címet?
SEO szempontból nincs érdemi különbség, a lényeg a következetesség. Válaszd azt, amit a márkakommunikációban használsz, majd minden más változatot 301-es átirányítással vezess erre, és állítsd át ehhez a CMS beállításait, a sitemapet és a Search Console propertyt is.
Mit tegyek, ha az oldal átirányítási hurokba kerül a HTTPS bekapcsolása után?
Először nézd meg curl-lel, hova lép a kérés lépésről lépésre. A leggyakoribb ok, hogy egy proxy vagy CDN HTTPS-en fogadja a kérést, de HTTP-n adja tovább a szervernek, ami emiatt újra átirányít. A megoldás az X-Forwarded-Proto fejléc felismerése a CMS-ben, illetve az, hogy a HTTPS-átirányítás csak egyetlen rétegben éljen.
Hány naponta újul meg a tanúsítvány, és honnan tudom, ha elakadt?
A Let's Encrypt tanúsítványok 90 napig érvényesek, a megújítás jellemzően a lejárat előtt körülbelül 30 nappal indul. A certbot renew --dry-run paranccsal ellenőrizheted a folyamatot, de érdemes egy ettől független, naponta futó lejárat-figyelést is beállítani, mert az automatizmus hibája magától nem tűnik fel.
Kell-e HSTS-t beállítanom?
Hasznos, mert megszünteti az első kérésnél a HTTP-lépést és véd bizonyos támadástípusok ellen, de csak akkor kapcsold be, ha az oldal és az összes aldomain már stabilan fut HTTPS-en. Kezdd rövid max-age értékkel, és csak több napnyi hibátlan működés után emeld meg, illetve bővítsd aldomainekre.
Az SSL beállítás javítja a Google-helyezésemet?
A Google hivatalosan is megerősítette, hogy a HTTPS rangsorolási jel, de kis súllyal, tehát önmagában nem hoz jobb pozíciót és nem garantál semmit. A közvetett hatás fontosabb: a hurkok, a tanúsítványhibák és a párhuzamosan élő URL-változatok viszont valóban akadályozhatják az indexelést és megoszthatják a jeleket.
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.