Ändringar i klientautentiseringscertifikat: Chromes mTLS-skifte 2026

Ett klientautentiseringscertifikat är ett digitalt certifikat som bevisar identiteten för en användare, enhet, arbetsbelastning eller tjänst till en server, oftast inom en ömsesidig TLS (mTLS) handskakning. Chromes ändring från 2026, som levererades via Chrome Root Program , ändrar förtroendekraven för offentligt betrodda certifikat. Enligt dessa krav kommer Chrome inte längre att lita på nyligen utfärdade offentliga certifikat som kombinerar server- och klientautentisering. Nya certifikat som utfärdats under kompatibla offentliga hierarkier är begränsade till serverautentisering, medan certifikat som utfärdats tidigare fortsätter att fungera tills de upphör att gälla. Klientautentisering flyttas till privat eller företags-PKI.

I åratal har många organisationer använt offentligt betrodda Transport Layer Security (TLS)-certifikat för både serverautentisering och klientautentisering i mTLS-distributioner. Den metoden håller nu på att upphöra.

Från och med den 15 juni 2026 påskyndar ändringar som införts genom Googles Chrome Root Program separationen av offentlig serverautentisering och klientautentisering i distinkta PKI-hierarkier (Public Key Infrastructure). Som ett resultat av detta övergår offentligt betrodda certifikatutfärdare (CA) från att utfärda certifikat som innehåller både serverautentisering och klientautentisering med utökad nyckelanvändning (EKU).

Den 15 juni 2026 gäller kravet på nyligen offentliggjorda underordnade certifikatutfärdare; alla nyligen utfärdade offentliga TLS-prenumerantcertifikat måste endast innehålla Server Authentication EKU från och med den 15 mars 2027, enligt Chrome Root Program Policy v1.8.

Detta betyder inte att Chrome avskaffar mTLS. Ömsesidig TLS är fortfarande en viktig säkerhetsmekanism för att autentisera användare, enheter, arbetsbelastningar och tjänster. Istället driver Chrome en övergång mot ändamålsspecifik PKI, där offentliga certifikatutfärdare fokuserar på serveridentitet medan klientautentisering hanteras via privat PKI eller dedikerade företagsinfrastrukturer.

För organisationer som fortfarande förlitar sig på offentligt betrodda certifikat för klientautentisering är detta inte en mindre policyuppdatering. Det är en förändring av förtroendearkitekturen som kräver planering innan förnyelsecykler börjar exponera dolda beroenden.

Vad ändrade Chrome egentligen

Chrome har ändrat reglerna för vad ett offentligt betrott certifikat får göra: nya offentliga TLS -certifikat får endast använda Server Authentication EKU, så de kan inte längre fungera som klientautentiseringsuppgifter. Mycket av diskussionen kring detta ämne har framställts som "mTLS död", men den karaktäriseringen är missvisande.

Chrome Root Programs policyändringar fokuserar på att minska attackytan för den publika WebPKI:n genom att uppmuntra dedikerade TLS-serverautentiseringshierarkier. Från och med den 15 juni 2026 måste nyligen publicerade underordnade CA:er i Chrome-betrodda hierarkier endast bekräfta Server Authentication EKU (id-kp-serverAuth, OID 1.3.6.1.5.5.7.3.1), enligt Chrome Root Program Policy v1.8.

Prenumerantcertifikat som utfärdas enligt dessa hierarkier måste begränsas till serverautentisering från och med den 15 mars 2027, medan redan utfärdade certifikat förblir giltiga tills de löper ut.

Målet är enkelt: separera serveridentitet från klientidentitet.

Tänk på det så här: ett servercertifikat är som en skylt i butiken som bevisar att en butik är legitim, medan ett klientcertifikat är som en anställdsbricka som bevisar att du hör hemma där. Chrome ber varje certifikat att bara utföra ett av dessa jobb.

Historiskt sett kunde vissa offentliga certifikat användas för båda ändamålen eftersom de innehöll både serverautentisering (OID 1.3.6.1.5.5.7.3.1) och klientautentisering (OID 1.3.6.1.5.5.7.3.2) EKU:er. Även om detta var bekvämt skapade detta mångsidiga autentiseringsuppgifter som ofta var överprivilegierade och svårare att styra.

Chromes policy driver ekosystemet mot dedikerade förtroendemodeller där certifikat utför en roll väl istället för flera roller samtidigt.

Varför överger offentliga certifikatutfärdare klientautentisering?

Förändringen ligger i linje med en bredare branschrörelse mot ändamålsspecifika förtroendearkitekturer.

Krav för klientautentisering skiljer sig avsevärt från krav för autentisering av offentliga webbplatser. Företagsenhetsidentitet , arbetsbelastningsautentisering, API-autentisering och intern tjänst-till-tjänst-kommunikation kräver ofta strängare kontroll över utfärdande, återkallelse, livscykelhantering och identitetsstyrning än vad offentliga WebPKI var utformade för att ge.

Let's Encrypt har varit särskilt tydliga på denna punkt. Organisationen tog bort Client Authentication EKU från sin standardcertifikatprofil den 11 februari 2026 och kommer att sluta utfärda klientautentiseringscertifikat helt och hållet den 8 juli 2026, eftersom många användningsfall för klientautentisering är bättre betjänade av privata certifikatutfärdare. Ändringen är direkt kopplad till Chrome Root Programs krav för hierarkier med dedikerad serverautentisering, vilket gör privat eller företags-PKI till den föredragna metoden för klientautentisering.

Stora offentliga certifikatutfärdare som är verksamma inom Chrome Root Program följer liknande tidslinjer, och de flesta slutför övergången före deadline den 15 mars 2027.

Med andra ord tar Chrome inte bort klientautentisering. Det flyttar klientautentisering ut ur det offentliga förtroende-ekosystemet.

Tidslinje: Viktiga datum som organisationer behöver känna till

Flera viktiga milstolpar påverkar organisationer som för närvarande använder offentliga certifikat för klientautentisering.

Datum	Ändra
October 1, 2025	Let's Encrypt introducerar den tillfälliga tlsclient-profilen för organisationer som behöver ytterligare migreringstid
Februari 11, 2026	Let's Encrypt tar bort klientautentiserings-EKU från standardcertifikatprofilen.
May 13, 2026	Åtkomst till tlsclient-profilen stängs för nya användare; befintliga användare kan fortsätta till och med den 8 juli 2026.
Juni 15, 2026	Nyligen avslöjade underordnade certifikatutfärdare i Chrome-betrodda hierarkier måste endast bekräfta Server Authentication EKU (Chrome Root Program Policy v1.8)
July 8, 2026	Let's Encrypt avslutar permanent utfärdandet av certifikat som innehåller klientautentiserings-EKU via tlsclient-profilen.
Mars 15, 2027	Alla nyligen utfärdade offentliga TLS-prenumerationscertifikat måste endast innehålla serverautentiserings-EKU:n (id-kp-serverAuth), enligt Chrome Root Program Policy v1.8.

För många organisationer kommer den operativa effekten inte att märkas omedelbart. Befintliga certifikat fortsätter vanligtvis att fungera tills de löper ut. Den verkliga störningen inträffar när förnyelsetiden är inne och nyutfärdade certifikat inte längre innehåller den förväntade klientautentiserings-EKU:n.

Offentlig PKI vs. privat PKI: Den nya verkligheten

Den viktigaste arkitekturförändringen är separationen av certifikatroller.

Area	Traditionell strategi	Modernt tillvägagångssätt
Offentliga TLS-certifikat	Serverautentisering och klientautentisering tillsammans	Endast serverautentisering
mTLS-autentisering	Använder ofta offentliga certifikat	Använder privat PKI eller dedikerad klientautentiseringshierarki
Trust Model	Syfte med delat förtroende	Ändamålsspecifik förtroendearkitektur
Certifikatstyrning	Multifunktionella certifikat	Dedikerade certifikatroller
Säkerhetshållning	Bredare omfattning av behörighetskrav	Minskad attackyta och starkare tillämpning av policyer

Denna förändring överensstämmer med principen om minsta möjliga behörighet. Ett certifikat som är avsett att autentisera en offentlig webbplats bör inte automatiskt bli en autentiseringsuppgift för autentisering av enheter, användare, API:er eller interna tjänster.

Genom att separera dessa funktioner får organisationer starkare kontroll över identitetshanteringen och minskar risken för missbruk av autentiseringsuppgifter.

Vad som går sönder först

Till en början går ingenting sönder, och det är just det som är risken. System fortsätter ofta att fungera normalt tills certifikatförnyelsen sker.

En mTLS-distribution kan fungera perfekt idag eftersom den förlitar sig på certifikat som utfärdats innan policyändringarna. Men när dessa certifikat löper ut och administratörer försöker förnya dem, kanske ersättningscertifikatet inte längre innehåller den klientautentiserings-EKU som programmet förväntar sig.

Detta skapar ett farligt scenario där dolda beroenden förblir oupptäckta tills ett rutinmässigt certifikatersättningsarbete leder till ett avbrott.

De miljöer som sannolikt kommer att påverkas inkluderar:

• API-gateways med certifikatbaserad klientautentisering
• Intern kommunikation mellan tjänster
• Plattformar för enhetsautentisering
• Partnerintegrationer med mTLS
• Äldre arbetsbelastning identitet arkitekturer
• Företagsapplikationer som förlitar sig på offentliga certifikat för klientidentitet

Organisationer upptäcker ofta dessa beroenden först när en förnyelse misslyckas eller när en handskakning börjar avvisa nya certifikat.

Varför certifikatinventering är viktigare än någonsin

Denna övergång förstärker en lärdom som PKI-team har betonat i åratal: man kan inte hantera det man inte kan se.

Många organisationer har utmärkt insyn i webbplatscertifikat men har liten förståelse för var klientcertifikat används. Vissa klientautentiseringsimplementeringar implementerades för flera år sedan och har sedan dess blivit operativa blinda fläckar.

Det första steget i varje migrering bör vara att identifiera certifikat som innehåller Client Authentication EKU och avgöra om de kommer från offentligt betrodda certifikatutfärdare. Denna identifieringsprocess speglar vad utövare i allt högre grad kallar en kryptografisk materiallista (CBOM), en strukturerad inventering av alla kryptografiska tillgångar, algoritmer, certifikat och nycklar i hela miljön, vilket också håller på att bli en rekommenderad praxis inom bredare planeringsramverk för kryptoagilitet.

När organisationer väl har upptäckt certifikat kan de klassificera dem i tre kategorier:

• Offentlig webbplats TLS
• Klientautentisering
• Intern mTLS och arbetsbelastningsidentitet

I många miljöer är det bara den första kategorin som verkligen hör hemma i offentlig PKI.

Vanliga misstag som organisationer gör

En vanlig missuppfattning är att Chrome helt eliminerar ömsesidig TLS. Detta är felaktigt.

Chromes policy påverkar hur offentliga certifikatutfärdare utfärdar certifikat. Ömsesidig TLS stöds fortfarande fullt ut och fortsätter att vara en viktig autentiseringsmekanism i företagsmiljöer.

Ett annat misstag är att vänta tills förnyelsedatumet är klart för att undersöka beroenden. Vid det laget kan certifikatersättning redan vara på en kritisk väg för affärsverksamheten.

Vissa organisationer fortsätter också att använda offentliga certifikatutfärdare för intern autentisering helt enkelt för att det är bekant. Offentliga WebPKI utformades dock aldrig för att hantera företagsenhetsidentiteter, arbetsbelastningsidentiteter eller interna förtroendeförhållanden i stor skala.

Den nuvarande övergången belyser varför dessa funktioner i allt högre grad hör hemma i företagsstyrda PKI-miljöer.

Bästa säkerhetspraxis framöver

Branschens riktning blir tydlig: använd offentlig PKI för offentligt förtroende och privat PKI för privat förtroende.

Offentliga certifikat bör främst användas för att säkra offentliga webbplatser och internetbaserade tjänster. Klientautentisering, tjänstidentitet, maskinidentitet och intern arbetsbelastningsautentisering bör hanteras via PKI-system för företag som är specifikt utformade för dessa ändamål.

Organisationer bör också prioritera automatisering av certifikatlivscykeln . I takt med att certifikatens livslängd fortsätter att krympa inom branschen blir manuella processer allt svårare att upprätthålla.

Certifikatinventeringar bör övervakas kontinuerligt, förnyelsearbetsflöden automatiseras och privata nycklar skyddas med hjälp av säkra nyckelhanteringsmetoder, såsom hårdvarusäkerhetsmoduler (HSM) validerade enligt FIPS 140-3 där så är lämpligt.

De organisationer som framgångsrikt navigerar denna övergång kommer att vara de som behandlar den som ett initiativ för modernisering av förtroende snarare än ett projekt för att ersätta certifikat.

Hur krypteringskonsulting kan hjälpa

För många organisationer ligger utmaningen inte i att ersätta ett certifikat. Det ligger i att omforma förtroendearkitekturen.

Krypteringskonsulttjänster hjälper organisationer att modernisera PKI-miljöer, separera offentliga och privata förtroendemodeller och bygga skalbara strategier för hantering av certifikatlivscykler.

Genom Enterprise PKI-tjänster kan organisationer utvärdera befintliga mTLS-distributioner, identifiera beroenden för offentliga certifikat och utforma privata PKI-arkitekturer som stöder säker klientautentisering och hantering av arbetsbelastningsidentiteter. För organisationer som behöver certifikatutfärdarfunktioner på företagsnivå utan omkostnaderna för att bygga och driva intern CA-infrastruktur, tillhandahåller en hanterad privat CA-tjänst den utfärdande, livscykelhantering och policystyrning som krävs för att stödja klientautentisering framöver.

När arkitekturen är definierad är nästa prioritet operativ insyn i hela certifikatmiljön och livscykelautomatisering för att hålla jämna steg med förnyelsecyklerna.

CertSecure Manager tillhandahåller centraliserad certifikatidentifiering , lagerhantering, övervakning och livscykelautomatisering, vilket hjälper organisationer att identifiera certifikat som påverkas av kommande policyändringar och automatisera migreringsaktiviteter innan förnyelsedatum skapar operativa risker.

För organisationer som behöver se bortom omedelbar migrering och bygga en långsiktig förtroendestrategi erbjuder Encryption Consulting även dedikerad rådgivningsstöd.

För organisationer som planerar bredare initiativ för modernisering av förtroende kan våra krypteringsrådgivningstjänster hjälpa till att anpassa certifikathantering, arbetsbelastningsidentitet, kryptoagilitet och PKI-styrning till en enhetlig färdplan.

Slutsats

Chromes policyändringar från 2026 signalerar inte slutet för ömsesidig TLS. De signalerar slutet på att använda offentlig WebPKI som en komplett lösning för både server- och klientautentisering.

Branschen rör sig mot dedikerade förtroendearkitekturer där offentliga certifikatutfärdare fokuserar på serverautentisering och privata PKI-plattformar hanterar klientidentiteter, arbetsbelastningsidentiteter och företagsförtroenderelationer.

Organisationer som kartlägger sina certifikat, identifierar beroenden för klientautentisering och börjar migrera till ändamålsspecifika PKI-modeller nu kommer att undvika störande överraskningar vid förnyelse senare.

De mest framgångsrika migreringarna kommer inte enbart att drivas av certifikatutbyte. De kommer att drivas av en genomtänkt modernisering av förtroendearkitekturen som separerar serveridentitet från klientidentitet och förbereder organisationer för nästa generations PKI.