A jelszó érvénytelen. Készen áll a hálózatod a cseréjére?
A szervezete évek óta zárva tartja a bejárati ajtót: tűzfalak, VPN-ek, többtényezős hitelesítés, végpontvédelem. De van egy csendesebb kérdés, amelyre sok IT-csapat még nem adott teljes választ: amikor egy eszköz, egy szerver vagy egy szolgáltatás megpróbálja bizonyítani... az, akinek mondja magát, mi támasztja alá ezt az állítást valójában?
Sok szervezet számára az őszinte válasz a „jelszó” vagy az „API-kulcs”. Mindkettőt ellophatják, adathalászhatnak vagy visszajátszhatják bárki, aki a kezébe kerül.
Van egy jobb válasz, és ezt a böngészők és a root programok most már gyakorlatilag megkövetelik: egy dedikált kliens-hitelesítési tanúsítványt.
Klienshitelesítési tanúsítvány lehetőségeinek felfedezése
Miért lett ez hirtelen sürgős?
Íme a változás, ami a problémát kiváltotta. 2026. június 15. óta a Chrome root programja újonnan kiadott, nyilvánosan megbízható tanúsítványokat igényel. TLS szervertanúsítványok, amelyek csak a serverAuth EKU-t tartalmazzák. A Mozilla, az Apple és a Microsoft kompatibilis root programszabályzatokat fogadott el, megszüntetve a clientAuth EKU-k használatát nyilvánosan megbízható rendszerekben. TLS szerver tanúsítványok.
Ha a szervezete újrahasznosított egy szabványt TLS tanúsítvány az ügyfél-hitelesítés kezelésére is, vagy kölcsönös TLS (mTLS), ez a gyorsbillentyű már nem működik. Bármely kettős célú tanúsítvány, amely szerver- és kliensazonosítóként is szolgált, már nem érvényes klienshitelesítésre, és egy kifejezetten erre a célra létrehozott tanúsítvánnyal kell helyettesíteni, amelyet az SSL biztosít.
Bármely szervezet, amely még mindig egy régi, kettős célú tanúsítványra támaszkodik, már ma sem felel meg a követelményeknek, és a kockázat csak nő, minél tovább nem kezelik a problémát. Ez mindenkit érint, aki tanúsítványalapú hitelesítést használ mTLS, Zero Trust hozzáférés, VPN-ek, Wi-Fi hálózati hozzáférés, IoT-eszközök, ipari vezérlőrendszerek vagy energiapiaci platformok.
Mit csinál valójában egy klienshitelesítési tanúsítvány?
Gondolj a szokásos TLS tanúsítványt a szerver azonosító jelvényeként. Ez igazolja, hogy a szerver valóban az, akinek állítja magát, amikor a böngésző csatlakozik hozzá. Egy kliens-hitelesítési tanúsítvány megfordítja ezt a párbeszédet. Lehetővé teszi egy eszköz, felhasználó, szerver vagy szolgáltatás számára, hogy igazolja saját identitását bármihez is csatlakozik.
A mechanika itt fontos, de csak azért, mert mit jelent az Ön vállalkozása számára. A privát kulcs magán az eszközön generálódik, és soha nem hagyja el azt. Egy nyilvánosan megbízható hitelesítésszolgáltató (mint például az SSL) csak a nyilvános kulcsot írja alá, és egy ellenőrzött személyazonossághoz köti. Ez azt jelenti, hogy nincs valahol egy adatbázisban adathalászatra váró jelszó, nincs megosztott titok, ami kiszivároghat egy incidens során, és nincs API-kulcs, amelyet egy olyan szkriptbe másoltak, amelyet valaki elfelejtett cserélni.
A visszavonás tanúsítványonként is működik, nem pedig flottánként. Ha egy laptop elveszik, egy vállalkozó hozzáférése megszűnik, vagy egy eszköz veszélybe kerül, Ön visszavonja ezt az egy tanúsítványt, és minden más végpont megszakítás nélkül tovább működik.
A legfontosabb előnyök áttekintése
A dedikált kliens-hitelesítési tanúsítványra való váltás a következőket eredményezi:
- Adathalászattal szemben ellenálló identitás. A privát kulcs soha nem hagyja el az eszközt, így nincs jelszó, amit el lehetne lopni, vissza lehetne játszani vagy adathalászni.
- Chrome és root programok kompatibilisek. Egy dedikált clientAuth EKU, amely megfelel a CA/Browser Forum és a root tároló követelményeinek, így nem kell lemaradnod a szabályzatváltozásról, ami mindezt elindította.
- Nyilvánosan megbízható hierarchia. Az SSL WebTrust által auditált nyilvános forrásaiból kiadva PKI, anélkül, hogy privát gyökeret kellene elosztani a függő entitás veremében.
- Három érvényesítési szint. IV, OV és IV+OV (szponzor), így a hitelesítő adat megfelel az identitáspolitikádnak és az esetleges szabályozási követelményeknek, amelyek alatt dolgozol.
- Részletes visszavonás. Egyetlen tanúsítvány visszavonása azonnal, amint egy eszköz elveszik, leszereli vagy veszélybe kerül, anélkül, hogy a flotta többi eszközét érintené.
- API-első kibocsátás. A probléma ma nagy léptékben kerül bevezetésre az SSL REST API-ján keresztül, az ACME és a SCEP/EST automatizálás pedig hamarosan elérhető lesz.
A hitelesítő adat és a használati eset összehangolása
Az egyéni validáció (IV) megerősíti a megnevezett személy valódi kilétét, ami természetessé teszi az alkalmazottak eszközeihez, a BYOD-szabályzatokhoz és az egyéni végpontok eléréséhez. A szervezeti validáció (OV) megerősíti a vállalat jogi létezését, amire szükség van szerverek, virtuális gépek, szolgáltatásfiókok és API-kliensek esetében. Azokban az esetekben, amikor mindkettőre szükség van, például privilegizált felhasználók, alvállalkozók vagy szabályozott iparágak esetén, létezik az IV+OV (szponzori validáció), amely egyszerre köti az egyén kilétét a szponzoráló szervezethez.
Ez a rugalmasság azért fontos, mert az ügyfél-hitelesítés több helyen jelenik meg, mint azt a legtöbb ember gondolná:
|
Használja az ügyet |
Tanúsítvány szintje |
Kompatibilis |
Megjegyzések |
|
mTLS / Nulla bizalom |
OV / IV+OV |
Nginx, Envoy, Istio, Kong, AWS API GW |
Kölcsönös TLSmindkét fél X.509-cel hitelesíti magát |
|
VPN (tanúsítványalapú) |
IV / OV / IV+OV |
Cisco ASA/FTD, Palo Alto, Fortinet, Juniper SRX |
Kiküszöböli a jelszóalapú VPN-t; adathalászat-biztos |
|
Wi-Fi (802.1X / EAP-)TLS) |
IV. / OV. |
Cisco ISE, Aruba ClearPass, Microsoft NPS |
NAC-érvényesítés; hitelesítő adatok az eszközön, nem jelszóban |
|
IoT / Eszközazonosítás |
OV |
AWS IoT Core, Azure IoT Hub, egyéni brókerek |
Eszközönkénti tanúsítvány; egyedi visszavonás a flotta újraflashelése nélkül |
|
OT / SCADA / ICS |
OV |
Claroty, Nozomi, Dragos; IEC 62443-kompatibilis rendszerek |
Hitelesíti a PLC-ket, HMI-ket és történeti csomópontokat OT hálózatokon |
|
NAESB Energiapiacok |
IV+OV |
NAESB WEQ-12 kompatibilis platformok |
Szükséges hitelesítő adatok az OATI, PowerSecure és más EIS platformokhoz |
|
API átjáró hitelesítése |
OV / IV+OV |
Apigee, Kong, AWS API GW, Azure APIM |
API-kulcsokat és JWT-ket cserél le tanúsítványhoz kötött szolgáltatásidentitással |
Ezen konkrét felhasználási eseteken túl a tanúsítványok széles körben működnek a csapatod által már üzemeltetett infrastruktúrában:
- TLS halmok: OpenSSL, BoringSSL, NSS, SChannel, SecureTransport, wolfSSL és mbedTLS.
- VPN és távoli hozzáférés: Cisco AnyConnect/SecureClient, Palo Alto GlobalProtect, Fortinet FortiClient, OpenVPN és WireGuard (külső hitelesítésen keresztül).
- NAC és 802.1X: Cisco ISE, Aruba ClearPass, Microsoft NPS/RADIUS, FreeRADIUS és Juniper Access Control.
- API átjárók: Kong, Nginx, Envoy, Istio, AWS API átjáró (mTLS), az Azure API Management és az Apigee.
- ICS és OT: IEC 62443 szabványt támogató platformok, beleértve a Claroty, a Nozomi Networks és a Dragos eszközfelderítési és hitelesítési rétegeit.
Tanúsítványok kijuttatása az ajtón
Akárhogy is szeretné a szervezete tanúsítványokat kibocsátani, az SSL-nek van egy elérési útja, amely illeszkedik:
|
Módszer |
Kinek szól |
Hogyan működik |
|
Webes felhasználói felület (ssl.com irányítópult) |
IT-adminisztrátorok, kisebb telepítések, egyszeri kiadás |
Jelentkezzen be az ssl.com oldalra, válassza ki a Klienshitelesítés lehetőséget, válassza ki az érvényesítési szintet, fejezze be az ellenőrzést, majd generálja és töltse le a tanúsítványt. Nincs szükség kódolásra. |
|
REST API |
DevOps, CI/CD folyamatok, nagyméretű flotta kiépítése |
Programozott tanúsítványrendelés, CSR beküldés és letöltés az SSL dokumentált REST API-ján keresztül. Támogatja a tömeges kibocsátást és az integrációt az orchestrációs platformokkal. |
|
ACME / SCEP / EST |
Vállalati MDM, IETF-szabványú automatizálás (tervezett) |
Protokoll alapú életciklus-automatizálás ACME (RFC 8555), SCEP és EST (RFC 7030) szabványokon keresztül. Fejlesztés alatt – az ütemtervvel és a korai hozzáféréssel kapcsolatos részletekért forduljon az értékesítési csapathoz. |
Vásárlás
Az ügyfél-hitelesítési tanúsítványok közvetlenül az SSL-től érhetők el, minimális kötelezettségvállalás nélkül:
- Önkiszolgáló. Konfigurálás és vásárlás online.
- Vállalat és mennyiség. Lépjen kapcsolatba az SSL értékesítési csapatával mennyiségi árképzéshez, dedikált ügyfélkezeléshez és NAESB-specifikus bevezetés.
- Privát hierarchiára vagy kettős EKU-ra van szükség. Ha privát hierarchiára, egyéni tanúsítványprofilra vagy kettős EKU-tanúsítványra van szüksége, SSL-ek privátak PKI termékek (Nagy biztonságú magántanúsítványok, dedikált PKIés Enterprise PKI) a helyes útvonal. Ajánlásért forduljon az értékesítési csapathoz.
A lényeg
A clientAuth EKU módosítása nem csupán egy technikai lábjegyzet volt. Egy kényszerítő függvény, amely arra ösztönzi a szervezeteket, hogy végre válasszák szét a szerver identitását az ügyfél identitásával, és a jelszavakat és API-kulcsokat olyannal helyettesítsék, amelyet nem lehet adathalászni vagy visszajátszani.
Az SSL több mint 20 éve üzemeltet egy WebTrust által auditált nyilvános hitelesítésszolgáltatót, és az ügyfél-hitelesítési tanúsítvány a közvetlen, megfelelő utat jelenti minden olyan szervezet számára, amelynek dedikált ügyfél-identitásra van szüksége nagy léptékben, legyen szó akár egy zéró bizalom hálózat, egy IoT-eszközflotta vagy egy NAESB által szabályozott kereskedési platform biztonságáról.
Ha nem biztos benne, hogy jelenlegi rendszere továbbra is kettős célú tanúsítványra támaszkodik-e, itt az ideje ellenőrizni. A hatálybalépési dátum már lejárt, így a hiányosság megszüntetése már nem opcionális, de mi készen állunk segíteni.
Az m-ed?TLS érinti a clientAuth EKU eltávolítása? Vizsgálja meg a clientAuth EKU tanúsítványait, majd beszéljen az SSL-lel a dedikált klienshitelesítési tanúsítványokra (vagy privát tanúsítványokra) való migrálásról. PKI (csak belső használatra / kettős EKU igények esetén) a jelenlegi tanúsítványok lejárta előtt:
