Lösenordet är dött. Är ditt nätverk redo att ersättas?
Er organisation har ägnat år åt att stänga ytterdörren: brandväggar, VPN, multifaktorautentisering, slutpunktsskydd. Men det finns en tystare fråga som många IT-team ännu inte har fått ett helt svar på: när en enhet, en server eller en tjänst försöker bevisa det är vem det säger att det är, vad stöder egentligen det påståendet?
För många organisationer är det ärliga svaret ”ett lösenord” eller ”en API-nyckel”. Och båda dessa kan stjälas, utnyttjas för nätfiske eller spelas upp av vem som helst som får tag på dem.
Det finns ett bättre svar, och det är ett som webbläsare och root-program nu i praktiken kräver: ett dedikerat klientautentiseringscertifikat.
Utforska alternativ för klientautentiseringscertifikat
Varför detta plötsligt är brådskande
Här är förändringen som orsakade problemet. Sedan den 15 juni 2026 kräver Chromes rotprogram nyligen utfärdade offentligt betrodda behörigheter. TLS servercertifikat för att endast inkludera serverAuth EKU. Mozilla, Apple och Microsoft har antagit kompatibla rotprogrampolicyer, vilket avslutar användningen av clientAuth EKU:er i offentligt betrodda TLS servercertifikat.
Om din organisation återanvände en standard TLS certifikat för att även hantera klientautentisering eller ömsesidigt TLS (mTLS), den genvägen fungerar inte längre. Alla certifikat med dubbla funktioner som fungerade som både server- och klientidentitet är inte längre giltiga för klientautentisering och måste ersättas med ett certifikat som är specifikt utformat för det ändamålet, vilket SSL tillhandahåller.
Alla organisationer som fortfarande förlitar sig på ett gammalt dubbelfunktionscertifikat uppfyller inte kraven idag, och exponeringen ökar bara ju längre det inte åtgärdas. Det påverkar alla som använder certifikatbaserad autentisering för mTLS, Nollförtroende-åtkomst, VPN, Wi-Fi-nätverksåtkomst, IoT-enheter, industriella styrsystem eller energimarknadsplattformar.
Vad ett klientautentiseringscertifikat faktiskt gör
Tänk på ditt vanliga TLS certifikat som din servers ID-bricka. Det bevisar att servern är den den utger sig för att vara när din webbläsare ansluter till den. Ett klientautentiseringscertifikat vänder på den konversationen. Det låter en enhet, användare, server eller tjänst bevisa sin egen identitet tillbaka till det den ansluter till.
Mekaniken spelar roll här, men bara på grund av vad den betyder för ditt företag. Den privata nyckeln genereras på själva enheten och lämnar den aldrig. En offentligt betrodd certifikatutfärdare (som SSL) signerar bara den offentliga nyckeln och binder den till en verifierad identitet. Det betyder att det inte finns något lösenord som ligger i en databas någonstans och väntar på att bli nätfiskat, ingen delad hemlighet som läcker vid ett intrång och ingen API-nyckel som kopierats till ett skript som någon glömt att rotera.
Återkallelse fungerar även per certifikat, inte per maskinpark. Om en bärbar dator förloras, en entreprenörs åtkomst upphör eller en enhet komprometteras, återkallar du det certifikatet och alla andra slutpunkter fortsätter att köras utan avbrott.
De viktigaste fördelarna, i korthet
Här är vad du faktiskt får genom att byta till ett dedikerat klientautentiseringscertifikat:
- Nätfiskeresistent identitet. Den privata nyckeln lämnar aldrig enheten, så det finns inget lösenord att stjäla, spela upp eller nätfiska.
- Kompatibel med Chrome och root-program. En dedikerad clientAuth EKU som uppfyller kraven för CA/Browser Forum och rotarkiv, så att du inte blir överraskad av policyändringen som startade allt detta.
- Offentligt betrodd hierarki. Utfärdad från SSL:s WebTrust-granskade publika PKI, utan behov av att distribuera en privat rot över din förlitande parts stack.
- Tre valideringsnivåer. IV, OV och IV+OV (Sponsor), så att autentiseringsuppgifterna matchar din identitetspolicy och eventuella myndighetskrav du arbetar under.
- Granulär återkallelse. Återkalla ett enda certifikat i det ögonblick en enhet förloras, tas ur bruk eller komprometteras, utan att påverka resten av din utrustningspark.
- API-först-utgivning. Problem i stor skala idag via SSL:s REST API, med ACME- och SCEP/EST-automatisering på gång.
Matcha autentiseringsuppgifterna med användningsfallet
Individuell validering (IV) bekräftar den verkliga identiteten för en namngiven person, vilket gör den till en naturlig lösning för anställdas enheter, BYOD-policyer och individuell slutpunktsåtkomst. Organisationsvalidering (OV) bekräftar ett företags juridiska existens, vilket är vad du vill ha för servrar, virtuella maskiner, servicekonton och API-klienter. Och för situationer där du behöver båda, till exempel privilegierade användare, entreprenörer eller reglerade branscher, finns IV+OV (Sponsorvalidering), som binder en individs identitet till den sponsrande organisationen samtidigt.
Den flexibiliteten är viktig eftersom klientautentisering dyker upp på fler ställen än de flesta inser:
|
Användningsfall |
Certifieringsnivå |
kompatibel med |
Anmärkningar |
|
mTLS / Noll förtroende |
OV / IV+OV |
Nginx, Envoy, Istio, Kong, AWS API GW |
Ömsesidigt TLSbåda peer-pe ... |
|
VPN (certifikatbaserat) |
IV / OV / IV+OV |
Cisco ASA/FTD, Palo Alto, Fortinet, Juniper SRX |
Eliminerar lösenordsbaserad VPN; nätfiskebeständig |
|
Wi-Fi (802.1X / EAP-TLS) |
IV / OV |
Cisco ISE, Aruba ClearPass, Microsoft NPS |
NAC-tillämpning; autentiseringsuppgifter på enheten, inte i ett lösenord |
|
IoT / Enhetsidentitet |
OV |
AWS IoT Core, Azure IoT Hub, anpassade mäklare |
Certifikat per enhet; individuell återkallelse utan att flasha om flottan |
|
OT / SCADA / ICS |
OV |
Claroty, Nozomi, Dragos; IEC 62443-medvetna stackar |
Autentiserar PLC:er, HMI:er och historiknoder på OT-nätverk |
|
NAESB Energimarknader |
IV+OV |
NAESB WEQ-12-kompatibla plattformar |
Obligatorisk behörighet för OATI, PowerSecure och andra EIS-plattformar |
|
API Gateway-autentisering |
OV / IV+OV |
Apigee, Kong, AWS API GW, Azure APIM |
Ersätter API-nycklar och JWT:er med certifikatbunden tjänstidentitet |
Utöver dessa specifika användningsfall fungerar certifikaten i stort sett över den infrastruktur som ditt team redan kör:
- TLS staplar: OpenSSL, BoringSSL, NSS, SChannel, SecureTransport, wolfSSL och mbedTLS.
- VPN och fjärråtkomst: Cisco AnyConnect/SecureClient, Palo Alto GlobalProtect, Fortinet FortiClient, OpenVPN och WireGuard (via extern autentisering).
- NAC och 802.1X: Cisco ISE, Aruba ClearPass, Microsoft NPS/RADIUS, FreeRADIUS och Juniper Access Control.
- API-gateways: Kong, Nginx, Envoy, Istio, AWS API Gateway (mTLS), Azure API-hantering och Apigee.
- ICS och OT: IEC 62443-kompatibla plattformar, inklusive lager för identifiering och autentisering av tillgångar i Claroty, Nozomi Networks och Dragos.
Att få certifikat ut genom dörren
Oavsett hur din organisation föredrar att utfärda certifikat, har SSL en lämplig sökväg:
|
Metod |
Vem det är för |
Så fungerar det |
|
Webbgränssnitt (ssl.com-instrumentpanel) |
IT-administratörer, mindre implementeringar, engångsutgivningar |
Logga in på ssl.com, välj Klientautentisering, välj valideringsnivå, slutför verifieringen, generera och ladda ner certifikatet. Ingen kodning krävs. |
|
REST API |
DevOps, CI/CD-pipelines, storskalig flottprovisionering |
Beställning av programmatiska certifikat, CSR inlämning och nedladdning via SSL:s dokumenterade REST API. Stöder massutgivning och integration med orkestreringsplattformar. |
|
ACME / SCEP / EST |
Enterprise MDM, IETF-standardautomation (planerad) |
Protokollbaserad livscykelautomation via ACME (RFC 8555), SCEP och EST (RFC 7030). Under utveckling – kontakta säljavdelningen för tidslinje och information om tidig åtkomst. |
Hur man köper
Klientautentiseringscertifikat är tillgängliga direkt från SSL utan minimikrav:
- Självbetjäning. Konfigurera och köp online.
- Företag och volym. Kontakta SSL-säljteamet för volymprissättning, dedikerad kontohantering och NAESB-specifik onboarding.
- Privat hierarki eller behov av dubbla EKU. Om du behöver en privat hierarki, en anpassad certifikatprofil eller ett dubbelt EKU-certifikat, SSL:s privata PKI produkter (Privata certifikat med hög säkerhet, dedikerade PKIoch Enterprise PKI) är rätt väg. Kontakta säljavdelningen för en rekommendation.
The Bottom Line
Ändringen av clientAuth EKU var inte bara en teknisk fotnot. Det var en tvingande funktion som tvingar organisationer att äntligen separera serveridentitet från klientidentitet, och att ersätta lösenord och API-nycklar med något som inte kan nätfiskas eller spelas upp igen.
SSL har drivit en WebTrust-granskad offentlig certifikatutfärdare i över 20 år, och klientautentiseringscertifikatet är den direkta, kompatibla vägen framåt för alla organisationer som behöver dedikerad klientidentitet i stor skala, oavsett om det handlar om att säkra ett Zero Trust-nätverk, en flotta av IoT-enheter eller en NAESB-reglerad handelsplattform.
Om du är osäker på om din nuvarande konfiguration fortfarande är beroende av ett dubbelfunktionscertifikat är det dags att kontrollera det nu. Datumet för tillämpning har redan passerat, så det är inte längre valfritt att täcka den luckan, men vi är redo att hjälpa till.
Är din mTLS påverkas av borttagningen av clientAuth EKU? Granska dina certifikat för clientAuth EKU och prata sedan med SSL om att migrera till dedikerade klientautentiseringscertifikat (eller privata PKI för interna behov / behov med dubbla EKU) innan dina nuvarande certifikat löper ut:
