S Secageo

Hírek

É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átumaLegfeljebb ennyi napig érvényes
2026-03-15 előtt398 nap
2026-03-15-től200 nap
2027-03-15-től100 nap
2029-03-15-től47 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?

  1. 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.
  2. Hol van még kézzel telepített tanúsítvány: aldomain, levelezőszerver, régi admin-felület.
  3. 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?

  1. Mi áll ma a robots.txt-ben a három névre.
  2. Szándékos-e: tanításból kimaradni és keresésben benne lenni, vagy fordítva.
  3. 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.

Források

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?

  1. Melyik WordPress-verzió fut az oldalon. A vezérlőpult alján vagy a Frissítések menüben látszik.
  2. Ha az automatikus frissítés be van kapcsolva, valószínűleg már megtörtént, de érdemes ellenőrizni.
  3. Ha az oldalt egy ügynökség vagy külsős fejlesztő kezeli, kérdezze meg tőle, mikor frissített.
  4. 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