Adgangskoden er død. Er dit netværk klar til at blive udskiftet?
Din organisation har brugt årevis på at lukke hoveddøren: firewalls, VPN'er, multifaktorgodkendelse, endpoint-beskyttelse. Men der er et mere stille spørgsmål, som mange IT-teams endnu ikke har besvaret fuldt ud: når en enhed, en server eller en tjeneste forsøger at bevise det er den, den siger, den er, hvad understøtter egentlig den påstand?
For mange organisationer er det ærlige svar "en adgangskode" eller "en API-nøgle". Og begge dele kan stjæles, phishes eller afspilles af alle, der får fat i dem.
Der er et bedre svar, og det er et som browsere og root-programmer nu effektivt kræver: et dedikeret klientgodkendelsescertifikat.
Udforsk muligheder for klientgodkendelsescertifikat
Hvorfor dette pludselig haster
Her er ændringen, der forårsagede problemet. Siden 15. juni 2026 kræver Chromes rodprogram nyligt udstedte, offentligt betroede certifikater TLS servercertifikater til kun at inkludere serverAuth EKU. Mozilla, Apple og Microsoft har indført kompatible rodprogrampolitikker, hvilket afslutter brugen af clientAuth EKU'er i offentligt betroede TLS servercertifikater.
Hvis din organisation genbrugte en standard TLS certifikat til også at håndtere klientgodkendelse eller gensidig TLS (mTLS), den genvej virker ikke længere. Ethvert dobbeltfunktionscertifikat, der fungerede som både server- og klientidentitet, er ikke længere gyldigt til klientgodkendelse og skal erstattes med et certifikat, der er bygget specifikt til dette formål, hvilket SSL leverer.
Enhver organisation, der stadig er afhængig af et gammelt dobbeltformålscertifikat, er allerede ude af overholdelse af reglerne i dag, og eksponeringen vokser kun, jo længere det ikke håndteres. Det påvirker alle, der bruger certifikatbaseret godkendelse til mTLS, Zero Trust-adgang, VPN'er, Wi-Fi-netværksadgang, IoT-enheder, industrielle kontrolsystemer eller energimarkedsplatforme.
Hvad et klientgodkendelsescertifikat rent faktisk gør
Tænk på dine regelmæssige TLS certifikat som din servers ID-badge. Det beviser, at serveren er den, den påstår at være, når din browser opretter forbindelse til den. Et klientgodkendelsescertifikat vender samtalen om. Det lader en enhed, bruger, server eller tjeneste bevise sin egen identitet tilbage til det, den opretter forbindelse til.
Mekanikken er vigtig her, men kun på grund af, hvad den betyder for din virksomhed. Den private nøgle genereres på selve enheden og forlader den aldrig. En offentligt betroet certifikatmyndighed (såsom SSL) signerer kun den offentlige nøgle og binder den til en verificeret identitet. Det betyder, at der ikke ligger nogen adgangskode et sted i en database, der venter på at blive phishet, ingen delt hemmelighed, der lækker ved et brud, og ingen API-nøgle kopieret ind i et script, som nogen glemte at rotere.
Tilbagekaldelse fungerer også pr. certifikat, ikke pr. flåde. Hvis en bærbar computer mistes, en entreprenørs adgang ophører, eller en enhed kompromitteres, tilbagekalder du det ene certifikat, og alle andre endpoints fortsætter med at køre uden afbrydelse.
De vigtigste fordele, et overblik
Her er hvad du rent faktisk får ved at skifte til et dedikeret klientgodkendelsescertifikat:
- Phishing-resistent identitet. Den private nøgle forlader aldrig enheden, så der er ingen adgangskode at stjæle, afspille eller phishe.
- Kompatibel med Chrome og root-programmer. En dedikeret clientAuth EKU, der opfylder kravene til CA/Browser Forum og root store, så du ikke bliver overrasket af den politikændring, der startede alt dette.
- Offentligt betroet hierarki. Udstedt fra SSL's WebTrust-reviderede offentlighed PKI, uden behov for at distribuere en privat rod på tværs af din reliating-party-stak.
- Tre valideringsniveauer. IV, OV og IV+OV (Sponsor), så legitimationsoplysningerne matcher din identitetspolitik og eventuelle lovgivningsmæssige krav, du arbejder under.
- Granulær tilbagekaldelse. Tilbagekald et enkelt certifikat i det øjeblik, en enhed mistes, tages ud af drift eller kompromitteres, uden at det påvirker resten af din flåde.
- API-første udstedelse. Problem i stor skala i dag via SSL's REST API, med ACME- og SCEP/EST-automatisering på vej.
Matchning af legitimationsoplysningerne med brugsscenariet
Individuel validering (IV) bekræfter den faktiske identitet af en navngiven person, hvilket gør den til et naturligt valg for medarbejderenheder, BYOD-politikker og individuel endpoint-adgang. Organisationsvalidering (OV) bekræfter en virksomheds juridiske eksistens, hvilket er det, du ønsker til servere, virtuelle maskiner, servicekonti og API-klienter. Og i situationer, hvor du har brug for begge dele, såsom privilegerede brugere, entreprenører eller regulerede brancher, er der IV+OV (Sponsorvalidering), som binder en persons identitet til den sponsorerende organisation på samme tid.
Den fleksibilitet er vigtig, fordi klientgodkendelse optræder flere steder, end de fleste er klar over:
|
Use Case |
Certificeret niveau |
Kompatibel med |
Noter |
|
mTLS / Nul tillid |
OV / IV+OV |
Nginx, Envoy, Istio, Kong, AWS API GW |
Gensidig TLSbegge peers autentificerer med X.509 |
|
VPN (certifikatbaseret) |
IV / OV / IV+OV |
Cisco ASA/FTD, Palo Alto, Fortinet, Juniper SRX |
Eliminerer adgangskodebaseret VPN; phishing-resistent |
|
Wi-Fi (802.1X / EAP-)TLS) |
IV / OV |
Cisco ISE, Aruba ClearPass, Microsoft NPS |
NAC-håndhævelse; legitimationsoplysninger på enheden, ikke i en adgangskode |
|
IoT / Enhedsidentitet |
OV |
AWS IoT Core, Azure IoT Hub, brugerdefinerede mæglere |
Certifikat pr. enhed; individuel tilbagekaldelse uden genindlæsning af flåden |
|
OT / SCADA / ICS |
OV |
Claroty, Nozomi, Dragos; IEC 62443-kompatible stakke |
Autentificerer PLC'er, HMI'er og historiknoder på OT-netværk |
|
NAESB Energimarkeder |
IV+OV |
NAESB WEQ-12 kompatible platforme |
Påkrævet legitimationsoplysninger til OATI, PowerSecure og andre EIS-platforme |
|
API Gateway-godkendelse |
OV / IV+OV |
Apigee, Kong, AWS API GW, Azure APIM |
Erstatter API-nøgler og JWT'er med cert-bundet tjenesteidentitet |
Ud over disse specifikke brugsscenarier fungerer certifikaterne bredt på tværs af den infrastruktur, dit team allerede kører:
- TLS stakke: OpenSSL, BoringSSL, NSS, SChannel, SecureTransport, wolfSSL og mbedTLS.
- VPN og fjernadgang: Cisco AnyConnect/SecureClient, Palo Alto GlobalProtect, Fortinet FortiClient, OpenVPN og WireGuard (via ekstern godkendelse).
- NAC og 802.1X: Cisco ISE, Aruba ClearPass, Microsoft NPS/RADIUS, FreeRADIUS og Juniper Access Control.
- API-gateways: Kong, Nginx, Envoy, Istio, AWS API Gateway (mTLS), Azure API-administration og Apigee.
- ICS og OT: IEC 62443-kompatible platforme, herunder lagene til registrering og godkendelse af aktiver i Claroty, Nozomi Networks og Dragos.
Få certifikater ud af døren
Uanset hvordan din organisation foretrækker at udstede certifikater, har SSL en sti, der passer til:
|
Metode |
Hvem det er til |
Hvordan det virker |
|
Webgrænseflade (ssl.com Dashboard) |
IT-administratorer, mindre implementeringer, engangsudstedelse |
Log ind på ssl.com, vælg Klientgodkendelse, vælg valideringsniveau, fuldfør verifikationen, generer og download certifikatet. Ingen kodning kræves. |
|
REST-API |
DevOps, CI/CD-pipelines, storstilet flådeforsyning |
Bestilling af programmatiske certifikater, CSR indsendelse og download via SSL's dokumenterede REST API. Understøtter masseudstedelse og integration med orkestreringsplatforme. |
|
ACME / SCEP / EST |
Enterprise MDM, IETF-standard automatisering (planlagt) |
Protokolbaseret livscyklusautomatisering via ACME (RFC 8555), SCEP og EST (RFC 7030). Under udvikling — kontakt salg for tidslinje og oplysninger om tidlig adgang. |
Sådan køber
Klientgodkendelsescertifikater er tilgængelige direkte fra SSL uden minimumsforpligtelser:
- Selvbetjening. Konfigurer og køb online.
- Virksomhed og volumen. Kontakt SSL-salgsteamet til volumenprissætning, dedikeret kontoadministration og NAESB-specifik onboarding.
- Privat hierarki eller behov for dobbelt EKU. Hvis du har brug for et privat hierarki, en brugerdefineret certifikatprofil eller et dobbelt EKU-certifikat, SSL's private PKI produkter (Private certifikater med høj sikkerhed, dedikerede PKIog Enterprise PKI) er den korrekte vej. Kontakt salg for at få en henvisning.
The Bottom Line
Ændringen af clientAuth EKU var ikke bare en teknisk fodnote. Det var en tvangsfunktion, der presser organisationer til endelig at adskille serveridentitet fra klientidentitet og erstatte adgangskoder og API-nøgler med noget, der ikke kan phishes eller afspilles igen.
SSL har drevet en WebTrust-revideret offentlig certifikatmyndighed i over 20 år, og klientgodkendelsescertifikatet er den direkte, kompatible vej frem for enhver organisation, der har brug for dedikeret klientidentitet i stor skala, uanset om det drejer sig om at sikre et Zero Trust-netværk, en flåde af IoT-enheder eller en NAESB-reguleret handelsplatform.
Hvis du ikke er sikker på, om din nuværende opsætning stadig er afhængig af et dobbeltfunktionscertifikat, er det nu, du skal tjekke. Håndhævelsesdatoen er allerede overskredet, så det er ikke længere valgfrit at lukke dette hul, men vi er klar til at hjælpe.
Er din mTLS påvirket af fjernelsen af clientAuth EKU? Undersøg dine certifikater for clientAuth EKU, og tal derefter med SSL om migrering til dedikerede klientgodkendelsescertifikater (eller private PKI kun til interne behov / dobbelt-EKU) før dine nuværende certifikater udløber:
