Évente egyszer már nem elég: rövidül a HTTPS-tanúsítványok élettartama
A weboldalak HTTPS-tanúsítványa eddig legfeljebb 398 napig lehetett érvényes. Sokan évente egyszer, kézzel cserélték, és egy naptárbejegyzés elég volt hozzá. Ez a gyakorlat megszűnik.
Mi változott?
A tanúsítványokat kibocsátó cégek és a böngészőgyártók közös testülete, a CA/Browser Forum 2025 áprilisában elfogadta az SC-081 javaslatot. A menetrend a testület hatályos szabályzatában így áll:
| Kiállítás dátuma | Legfeljebb ennyi napig érvényes |
|---|
| 2026-03-15 előtt | 398 nap |
| 2026-03-15-től | 200 nap |
| 2027-03-15-től | 100 nap |
| 2029-03-15-től | 47 nap |
Az első lépés már él: a márciusi idő óta kiállított tanúsítványok legfeljebb 200 napig érvényesek. Évente tehát már legalább kétszer kell cserélni, 2029-től pedig nagyjából havonta.
Ugyanezzel a döntéssel rövidül az is, hogy a kibocsátó meddig használhatja újra a domain korábbi ellenőrzését: ma 200 nap, 2029-től 10 nap. Vagyis a domaint is egyre gyakrabban kell újra igazolni.
Mit jelent ez egy cégnek?
Ha a tanúsítvány lejár, a böngésző figyelmeztető oldalt mutat a látogatónak, és a legtöbben ott el is hagyják az oldalt. Ahol a cserét ma kézzel végzi valaki, ott ez a kockázat évről évre nő: két csere évente még kézben tartható, havi csere már nem.
Mit érdemes most megnézni?
- Automatikus-e a megújítás. A legtöbb tárhely és a Cloudflare ezt magától intézi, de érdemes megkérdezni a szolgáltatót vagy a fejlesztőt.
- Hol van még kézzel telepített tanúsítvány: aldomain, levelezőszerver, régi admin-felület.
- Van-e riasztás, ha egy tanúsítvány közel jár a lejárathoz.
A Secageo ingyenes mérése kívülről megnézi a weboldal tanúsítványát, és jelzi, ha 14 napon belül lejár.
Források
- CA/B Forum SC-081v3 szavazás (lezárva 2025-04-11; kibocsátók 25 igen / 0 nem / 5 tartózkodás, böngészők 4 igen): cabforum.org
- CA/B Forum Baseline Requirements 2.3.1 (2026-10-04), 1.2.2, 4.2.1 és 6.3.2 pont: cabforum.org
Nem elég a GPTBotot tiltani: így látogatja az OpenAI a weboldalát
Sok cég egyetlen sorral letiltotta a robots.txt-ben a „GPTBot”-ot, mondván: nem akarja, hogy a ChatGPT az ő tartalmán tanuljon. Az OpenAI dokumentációja szerint azonban több külön robot jár az oldalakra, és mindegyik mást csinál. Aki ezt nem tudja, könnyen mást tilt le, mint amit szeretne.
A három robot, ami számít
- GPTBot: olyan tartalmat gyűjt, amelyet az OpenAI a modelljei tanításához használhat. Az OpenAI szerint ha egy oldal tiltja, az azt jelenti, hogy a tartalma ne kerüljön a tanítóadatba.
- OAI-SearchBot: a ChatGPT keresőjének robotja. Az OpenAI szavaival: azok az oldalak, amelyek tiltják az OAI-SearchBotot, nem jelennek meg a ChatGPT keresési válaszaiban.
- ChatGPT-User: akkor jön, amikor egy felhasználó kéri meg a ChatGPT-t, hogy nyisson meg egy oldalt. Az OpenAI szerint nem gépiesen pásztázza a webet, és mivel felhasználói kérésre indul, a robots.txt szabályai nem feltétlenül vonatkoznak rá.
A dokumentáció egy negyediket is említ, az OAI-AdsBotot, amely a hirdetésként beküldött céloldalakat ellenőrzi.
Miért fontos ez?
A GPTBot és az OAI-SearchBot beállítása az OpenAI szerint független egymástól. Megengedheti az egyiket, és tilthatja a másikat. A leggyakoribb helyzet egy cégnél:
- nem akarja, hogy a tartalmán tanítsanak, ezért tiltja a GPTBotot,
- de szeretné, hogy a ChatGPT ajánlja, ha valaki a szolgáltatására keres, ezért engedi az OAI-SearchBotot.
Aki „minden OpenAI-robotot” tilt, az a keresési válaszokból is kizárja magát. Aki semmit nem állított be, annál mindhárom szabadon jár.
Mit érdemes most megnézni?
- Mi áll ma a robots.txt-ben a három névre.
- Szándékos-e: tanításból kimaradni és keresésben benne lenni, vagy fordítva.
- Ha a tárhely vagy a Cloudflare kínál „AI-robotok tiltása” kapcsolót, pontosan melyik robotokat érinti.
A Secageo ingyenes mérése kiolvassa a robots.txt-t, és megmutatja, hogy a GPTBot, az OAI-SearchBot és a ChatGPT-User engedélyezett vagy tiltott.
Aktívan kihasznált WordPress-hiba: frissült már az oldala?
A WordPress 2026. szeptember 22-én kritikus biztonsági javítást adott ki (CVE-2026-87902). Három nappal később az amerikai kiberbiztonsági hivatal, a CISA felvette a hibát az aktívan kihasznált sérülékenységek listájára. Ez azt jelenti, hogy már ténylegesen támadnak vele, nem csak elméleti veszély.
Miről szól a hiba?
A WordPress magjában, nem egy bővítményben van. A WordPress közleménye szerint egy bejelentkezés nélküli támadó rá tudja venni az oldalt, hogy a szerveren lévő más PHP-fájlt töltsön be. Bizonyos téma- és szerverbeállítások mellett ez a szerver átvételéig vezethet. A közlemény név szerint említ néhány érintett témát (a régi Twenty Twelve és Twenty Fourteen, valamint a Neve, a Hestia és a Sydney).
Kit érint?
A 4.7 és a 7.1.1 közötti WordPress-verziókat. A javítás a 7.1.2-ben jelent meg, és a WordPress minden régebbi ágra is kiadta, egészen a 4.7-ig (például 7.0.6, 6.9.9, 6.8.10).
Mit érdemes most megnézni?
- Melyik WordPress-verzió fut az oldalon. A vezérlőpult alján vagy a Frissítések menüben látszik.
- Ha az automatikus frissítés be van kapcsolva, valószínűleg már megtörtént, de érdemes ellenőrizni.
- Ha az oldalt egy ügynökség vagy külsős fejlesztő kezeli, kérdezze meg tőle, mikor frissített.
- Ha a frissítés hetekig elmaradt, kérje meg a fejlesztőt, hogy nézze át a szervert, mert a hiba már szeptember vége óta aktívan kihasznált.
A Secageo passzív mérése nem lép be az oldalra, és a WordPress-verziót sem állapítja meg. Azt viszont kívülről jelzi, ha a bejelentkező felület (például /wp-admin) bárki számára elérhető. Ez minden ilyen hibánál növeli a kockázatot.
Források
- CISA KEV katalógus (catalogVersion 2026.10.13), CVE-2026-87902 (dateAdded 2026-09-25, dueDate 2026-09-28, CWE-98): cisa.gov
- WordPress biztonsági közlemény GHSA-7hp8-65ch-5whp (2026-09-22, critical; javítva 7.1.2-ben, visszaportolva 4.7-ig): github.com