Passordet er dødt. Er nettverket ditt klart for en erstatning?
Organisasjonen din har brukt årevis på å stenge døren: brannmurer, VPN-er, flerfaktorautentisering, endepunktbeskyttelse. Men det finnes et mer stille spørsmål som mange IT-team ikke har fått fullt svar på ennå: når en enhet, en server eller en tjeneste prøver å bevise det er den den sier den er, hva støtter egentlig den påstanden?
For mange organisasjoner er det ærlige svaret «et passord» eller «en API-nøkkel». Og begge disse kan stjeles, phishes eller spilles av på nytt av alle som får tak i dem.
Det finnes et bedre svar, og det er et som nettlesere og rotprogrammer nå effektivt krever: et dedikert klientautentiseringssertifikat.
Utforsk alternativer for klientgodkjenningssertifikat
Hvorfor dette plutselig haster
Her er endringen som forårsaket problemet. Siden 15. juni 2026 krever Chromes rotprogram nylig utstedte, offentlig klarerte TLS serversertifikater til kun å inkludere serverAuth EKU. Mozilla, Apple og Microsoft har tatt i bruk kompatible rotprogrampolicyer, og dermed avsluttet bruken av clientAuth EKU-er i offentlig klarerte TLS serversertifikater.
Hvis organisasjonen din gjenbrukte en standard TLS sertifikat for også å håndtere klientgodkjenning eller gjensidig TLS (mTLS), den snarveien fungerer ikke lenger. Ethvert dobbeltfunksjonssertifikat som fungerte som både server- og klientidentitet, er ikke lenger gyldig for klientgodkjenning og må erstattes med et sertifikat som er spesielt bygget for det formålet, som SSL tilbyr.
Enhver organisasjon som fortsatt er avhengig av et gammelt dobbeltformålssertifikat, er allerede ute av samsvar med regelverket i dag, og eksponeringen øker bare jo lenger det ikke håndteres. Det påvirker alle som bruker sertifikatbasert autentisering til mTLS, Nulltillits-tilgang, VPN-er, Wi-Fi-nettverkstilgang, IoT-enheter, industrielle kontrollsystemer eller energimarkedsplattformer.
Hva et klientautentiseringssertifikat egentlig gjør
Tenk på din vanlige TLS sertifikatet som serverens ID-merke. Det beviser at serveren er den den utgir seg for å være når nettleseren din kobler seg til den. Et klientautentiseringssertifikat snur den samtalen på hodet. Det lar en enhet, bruker, server eller tjeneste bevise sin egen identitet tilbake til det den kobler seg til.
Mekanikken er viktig her, men bare på grunn av hva den betyr for bedriften din. Den private nøkkelen genereres på selve enheten og forlater den aldri. En offentlig betrodd sertifiseringsinstans (som SSL) signerer bare den offentlige nøkkelen og binder den til en bekreftet identitet. Det betyr at det ikke finnes noe passord i en database et sted som venter på å bli phishet, ingen delt hemmelighet som lekker ved et sikkerhetsbrudd, og ingen API-nøkkel kopiert inn i et skript som noen glemte å rotere.
Tilbakekalling fungerer også per sertifikat, ikke per flåte. Hvis en bærbar PC går tapt, en entreprenørs tilgang avsluttes, eller en enhet kompromitteres, tilbakekaller du det ene sertifikatet, og alle andre endepunkter fortsetter å kjøre uten avbrudd.
De viktigste fordelene, på et øyeblikk
Her er hva du faktisk får ut av å bytte til et dedikert klientautentiseringssertifikat:
- Phishing-resistent identitet. Den private nøkkelen forlater aldri enheten, så det finnes ikke noe passord å stjele, spille av igjen eller phishe.
- Kompatibel med Chrome og root-programmer. En dedikert clientAuth EKU som oppfyller kravene til CA/Browser Forum og rotlager, slik at du ikke blir overrasket av policyendringen som startet alt dette.
- Offentlig klarert hierarki. Utstedt fra SSLs WebTrust-reviderte offentlighet PKI, uten behov for å distribuere en privat rot på tvers av den pålitelige partsstakken din.
- Tre valideringsnivåer. IV, OV og IV+OV (Sponsor), slik at legitimasjonen samsvarer med identitetspolicyen din og eventuelle regulatoriske krav du jobber under.
- Granulær tilbakekalling. Tilbakekall et enkelt sertifikat i det øyeblikket en enhet går tapt, ut av drift eller blir kompromittert, uten å berøre resten av verktøyparken din.
- API-første utstedelse. Problem i stor skala i dag gjennom SSLs REST API, med ACME- og SCEP/EST-automatisering på vei.
Matche legitimasjonen med brukstilfellet
Individuell validering (IV) bekrefter den virkelige identiteten til en navngitt person, noe som gjør den naturlig for ansattes enheter, BYOD-policyer og individuell endepunkttilgang. Organisasjonsvalidering (OV) bekrefter den juridiske eksistensen til et selskap, som er det du ønsker for servere, virtuelle maskiner, tjenestekontoer og API-klienter. Og for situasjoner der du trenger begge deler, for eksempel privilegerte brukere, kontraktører eller regulerte bransjer, finnes det IV+OV (Sponsorvalidering), som binder en persons identitet til den sponsende organisasjonen samtidig.
Den fleksibiliteten er viktig fordi klientautentisering dukker opp flere steder enn folk flest er klar over:
|
Bruk sak |
Sertifikatnivå |
kompatibel med |
Merknader |
|
mTLS / Null tillit |
OV / IV+OV |
Nginx, Envoy, Istio, Kong, AWS API GW |
Gjensidig TLSbegge motpartene autentiserer med X.509 |
|
VPN (sertifikatbasert) |
IV / OV / IV+OV |
Cisco ASA/FTD, Palo Alto, Fortinet, Juniper SRX |
Eliminerer passordbasert VPN; phishing-resistent |
|
Wi-Fi (802.1X / EAP-TLS) |
IV / OV |
Cisco ISE, Aruba ClearPass, Microsoft NPS |
NAC-håndhevelse; legitimasjon på enheten, ikke i et passord |
|
IoT / Enhetsidentitet |
OV |
AWS IoT Core, Azure IoT Hub, tilpassede meglere |
Sertifikat per enhet; individuell tilbakekalling uten å flashe flåten på nytt |
|
OT / SCADA / ICS |
OV |
Claroty, Nozomi, Dragos; IEC 62443-kompatible stabler |
Autentiserer PLS-er, HMI-er og historikknoder på OT-nettverk |
|
NAESB Energimarkeder |
IV+OV |
NAESB WEQ-12-kompatible plattformer |
Nødvendig legitimasjon for OATI, PowerSecure og andre EIS-plattformer |
|
API Gateway-autentisering |
OV / IV+OV |
Apigee, Kong, AWS API GW, Azure APIM |
Erstatter API-nøkler og JWT-er med sertifisert tjenesteidentitet |
I tillegg til disse spesifikke brukstilfellene fungerer sertifikatene bredt på tvers av infrastrukturen teamet ditt allerede kjører:
- TLS stabler: OpenSSL, BoringSSL, NSS, SChannel, SecureTransport, wolfSSL og mbedTLS.
- VPN og fjerntilgang: Cisco AnyConnect/SecureClient, Palo Alto GlobalProtect, Fortinet FortiClient, OpenVPN og WireGuard (via ekstern autentisering).
- NAC og 802.1X: Cisco ISE, Aruba ClearPass, Microsoft NPS/RADIUS, FreeRADIUS og Juniper Access Control.
- API-porter: Kong, Nginx, Envoy, Istio, AWS API-gateway (mTLS), Azure API-administrasjon og Apigee.
- ICS og OT: IEC 62443-kompatible plattformer, inkludert lagene for aktivaoppdagelse og autentisering i Claroty, Nozomi Networks og Dragos.
Å få sertifikater ut døren
Uansett hvordan organisasjonen din foretrekker å utstede sertifikater, har SSL en bane som passer:
|
Metode |
Hvem det er for |
Slik fungerer det |
|
Nettgrensesnitt (ssl.com-dashbord) |
IT-administratorer, mindre implementeringer, engangsutstedelse |
Logg inn på ssl.com, velg Klientautentisering, velg valideringsnivå, fullfør verifiseringen, generer og last ned sertifikatet. Ingen koding nødvendig. |
|
REST API |
DevOps, CI/CD-pipelines, storskala flåteklargjøring |
Bestilling av programmatiske sertifikater, CSR innsending og nedlasting via SSLs dokumenterte REST API. Støtter masseutstedelse og integrasjon med orkestreringsplattformer. |
|
ACME / SCEP / EST |
Enterprise MDM, IETF-standard automatisering (planlagt) |
Protokollbasert livssyklusautomatisering via ACME (RFC 8555), SCEP og EST (RFC 7030). Under utvikling – kontakt salg for tidslinje og detaljer om tidlig tilgang. |
Hvordan kjøpe
Klientautentiseringssertifikater er tilgjengelige direkte fra SSL uten minimumsforpliktelse:
- Selvbetjening. Konfigurer og kjøp på nett.
- Bedrift og volum. Kontakt SSL-salgsteamet for volumprising, dedikert kontoadministrasjon og NAESB-spesifikk onboarding.
- Privat hierarki eller behov for dobbel EKU. Hvis du trenger et privat hierarki, en tilpasset sertifikatprofil eller et dobbelt EKU-sertifikat, SSLs private PKI produktene (Private sertifikater med høy sikkerhet, dedikerte PKIog Enterprise PKI) er riktig vei. Kontakt salg for en henvisning.
Bunnlinjen
Endringen i clientAuth EKU var ikke bare en teknisk fotnote. Det var en tvangsfunksjon som presser organisasjoner til endelig å skille serveridentitet fra klientidentitet, og erstatte passord og API-nøkler med noe som ikke kan phishes eller spilles av på nytt.
SSL har drevet en WebTrust-revidert offentlig sertifikatmyndighet i over 20 år, og klientautentiseringssertifikatet er den direkte, kompatible veien videre for enhver organisasjon som trenger dedikert klientidentitet i stor skala, enten det er å sikre et nulltillitsnettverk, en flåte av IoT-enheter eller en NAESB-regulert handelsplattform.
Hvis du er usikker på om ditt nåværende oppsett fortsatt er avhengig av et dobbeltfunksjonssertifikat, er det nå på tide å sjekke. Håndhevelsesdatoen er allerede over, så det er ikke lenger valgfritt å lukke dette gapet, men vi er klare til å hjelpe.
Er din mTLS påvirket av fjerningen av clientAuth EKU? Kontroller sertifikatene dine for clientAuth EKU, og snakk deretter med SSL om migrering til dedikerte klientgodkjenningssertifikater (eller private PKI kun for interne behov / dobbel EKU) før dine nåværende sertifikater utløper:
