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

In het voortdurend veranderende landschap van internetbeveiliging hebben weinig veranderingen de potentie om fundamentele werkwijzen zo ingrijpend te veranderen als de update van het rootprogrammabeleid van Google Chrome. Chrome verandert geleidelijk, met een reeks deadlines vanaf 2026, hoe... SSL/TLS-certificaten kan 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 certificaten... certificeringsinstanties (CA's) voor het authenticeren van gebruikers, apparaten of applicaties, vereist deze wijziging 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 overgang wordt gevormd door Chrome Root Program Policy v1.8 (laatst bijgewerkt op 5 februari 2026), die de inspanningen van het programma voortzet om over te stappen op authenticatie via een dedicated TLS-server. PKI hiërarchieën. Volgens dit beleid mogen certificaathiërarchieën in de vertrouwensopslag van Chrome alleen worden gebruikt voor TLS-serverauthenticatie, en worden multifunctionele rootcertificaten geleidelijk uitgefaseerd.

In de praktijk betekent dit dat openbare CA's zich terugtrekken 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 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 toepasselijke deadline zijn uitgegeven, blijven geldig tot hun vervaldatum (tenzij ze worden ingetrokken), maar nieuwe en vernieuwde openbare certificaten zullen geen clientAuth meer bevatten. De meeste grote CA'sWaaronder 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 TLS. 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 specifieke oplossingen. 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, streven browsers zoals Chrome ernaar om:

• 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?

Encryptie Consulting's CertSecure Manager Dit is een leveranciersneutrale oplossing voor het beheer van de levenscyclus van certificaten die de ontdekking, automatisering, inschrijving, beleidshandhaving en integraties centraliseert. Het voorkomt storingen door geautomatiseerde verlengingen, verbetert de naleving van regelgeving, stroomlijnt IT-activiteiten 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.

Daarnaast kunt u bij Encryption Consulting terecht voor een plek waar clientauthenticatiecertificaten kunnen worden uitgegeven nadat ze de openbare vertrouwensopslag hebben verlaten. PKI-als-een-service Biedt u een volledig beheerde private CA. Het 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 eisen aan browservertrouwen steeds strenger worden, PKI Naarmate omgevingen diverser worden 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.