Borttagning av klientautentiserings-EKU från TLS Servercertifikat – Vad du behöver veta

Relaterat innehåll

Vill du fortsätta lära dig?

Prenumerera på SSL.coms nyhetsbrev, håll dig informerad och säker.

Översikt

Sedan 15 september 2025, SSL.coms TLS servercertifikat har utfärdats utan tillägget Client Authentication Extended Key Usage (EKU). Denna ändring styrdes av Google Chrome Root Program PolicyHär förklarar vi vad EKU:er är, varför denna ändring inträffade, hur den påverkar servermiljöer och vilka åtgärder du kan behöva vidta. Vi tillhandahåller även vanliga frågor och teknisk vägledning för olika scenarier.

Uppdatering: Borttagningen av clientAuth EKU är ett krav från CA/Browser Forum, inte en ändring som endast gäller för Chrome. Stora offentliga certifikatutfärdare, inklusive SSL.com, har tagit bort clientAuth EKU från nya och förnyade certifikat. TLS servercertifikat sedan slutet av 2025, och Chrome Root-programmets slutgiltiga deadline för denna borttagning är den 15 mars 2027. Om dina system är beroende av clientAuth EKU för ömsesidig TLS, VPN-autentisering eller ett liknande användningsfall, planera att flytta det användningsfallet till ett dedikerat klientautentiseringscertifikat innan dina nuvarande certifikat förnyas. Certifikat som utfärdats före varje certifikatutfärdares slutdatum fortsätter att fungera tills de löper ut.

Om du använder ClientAuth i någon av dina TLS servercertifikat, uppmuntrar vi dig att kontakta vårt team så att vi kan arbeta tillsammans för att hitta den bästa lösningen för din organisation.

Vad är Extended Key Usages (EKU)? 

Extended Key Usage (EKU), är en certifikattillägg som definierar den avsedda funktionen för en offentlig nyckel i ett digitalt certifikat. Den upprättar en strukturerad uppsättning tillåtna applikationer, vilket säkerställer att nyckeln endast används för specifika kryptografiska operationer. Denna funktion styrs av Objektidentifierare (OID)– unika numeriska identifierare som kategoriserar varje tillåten användning, såsom kodsignering, serverautentisering, klientautentisering eller säker e-post. När autentiseringen är certifikatbaserad granskar den verifierande enheten certifikatet för att identifiera objektidentifieraren (OID) inom EKU. Genom att bädda in EKU-förlängningen, en Certifikatmyndighet (CA) begränsar certifikatets omfattning till fördefinierade roller, med varje angett syfte explicit mappat till en OID. 

Till exempel: 

  • TLS Webbserverautentisering – Indikerar att certifikatet kan användas för att autentisera en server (t.ex. en HTTPS-webbplats). OID som motsvarar serverautentisering är 1.3.6.1.5.5.7.3.1 
  • TLS Webklientautentisering – Indikerar att certifikatet kan användas av en klient för att autentisera till en server (t.ex. ett klientcertifikat för ömsesidigt TLS). OID som tilldelats klientautentisering är 1.3.6.1.5.5.7.3.2 

Webbläsare och servrar behöver bara serverAuth EKU till etablera en säker anslutning för HTTPS men historiskt många TLS servercertifikat inkluderade både serverAuth och clientAuth EKU:er.  Nedan är ett exempel på ett sådant intyg:

Vad är happening? 

Från september 15, 2025 SSL.com kommer fråga TLS certifikat som endast innehåller serverAuth EKU (Och inte clientAuth) för servercertifikat. Med andra ord, ny SSL/TLS certifikat för din webbplats eller server kommer uttryckligen endast att vara för "Serverautentisering". 

Varför ta bort clientAuth EKU från servercertifikat? 

Det finns flera skäl till detta uppdrag: 

  • Säkerhet och omfattning: offentliga TLS certifikat är ska endast autentisera servrar på webben. Borttagningen ger en tydlig åtskillnad mellan server- och klientfunktionalitet. ClientAuth EKU används för autentisering av maskiner och användare med Mutual TLS (mTLS) och andra autentiseringsscenarier. 
  • Förhindra felkonfiguration: Vissa system kan lita på vilken som helst certifikat från en offentlig CA för klientautentisering om EKU finns, vilket kan vara en säkerhetsrisk. 
  • Webbläsarkrav: Större webbläsare kräver eller kontrollerar inte clientAuth EKU i en webbplatss certifikat.  
  • förenklade PKI Arkitektur: Genom att separera användningar kan CA:er upprätthålla distinkta certifikathierarkier för servern TLS kontra andra syften. 

Branschefterlevnad 

Denna policyändring är ett krav från CA/Browser Forum som fasas in i hela branschen, där Chrome Root Program har satt den slutgiltiga deadline för tillämpning till den 15 mars 2027 för TLS servercertifikat.

Inverkan på servermiljöer 

För de allra flesta serverdistributioner kommer denna förändring att vara liten påverkan or ingen inverkan. Här är vad du kan förvänta dig: 

  • Standard webbservrar (HTTPS): Ingen påverkan. De uppdaterade certifikaten kommer att fortsätta att fungera normalt. 
  • Befintliga certifikat: Eventuellt utfärdat certifikat innan cutoff kommer att fortsätta att fungera tills det går ut. 
  • Ömsesidigt TLS (mTLS) och Client Cert Scenarios: Om du använde en TLS servercertifikat för klientautentisering, måste du skaffa ett separat certifikat med clientAuth EKU från en annan källa.  
  • Företagssystem som kräver båda EKU:erna: Vissa äldre eller företagssystem förväntade sig båda EKU:erna. Du bör kontrollera om uppdateringar behövs för att följa de nya reglerna. 
  • Certifikat för API-klienter, IoT-enheter etc.: Om ditt användningsfall förlitade sig på clientAuth EKU måste du skaffa ett dedikerat klientautentiseringscertifikat. SSL.com erbjuder Klientautentiseringscertifikat. 

Nödvändiga åtgärder för kunder 

  1. Inventera dina certifikat: Identifiera alla TLS certifikat som används och kontrollera efter clientAuth EKU. 
  2. Identifiera eventuella fall med dubbla användningsområden: Bestäm om något av dina system är beroende av en TLS certifikat för klientautentisering. 
  3. Plan för förnyelse/återutgivning av certifikat: Framtida certifikat kommer att utfärdas utan clientAuth EKU som standard. 
  4. Återutgå tidigt om det behövs: Om du vill uppdatera dina certifikat proaktivt kan du utfärda dem igen innan deadline. 
  5. Skaffa klientautentiseringscertifikat om det behövs: Säkra ett separat certifikat med clientAuth EKU om det behövs. 
  6. Uppdatera dokumentation och konfiguration: Ändra eventuella automatiserade certifikatbegäranskript eller dokumentation som tidigare antog att båda EKU:erna skulle finnas. 

FAQ (Frequently Asked Questions) 

Q1. Vad är "Client Authentication" EKU och varför fanns det i mitt certifikat? 

"Client Authentication" EKU indikerar att ett certifikat kan användas av en klient för att autentisera till en server. Vissa CA har historiskt inkluderat det TLS certifikat som standard, men det krävdes aldrig för normal webbplatssäkerhet. 

Q2. Kommer webbläsare att avvisa mitt certifikat om det har clientAuth EKU? 

Nej. Webbläsare avvisar inte befintliga certifikat som har clientAuth EKU. Ändringen från september 2025 påverkade endast nya certifikatutfärdanden. Ett certifikat som utfärdats före det datumet förblir giltigt tills det löper ut.

Q3. Min nuvarande TLS certifikat säger "Client Authentication" under dess utökade nyckelanvändning. Är det nu ogiltigt? 

Nej, den förblir giltig. Du behöver inte byta ut den omedelbart. När du förnyar kommer det nya certifikatet helt enkelt inte att innehålla clientAuth EKU. 

Q4. Hur kan jag kontrollera om ett certifikat har clientAuth EKU? 

Du kan inspektera certifikatdetaljerna med hjälp av OpenSSL, PowerShell eller GUI-verktyg för att kontrollera Utökad nyckelanvändning förlängning. 

F5. Vårt system kräver att servercertifikatet har både serverAuth och clientAuth EKU. Vad ska vi göra? 

Du bör uppdatera ditt system till att endast kräva serverAuth för servercertifikat. Om klientautentisering behövs, skaffa ett separat certifikat med clientAuth EKU från SSL.com. 

F6. Kan jag fortfarande få ett offentligt pålitligt certifikat med endast klientautentiserings-ECU? 

Vissa certifikatutfärdare, som SSL.com, erbjuder dedikerade klientautentiseringscertifikat. Dessa är separata från TLS certifikat och används vanligtvis för företagsautentisering. 

F7. Påverkar detta andra EKU:er eller certifikattyper (kodsignering, e-post, etc.)? 

Nej, denna förändring är specifik för TLS servercertifikat. Kodsignering och e-postcertifikat har sina egna EKU-krav. 

F8. Vi använder autentisering av klientcertifikat på vår webbplats. Påverkar denna förändring det? 

Nej, ömsesidigt TLS (mTLS) autentisering fungerar fortfarande. Se dock till att klientcertifikat som presenteras av användare fortfarande har clientAuth EKU om det behövs. 

F9. Är detta relaterat till den kommande förändringen till kortare certifikatlivslängder (90-dagarscertifikat)? 

Nej, dessa är separata branschförändringar, men båda syftar till att förbättra säkerheten och certifikathanteringsmetoderna. 

Q10. Var kan jag se de officiella kraven för denna förändring? 

Ocuco-landskapet Google Chrome Root Program Policy  ger riktlinjer om förbud mot clientAuth EKU i TLS servercertifikat. 

Sammanfattning 

Borttagningen av clientAuth EKU från TLS servercertifikat är en branschomfattande policyändring som kommer att förbättra säkerheten och förhindra missbruk. För de flesta användare blir det ingen märkbar påverkan. Men om du litar på clientAuth EKU bör du vidta proaktiva åtgärder för att få rätt typ av certifikat för dina behov. 

Om du har några frågor eller behöver hjälp, vänligen kontakta vårt supportteam på support@ssl.com. 

SSL.com

Vi vill gärna ha din feedback

Följ vår undersökning och låt oss veta vad du tycker om ditt senaste köp.

Sekretessöversikt
SSL.com

Denna webbplats använder cookies så att vi kan ge dig den bästa användarupplevelsen som möjligt. Cookieinformation lagras i din webbläsare och utför funktioner som att känna igen dig när du återvänder till vår webbplats och hjälpa vårt team att förstå vilka delar av webbplatsen du tycker är mest intressant och användbar.

För mer information, läs vår Cookie- och integritetsförklaring.

Tredjepartscookies

Denna webbplats använder Google Analytics & Statcounter för att samla in anonym information som antalet besökare på webbplatsen och de mest populära sidorna.

Att hålla dessa cookies aktiverade hjälper oss att förbättra vår webbplats.

Visa detaljer