Inzicht in Chrome's Root Program Policy v1.8: Wat verandert er op 15 juni 2026?

In het voortdurend veranderende landschap van internetbeveiliging zijn er maar weinig veranderingen die zo'n grote impact hebben op fundamentele werkwijzen als de update van het rootprogrammabeleid van Google Chrome. Chrome verandert, met een reeks deadlines vanaf 2026, de manier waarop SSL/TLS-certificaten kunnen worden gebruikt. Openbare certificaathiërarchieën moeten nu uitsluitend worden gebruikt voor TLS-serverauthenticatie, wat betekent dat de ondersteuning voor TLS-clientauthenticatie in de wereld van openbare certificaten verdwijnt. Als uw organisatie afhankelijk is van openbare certificeringsinstanties (CA's) voor de authenticatie van gebruikers, apparaten of applicaties, vereist deze verandering onmiddellijke aandacht.

Laten we eens nader bekijken wat dit betekent, waarom het gebeurt en hoe je je kunt voorbereiden.

De kern van de verandering: Chrome Root Program Policy v1.8

De kern van deze transitie is het Chrome Root Program Policy v1.8 (laatst bijgewerkt op 5 februari 2026), dat de focus van het programma op dedicated TLS-serverauthenticatie PKI- hiërarchieën voortzet. Volgens dit beleid mogen certificaathiërarchieën in de vertrouwensopslag van Chrome alleen TLS-serverauthenticatie ondersteunen, en worden rootcertificaten voor meerdere doeleinden uitgefaseerd.

In de praktijk betekent dit dat openbare certificeringsinstanties (CA's) afstappen van certificaten die zowel de Extended Key Usages (EKU's) id-kp-serverAuth als id-kp-clientAuth bevatten. Deze EKU's definiëren waarvoor een certificaat gebruikt kan worden: server- of clientauthenticatie, maar niet voor beide. De wijziging vindt plaats op twee data die u in uw agenda kunt noteren.

Vanaf 15 juni 2026 moet elk nieuw intermediair (ondergeschikt) CA-certificaat dat aan de CCADB wordt vrijgegeven onder een root in de Chrome Root Store, alleen de serverAuth EKU bevatten. Vanaf 15 maart 2027 geldt dezelfde regel voor de certificaten die u daadwerkelijk implementeert: elk nieuw uitgegeven bladcertificaat dat een keten vormt naar een door Chrome vertrouwde root, moet ook alleen de serverAuth-eigenschap bevatten. Daarna is clientAuth feitelijk verdwenen uit openbare certificaten.

Certificaten die vóór de betreffende deadline zijn uitgegeven, blijven geldig tot ze verlopen (tenzij ze worden ingetrokken), maar nieuwe en vernieuwde openbare certificaten zullen clientAuth niet langer bevatten. De meeste grote certificeringsinstanties , waaronder DigiCert, Sectigo en Let's Encrypt, zijn al ruim voor deze deadlines begonnen met het standaard verwijderen van de clientAuth EKU.

Waarom deze Matters

TLS-clientauthenticatie is een cruciaal mechanisme dat wordt gebruikt om de identiteit van clients, of het nu gebruikers, apparaten of applicaties zijn, te verifiëren wanneer ze verbinding maken met een server. Het is iets anders dan serverauthenticatie, wat de meeste mensen associëren met HTTPS.

Clientauthenticatie wordt vaak gebruikt in:

• VPN-toegang: Controleren of de apparaten van medewerkers op afstand verbinding maken.
• Wi-Fi-integratie: Apparaten authenticeren zonder statische wachtwoorden.
• Mutual TLS (mTLS): Beveiliging van API-communicatie in microservices.
• Eenmalige aanmelding (SSO): Certificaten inbedden in eindapparaten.
• DevOps-omgevingen: Het identificeren van werklasten en containers.

Veel organisaties hebben voor deze doeleinden, vaak onbewust, gebruikgemaakt van openbare CA's, omdat het handig en kosteneffectief is. Maar met het nieuwe beleid van Chrome is deze aanpak niet langer haalbaar.

Waarom gebeurt dit?

Deze stap maakt deel uit van een bredere trend in de sector richting dedicated PKI- hiërarchieën. Certificaten voor meerdere doeleinden, die zowel voor server- als clientauthenticatie worden gebruikt, introduceren complexiteit en potentiële beveiligingsrisico's. Door deze gebruiksscenario's te scheiden, willen browsers zoals Chrome het volgende bereiken:

• Verbeter het certificaatbeheer.
• Versterk het vertrouwen in openbare PKI.
• Verminder het risico op misbruik of verkeerde configuratie.

Openbare certificeringsinstanties (CA's) zijn nooit ontworpen voor interne authenticatieprocessen. Ze zijn onderworpen aan externe audits, nalevingsvoorschriften en browserbeleid. Daardoor zijn ze ongeschikt voor de flexibiliteit en controle die vereist zijn in authenticatiescenario's voor klanten.

De oplossing: overstappen op private CA's

Als uw organisatie openbare certificaten gebruikt voor clientauthenticatie, is de oplossing duidelijk: migreer naar een private certificeringsinstantie (CA).

De voordelen van particuliere registeraccountants zijn onder andere:

• Aanpasbare certificaatprofielen.
• Volledige controle over uitgifte en intrekking.
• Geen afhankelijkheid van browservertrouwensarchieven.
• Ondersteuning voor protocollen zoals ACME, EST en SCEP.

Deze verschuiving stelt organisaties in staat om authenticatieworkflows te ontwerpen die zijn afgestemd op hun behoeften, zonder gebonden te zijn aan de beperkingen van openbare certificeringsinstanties.

Wat u vervolgens moet doen

Hier is een praktisch stappenplan om je voor te bereiden op de deadlines van Chrome in 2026 en 2027:

1. Controleer uw certificaatgebruik: Identificeer waar TLS-clientauthenticatie wordt gebruikt. Maakt u gebruik van openbare ACME-workflows zoals Let's Encrypt? Welke apparaten en services worden hierdoor beïnvloed?
2. Beoordeel uw risico: Bepaal welke certificaten worden beïnvloed en wanneer. Plan om ze te vervangen voordat ze verlopen of niet langer als betrouwbaar worden beschouwd.
3. Een privé-CA implementeren: Kies een oplossing die bij uw omgeving past: cloudgebaseerd, on-premise of hybride. Zorg ervoor dat deze automatisering en integratie met uw bestaande tools ondersteunt.
4. CLM implementeren en uw openbare CA-certificaten migreren naar een privé-CA: Zodra uw eigen CA is ingesteld, kunt u een implementatie uitvoeren. CLM Een platform voor het beheren van de levenscyclus van certificaten, het afdwingen van beleid en het behouden van inzicht in uw omgeving. Voordat u migreert, definieert u de juiste certificaatsjablonen en EKU's op de private CA, zodat de opnieuw uitgegeven certificaten de juiste gebruiksrechten hebben (voor clientauthenticatie de clientAuth EKU zonder serverAuth). Gebruik vervolgens de switch CA-functionaliteit van het CLM om uw bestaande clientauthenticatiecertificaten van de publieke CA in één keer over te zetten naar de private CA, in plaats van ze handmatig op te sporen en opnieuw uit te geven.
5. Informeer uw teams: Zorg ervoor dat IT, DevOpsEn de beveiligingsteams begrijpen de implicaties en zijn het eens over de migratiestrategie.

Hoe kan Encryption Consulting u helpen?

CertSecure Manager van Encryption Consulting is een leveranciersneutrale oplossing voor certificaatlevenscyclusbeheer die de ontdekking, automatisering, inschrijving, beleidshandhaving en integraties centraliseert. Het voorkomt storingen door geautomatiseerde verlengingen, verbetert de naleving van regelgeving, stroomlijnt IT-processen en verenigt het beheer van openbare en private certificeringsinstanties via één geautomatiseerd, schaalbaar platform.

Wat de wijziging in Chrome betreft, kunt u met de detectie- en inventarisatiefunctie precies achterhalen welke van uw certificaten momenteel de clientAuth EKU bevatten. De migratie naar een openbare CA met één klik helpt u bovendien om deze workloads in één keer over te zetten naar een privé-CA, zonder dat u handmatig alle certificaten één voor één hoeft op te sporen en opnieuw uit te geven.

Als u bovendien een plek nodig hebt om clientauthenticatiecertificaten uit te geven nadat ze de openbare vertrouwensopslag hebben verlaten, biedt de PKI-as-a-Service van Encryption Consulting u een volledig beheerde private CA. Deze oplossing verzorgt uw PKI-implementatie van begin tot eind, inclusief certificaatuitgifte, geautomatiseerd levenscyclusbeheer, beleidshandhaving en naleving van industriestandaarden voor beveiliging. Zo kunt u een dedicated private hiërarchie opzetten voor VPN, Wi-Fi, mTLS en SSO zonder zelf de infrastructuur te hoeven bouwen en beheren.

Conclusie

De update van het rootprogramma van Chrome is niet zomaar een technische aanpassing; het markeert een fundamentele verschuiving in de manier waarop digitale identiteit en vertrouwen op het internet worden beheerd. Hoewel het bestaande authenticatieprocessen kan verstoren, biedt het organisaties ook een uitgelezen kans om hun PKI-architectuur te moderniseren en een veiligere, schaalbare en veerkrachtigere basis te bouwen.

Als uw organisatie nog steeds openbare certificaten gebruikt voor clientauthenticatie, is het nu tijd om actie te ondernemen. De deadlines zijn vastgesteld, de handhaving is streng en de overstap van Chrome naar een openbare PKI die uitsluitend voor serverauthenticatie is bedoeld, maakt private CA's de enige duurzame weg voorwaarts.

Tegelijkertijd maken het toenemende aantal certificaten, de kortere geldigheidsduur van certificaten en de groeiende complexiteit van gedistribueerde omgevingen Certificate Lifecycle Management (CLM) essentieel, en niet optioneel. Een robuuste CLM-oplossing voorkomt storingen, automatiseert verlengingen, waarborgt naleving en geeft organisaties volledig inzicht in en controle over hun cryptografische activa.

In een ecosysteem waar de vertrouwensvereisten van browsers steeds strenger worden, PKI- omgevingen diversifiëren en digitale identiteiten zich vermenigvuldigen in cloud-, DevOps-, IoT- en zero-trust-architecturen, wordt effectief certificaatlevenscyclusbeheer essentieel voor een veilige, efficiënte en toekomstbestendige authenticatiestrategie.