Förstå Chromes rootprogrampolicy v1.8: Vad som ändras den 15 juni 2026

I det ständigt föränderliga landskapet för internetsäkerhet finns det få förändringar som har potential att omforma grundläggande praxis som Google Chromes uppdatering av root-programpolicyn. Under en rad deadlines som börjar 2026 förändrar Chrome hur SSL/TLS-certifikat kan användas. Hierarkier för offentliga certifikat måste nu endast dedikeras till TLS-serverautentisering, vilket innebär att stöd för TLS-klientautentisering försvinner i världen av offentliga certifikat. Om din organisation förlitar sig på offentliga certifikatmyndigheter (CA:er) för autentisering av användare, enheter eller applikationer, kräver denna förändring omedelbar uppmärksamhet.

Låt oss analysera vad detta innebär, varför det händer och hur du kan förbereda dig.

Kärnan i förändringen: Chrome Root Program Policy v1.8

Kärnan i denna övergång är Chrome Root Program Policy v1.8 (senast uppdaterad 5 februari 2026), som fortsätter programmets strävan mot dedikerad TLS-serverautentisering. PKI hierarkier. Enligt denna policy får certifikathierarkier som ingår i Chromes förtroendelager endast användas för TLS-serverautentisering, och flerfunktionella rötter fasas ut.

Vad detta i praktiken innebär är att offentliga CA:er kliver bort från certifikat som har både id-kp-serverAuth och id-kp-clientAuth Extended Key Usages (EKU). Dessa EKU:er definierar vad ett certifikat kan användas till, antingen server- eller klientautentisering, men inte båda. Ändringen sker på två datum som är värda att markera i din kalender.

Från och med den 15 juni 2026 måste alla nya mellanliggande (underordnade) CA-certifikat som deklareras till CCADB under en rot i Chrome Root Store endast bära serverAuth EKU. Sedan, från och med den 15 mars 2027, gäller samma regel för de certifikat du faktiskt distribuerar: varje nyligen utfärdat lövcertifikat som är kopplat till en Chrome-betrodd rot måste också vara serverAuth-only. Därefter är clientAuth i praktiken borta från offentliga certifikat.

Certifikat som utfärdats före den tillämpliga tidsfristen förblir giltiga tills de löper ut (såvida de inte återkallas), men nya och förnyade offentliga certifikat kommer inte längre att inkludera clientAuth. De flesta större CA, inklusive DigiCert, Sectigo och Let's Encrypt, började ta bort clientAuth EKU som standard långt före dessa deadlines.

Varför detta Matters

TLS-klientautentisering är en viktig mekanism som används för att verifiera klienters identitet, vare sig det är användare, enheter eller applikationer, när de ansluter till en server. Det skiljer sig från serverautentisering, vilket är vad de flesta förknippar med HTTPS.

Klientautentisering används ofta i:

• VPN-åtkomst: Verifierar anställdas enheter som ansluter på distans.
• Wi-Fi-introduktion: Autentisera enheter utan statiska lösenord.
• Ömsesidig TLS (mTLS): Säkra API-kommunikation i mikrotjänster.
• Enkel inloggning (SSO): Bädda in certifikat i slutpunktsenheter.
• DevOps-miljöer: Identifiera arbetsbelastningar och containrar.

Många organisationer har använt offentliga certifikatutfärdare för dessa ändamål, ofta omedvetet, eftersom det är bekvämt och kostnadseffektivt. Men med Chromes nya policy kommer denna metod inte längre att vara genomförbar.

Varför händer det här?

Flytten är en del av en bredare branschtrend mot dedikerad PKI hierarkier. Flerfunktionscertifikat, de som används för både server- och klientautentisering, introducerar komplexitet och potentiella säkerhetsrisker. Genom att separera dessa användningsfall syftar webbläsare som Chrome till att:

• Förbättra certifikathanteringen.
• Stärka förtroendet för offentlig PKI.
• Minska risken för felaktig användning eller felkonfiguration.

Publika certifikatutfärdare utformades aldrig för interna autentiseringsarbetsflöden. De är föremål för externa granskningar, efterlevnadskrav och webbläsarpolicyer. Detta gör dem olämpliga för den flexibilitet och kontroll som krävs i klientautentiseringsscenarier.

Lösningen: Övergång till privata CA:er

Om din organisation använder offentliga certifikat för klientautentisering är vägen framåt tydlig: migrera till en privat certifikatutfärdare (CA).

Fördelarna med privata CA:er inkluderar:

• Anpassningsbara certifikatprofiler.
• Full kontroll över utfärdande och återkallelse.
• Inget beroende av webbläsarens förtroendebutiker.
• Stöd för protokoll som ACME, EST och SCEP.

Denna förändring ger organisationer möjlighet att utforma autentiseringsarbetsflöden skräddarsydda efter deras behov, utan att begränsas av begränsningar från offentliga CA-leverantörer.

Vad du bör göra härnäst

Här är en praktisk färdplan för att förbereda sig för Chromes deadlines 2026 och 2027:

1. Granska din certifikatanvändning: Identifiera var TLS-klientautentisering används. Förlitar ni er på offentliga ACME-arbetsflöden som Let's Encrypt? Vilka enheter och tjänster påverkas?
2. Bedöm din risk: Bestäm vilka certifikat som kommer att påverkas och när. Planera att ersätta dem innan de löper ut eller blir opålitliga.
3. Implementera en privat certifikatutfärdare: Välj en lösning som passar din miljö: molnbaserad, lokal eller hybrid. Se till att den stöder automatisering och integration med dina befintliga verktyg.
4. Implementera CLM och migrera dina publika CA-certifikat till en privat CA: Med din privata CA på plats, implementera en CLM plattform för att hantera certifikatlivscykler, tillämpa policyer och upprätthålla synlighet i din miljö. Innan du migrerar, definiera lämpliga certifikatmallar och EKU:er på den privata certifikatutfärdaren så att de återutfärdade certifikaten har rätt användningsområden (för klientautentisering, clientAuth EKU utan serverAuth). Med det på plats kan du använda CLM:s switch-CA-funktion för att flytta dina befintliga klientautentiseringscertifikat för offentliga certifikatutfärdare till den privata certifikatutfärdaren i bulk, istället för att spåra och återutfärda vart och ett manuellt.
5. Utbilda dina team: Se till att IT, DevOps, och säkerhetsteamen förstår konsekvenserna och är överens om migreringsstrategin.

Hur kan krypteringskonsultation hjälpa till?

Krypteringskonsulttjänster CertSecure-hanterare är en leverantörsneutral lösning för hantering av certifikatlivscykeln som centraliserar identifiering, automatisering, registrering, policytillämpning och integrationer. Den förhindrar avbrott med automatiserade förnyelser, förbättrar efterlevnad, effektiviserar IT-driften och förenar hanteringen av offentliga och privata certifikatutfärdare genom en enda, automatiserad och skalbar plattform.

Specifikt för Chrome-ändringen låter dess identifiering och inventering dig hitta exakt vilka av dina certifikat som bär clientAuth EKU idag, och dess migrering av offentliga CA-certifikat med ett klick hjälper dig att flytta dessa arbetsbelastningar till en privat CA i bulk, utan den manuella ansträngningen att spåra och utfärda nya certifikat ett efter ett.

Dessutom, om du behöver någonstans att utfärda klientautentiseringscertifikat när de lämnar det offentliga förtroendearkivet, Encryption Consultings PKI-som-en-tjänst ger dig en helt hanterad privat CA. Den hanterar din PKI-distribution från början till slut, med certifikatutfärdande, automatiserad livscykelhantering, policytillämpning och efterlevnad av branschsäkerhetsstandarder, så att du kan upprätta en dedikerad privat hierarki för VPN, Wi-Fi, mTLS och SSO utan att behöva bygga och driva infrastrukturen själv.

Slutsats

Chromes root-programuppdatering är inte bara en teknisk justering; den markerar ett fundamentalt skifte i hur digital identitet och förtroende hanteras över internet. Även om det kan störa befintliga autentiseringsarbetsflöden ger det också organisationer en snabb möjlighet att modernisera sin PKI-arkitektur och bygga en säkrare, skalbarare och mer robust grund.

Om din organisation fortfarande använder offentliga certifikat för klientautentisering är det dags att agera nu. Tidsfristerna är fastställda, tillämpningen är strikt och Chromes övergång till dedikerad serverautentisering med offentlig PKI gör privata certifikatutfärdare till den enda hållbara vägen framåt.

Samtidigt gör den ökande volymen certifikat, de krympande livslängderna för certifikat och den ökande komplexiteten i distribuerade miljöer att certifikatlivscykelhantering (CLM) är avgörande, inte valfritt. En robust CLM-lösning förhindrar avbrott, automatiserar förnyelser, upprätthåller efterlevnad och ger organisationer fullständig insyn och kontroll över sina kryptografiska tillgångar.

I ett ekosystem där kraven på webbläsarförtroende fortsätter att skärpas, PKI När miljöer diversifieras och digitala identiteter mångfaldigas över moln-, DevOps-, IoT- och zero-trust-arkitekturer blir effektiv certifikatlivscykelhantering grundläggande för en säker, ändamålsenlig och framtidsklar autentiseringsstrategi.