Inzicht in Chrome's Root Program Policy v1.6 en de implicaties daarvan in 2026 

Snel antwoord: Chrome Root Program Policy v1.6 schrijft voor dat alle PKI-hiërarchieën in de vertrouwensopslag van Chrome uitsluitend bestemd moeten zijn voor TLS-serverauthenticatie. Vanaf 15 juni 2026 moet elk nieuw TLS-certificaat dat ook de volgende elementen bevat, aan deze eisen voldoen. id-kp-clientAuth EKU wordt door Chrome geweigerd. Organisaties moeten hun clientauthenticatieprocessen vóór deze datum migreren van openbare CA's naar privé-CA's.

Vanaf 15 juni 2026 zal Google Chrome elk nieuw, publiekelijk vertrouwd TLS-certificaat weigeren dat de volgende inhoud bevat: id-kp-clientAuth Uitgebreid sleutelgebruik (EKU). Deze wijziging, geïntroduceerd in Chrome Root Program Policy v1.6 en overgenomen in v1.8, maakt een einde aan het tijdperk van openbare TLS-certificaten met een dubbele functie, die zowel voor server- als clientauthenticatie werden gebruikt. Als uw organisatie openbare certificeringsinstanties gebruikt voor VPN-toegang, Wi-Fi-onboarding, wederzijdse TLS of SSO, vereist deze deadline onmiddellijke actie.

Key Takeaways

• Uiterste inleverdatum: 15 juni 2026. Chrome zal nieuwe openbare TLS-certificaten die de volgende inhoud bevatten, niet vertrouwen. id-kp-clientAuth EKU vanaf deze datum. Certificaten die vóór de deadline zijn afgegeven, blijven geldig tot hun natuurlijke vervaldatum.
• Deze wijziging geldt voor alle organisaties die openbare CA's gebruiken voor VPN, Wi-Fi-authenticatie, mTLS API-beveiliging, SSO of DevOps-workloadidentificatie.
• De oplossing is om clientauthenticatie te migreren van openbare CA's naar een privé-CA, die niet onderworpen is aan de vereisten van Chrome's vertrouwensopslag.
• Volgens de Trust Pulse Survey van DigiCert (2 juli 2025) heeft bijna de helft van alle bedrijven het afgelopen jaar te maken gehad met uitval als gevolg van certificaatproblemen. Een ongecontroleerde migratie naar private CA's brengt een aanzienlijk risico op uitval met zich mee, tenzij er geautomatiseerd beheer van de certificaatlevenscyclus is.
• Het CA/Browser Forum-voorstel SC-081v3 (april 2025) verkort tegelijkertijd de geldigheidsduur van openbare TLS-certificaten naar 200 dagen (maart 2026), 100 dagen (maart 2027) en 47 dagen (maart 2029). Beide wijzigingen samen maken handmatig certificaatbeheer onhoudbaar.

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

De kern van deze overgang is het Chrome Root Program Policy v1.6 (nu ook terug te vinden in de huidige v1.8), dat voorschrijft dat certificaathiërarchieën in de vertrouwensopslag van Chrome uitsluitend bestemd moeten zijn voor TLS-serverauthenticatie.

Dit betekent dat openbare certificeringsinstanties geen certificaten meer mogen uitgeven die beide elementen bevatten. id-kp-serverAuth en id-kp-clientAuth Uitgebreide sleutelgebruiken (EKU's). Deze EKU's definiëren waarvoor een certificaat kan worden gebruikt: serverauthenticatie, clientauthenticatie of beide. Vanaf 15 juni 2026 zal Chrome elk nieuw openbaar TLS-certificaat dat de volgende EKU's bevat, wantrouwen. clientAuth EKU-certificaten die vóór deze datum zijn afgegeven, blijven geldig tot hun natuurlijke vervaldatum, maar er worden geen nieuwe dubbele EKU-certificaten meer geaccepteerd.

Kernbegrippen en beslissingshandleiding

Gebruik deze tabel om de belangrijkste concepten te begrijpen, te bepalen wanneer elk concept van toepassing is op uw situatie en het juiste implementatiepad te kiezen.

Concept	Definitie	Als het er toe doet	Implementatieoverwegingen
id-kp-serverAuth EKU	De Extended Key Usage OID (1.3.6.1.5.5.7.3.1) die een certificaat autoriseert voor TLS-serverauthenticatie (HTTPS).	Elk openbaar TLS-certificaat dat is uitgegeven voor een website of API-eindpunt.	Alle nieuwe openbare TLS-certificaten na 15 juni 2026 moeten uitsluitend deze EKU bevatten.
id-kp-clientAuth EKU	De Extended Key Usage OID (1.3.6.1.5.5.7.3.2) die een certificaat autoriseert voor TLS-clientauthenticatie	VPN, Wi-Fi, mTLS, SSO, DevOps workload identity	Na 15 juni 2026 mogen certificaten alleen nog worden uitgegeven door particuliere certificeringsinstanties die niet onder de vertrouwensopslag van Chrome vallen.
Dubbel EKU-certificaat	Een TLS-certificaat dat zowel de serverAuth- als de clientAuth-EKU's in één certificaat bevat.	Verouderde configuraties die één certificaat gebruiken voor zowel server- als clientauthenticatie.	Niet langer uit te geven door openbare CA's voor Chrome-vertrouwde hiërarchieën na 15 juni 2026.
Privé CA	Een certificeringsinstantie die intern door een organisatie wordt beheerd of via een managed service, en die niet onderworpen is aan de vereisten van de browser trust store.	Elk gebruiksscenario voor clientauthenticatie na 15 juni 2026	Implementeer via on-premises ADCS, cloud-PKI of PKI-as-a-Service; distribueer de root naar interne vertrouwensarchieven.
mTLS (Mutual TLS)	Een TLS-handshake waarbij zowel de server als de client certificaten presenteren voor wederzijdse authenticatie, vaak gebruikt in microservices en zero-trust-architecturen.	API-beveiliging, service mesh, handhaving van zero-trust	Na de migratie moeten mTLS-clientcertificaten afkomstig zijn van een private CA; servercertificaten blijven bij publieke CA's geregistreerd.
Uitgebreid sleutelgebruik (EKU)	Een X.509-certificaatuitbreiding die de specifieke doeleinden definieert waarvoor de openbare sleutel van het certificaat mag worden gebruikt.	Alle TLS-certificaten moeten vóór 15 juni 2026 gecontroleerd worden op clientAuth.	Gebruik het CLM-platform om alle certificaten te scannen en certificaten met clientAuth EKU te markeren.
Chrome Root Store	De lijst met vertrouwde root-certificeringsinstanties van Google Chrome wordt onafhankelijk van de vertrouwensopslag van het besturingssysteem beheerd.	Elk certificaat dat door Chrome wordt vertrouwd voor HTTPS-verbindingen	Het Chrome Root Program Policy v1.6/v1.8 bepaalt welke certificaten deze CA's mogen uitgeven; particuliere CA's zijn niet in deze store opgenomen.

Waarom dit belangrijk is voor uw organisatie

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 en zero-trust-omgevingen.
• Eenmalige aanmelding (SSO): Certificaten inbedden in eindapparaten voor inloggen zonder wachtwoord.
• DevOps-omgevingen: Het identificeren van workloads, containers en serviceaccounts.

Veel organisaties hebben voor deze doeleinden gebruikgemaakt van openbare certificeringsinstanties (CA's), vaak onbewust, omdat het handig en kosteneffectief is. Met het nieuwe beleid van Chrome worden alle verlengingen of nieuwe uitgiften van deze certificaten door een openbare CA na 15 juni 2026 onmiddellijk door Chrome geweigerd.

Wie zou zich druk moeten maken over deze verandering?

Dit beleid heeft gevolgen voor meerdere teams. Hieronder staat wie actie moet ondernemen en wat ze moeten doen.

Rol	Waarom het uitmaakt	Actie-item
PKI-beheerders	Een eigen CA moet worden geïmplementeerd en de certificaatuitgifte moet worden gemigreerd voor alle clientauthenticatieprocessen.	Controleer alle certificaten voor de clientAuth EKU; implementeer een private CA (on-premise, in de cloud of PKIaaS); update het uitgiftebeleid.
Beveiligingsarchitecten	Het nieuwe vertrouwensmodel voor clientauthenticatie moet worden gedefinieerd en de beveiliging van de private CA-hiërarchie moet worden gewaarborgd.	Ontwerp een private CA-hiërarchie; definieer een certificaatbeleid voor clientauthenticatie; zorg voor sleutelopslag met HSM-ondersteuning.
Platform-/DevOps-teams	CI/CD-pipelines, service meshes en Kubernetes-workloads moeten worden bijgewerkt om certificaten te gebruiken die zijn uitgegeven door een private CA.	Update ACME-clients en inschrijvingsworkflows; distribueer de privé-CA-root naar interne vertrouwensarchieven; test authenticatiestromen
Compliance	Er moet bewijs worden geleverd dat alle betreffende certificaten vóór de deadline zijn geïnventariseerd en gemigreerd.	Bouw een auditlogboek op vanuit de CLM-inventaris; neem de migratie naar Chrome v1.6 op in de driemaandelijkse certificaatconformiteitscontrole.
CISO's	Neem het risico van de deadline op je; een gemiste migratie leidt tot authenticatieproblemen in de hele organisatie.	Beschouw dit als een formeel project met een strikte deadline van 15 juni 2026; financier de CLM-tools en de implementatie van private CA.

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, wil Chrome het certificaatbeheer verbeteren, het vertrouwen in openbare PKI's versterken en het risico op misbruik of verkeerde configuratie verminderen.

Openbare certificeringsinstanties (CA's) waren nooit ontworpen voor interne authenticatieprocessen. Ze zijn onderworpen aan externe audits, nalevingsvoorschriften en browserbeleid, waardoor ze ongeschikt zijn voor de flexibiliteit en controle die vereist zijn in clientauthenticatiescenario's. De bijeenkomst van het CA/Browser Forum in oktober 2024 gaf al een voorproefje van deze verandering toen Google de intentie van het Chrome Root Program presenteerde om dit te elimineren. clientAuth Gebruiksscenario's van server-SSL/TLS-certificaten. Het beleid werd formeel gepubliceerd in versie 1.6 en is nu actueel in versie 1.8.

De oplossing: overstappen naar een private CA

Als uw organisatie openbare certificaten gebruikt voor clientauthenticatie, is de oplossing duidelijk: migreer naar een private certificeringsinstantie (CA). Private CA's zijn niet opgenomen in de rootcertificaatwinkel van Chrome en vallen daarom niet onder de vereisten van Chrome voor de vertrouwensopslag.

De voordelen van particuliere registeraccountants zijn onder andere:

• Aanpasbare certificaatprofielen met elke gewenste EKU-combinatie, inclusief clientAuth.
• Volledige controle over uitgifte, beleid en intrekking zonder beperkingen van externe CA's.
• Geen afhankelijkheid van browservertrouwensarchieven voor interne authenticatie.
• Ondersteuning voor moderne inschrijvingsprotocollen zoals ACME, EST en SCEP.
• De mogelijkheid om kortstondige clientcertificaten uit te geven, waardoor de periode waarin een aanval mogelijk is vanuit een gecompromitteerde inloggegevens wordt verkort.

Deze verschuiving stelt organisaties in staat om authenticatieworkflows te ontwerpen die zijn afgestemd op hun behoeften, zonder beperkt te worden door de beperkingen van openbare CA's. Voor organisaties die geen eigen CA-infrastructuur willen beheren, biedt PKI-as-a-Service een volledig beheerde, private CA voor één gebruiker met ingebouwde automatisering, FIPS-compatibele HSM-sleutelbescherming en ondersteuning voor ACME-, SCEP- en EST-registratie.

Vergeet het beheer van de levenscyclus van certificaten niet.

Migreren naar een private CA is slechts de eerste stap. Om uw infrastructuur toekomstbestendig te maken, hebt u robuuste oplossingen nodig. Certificaatlevenscyclusbeheer (CLM)De migratie zelf legt een veelvoorkomend probleem bloot: de meeste organisaties beschikken niet over een volledig en nauwkeurig overzicht van welke certificaten de betreffende functionaliteit bevatten. clientAuth EKU, waar ze worden ingezet, of wanneer ze verlopen.

Een CLM-platform helpt u bij:

• Ontdek en inventariseer alle certificaten, inclusief die met de clientAuth EKU, in alle omgevingen.
• Automatiseer de uitgifte, verlenging en intrekking van uw nieuwe privé-CA.
• Handhaaf beleid met betrekking tot sleutellengte, EKU's, geldigheidsperioden en goedgekeurde CA-bronnen.
• Voorkom storingen als gevolg van verlopen of verkeerd geconfigureerde certificaten tijdens en na de migratie.
• Genereer auditrapporten die de naleving van het Chrome-beleid en andere frameworks aantonen.

Naarmate de levensduur van certificaten korter wordt — de stemming van het CA/Browser Forum SC-081v3 (april 2025) beperkt de maximale geldigheidsduur van openbare TLS-certificaten tot 47 dagen in maart 2029 — wordt handmatig bijhouden volstrekt onhoudbaar. CertSecure Manager biedt geautomatiseerd certificaatlevenscyclusbeheer met detectie, beleidshandhaving en naadloze integratie in uw IT-ecosysteem, inclusief private en publieke CA's.

Migratiechecklist: Wat te doen vóór 15 juni 2026

Doorloop deze checklist in de juiste volgorde. Elke stap is afhankelijk van de voltooiing van de vorige stap.

• Controleer uw certificaatgebruik: Gebruik een CLM-platform of een tool voor certificaatdetectie om alle omgevingen (on-premises, cloud, Kubernetes, DevOps-pipelines) te scannen en elk certificaat te identificeren dat de volgende eigenschappen bevat: id-kp-clientAuth EKU. Let op de uitgevende CA, de vervaldatum en de dienst die van elk certificaat afhankelijk is. CBOM Secure Deze ontdekking kan geautomatiseerd worden in hybride en multi-cloudomgevingen.
• Beoordeel uw risicoblootstellingBepaal welke certificaten als eerste worden getroffen (die met de vroegste verlengings- of vervaldatum na 15 juni 2026) en welke services ervan afhankelijk zijn. Geef prioriteit aan authenticatiekritieke services zoals VPN-gateways, Wi-Fi-controllers en SSO-providers.
• Een privé-CA implementeren: Kies een oplossing die bij uw omgeving past: on-premises ADCS, een in de cloud gehoste private CA (AWS Private CA, Azure AD CA) of een volledig beheerde oplossing. PKI-as-a-Service platform. Zorg ervoor dat de CA automatisering ondersteunt en integreert met uw bestaande inschrijvingstools. Verspreid het privé-CA-rootcertificaat naar alle interne client-vertrouwensarchieven voordat u migreert.
• CLM implementeren: Aanwenden CertSecure Manager Om de levenscyclus van certificaten te beheren, EKU-beleid af te dwingen en tijdens de overgang volledig inzicht te behouden in zowel uw oude openbare CA-certificaten als uw nieuwe privé-CA-certificaten.
• Authenticatieworkflows migreren en testenGeef nieuwe clientauthenticatiecertificaten uit via uw nieuwe privé-CA. Test elke authenticatieworkflow (VPN, Wi-Fi, mTLS, SSO) om te bevestigen dat deze correct werkt met de nieuwe, door de privé-CA uitgegeven certificaten voordat u de oude openbare CA-certificaten intrekt.
• Train je teams: Zorg voor IT, DevOpsDe beveiligingsteams begrijpen de verandering en zijn het eens over de migratiestrategie. Werk de handleidingen, onboardinggidsen en certificaataanvraagprocedures bij om de nieuwe workflow voor private CA's weer te geven.

Hoe encryptieconsultancy kan helpen

CertSecure Manager is een leveranciersneutraal platform voor certificaatlevenscyclusbeheer dat de ontdekking, automatisering, inschrijving, beleidshandhaving en integraties tussen openbare en private CA's centraliseert. Het voorkomt storingen met geautomatiseerde verlengingen, verbetert de naleving van regelgeving, stroomlijnt IT-processen en geeft organisaties volledig inzicht in en controle over hun gehele certificaatportfolio tijdens en na de migratie naar Chrome v1.6.

PKI-as-a-Service helpt organisaties bij het vereenvoudigen van de implementatie van een private CA met end-to-end certificaatuitgifte, geautomatiseerd lifecyclemanagement, beleidshandhaving en naadloze naleving van industriestandaarden voor beveiliging. Voor organisaties die snel een private CA moeten implementeren vóór de deadline van 15 juni 2026, elimineert PKIaaS de tijd die nodig is voor de infrastructuurconfiguratie en biedt het vanaf dag één een productiegereed CA-systeem.

Voor een breder cryptografisch overzicht in alle omgevingen, inclusief certificaten, sleutels en algoritmen, bouwt en onderhoudt CBOM Secure een complete cryptografische materiaallijst (Bill of Materials). Dit is met name nuttig tijdens de initiële verkenningsfase van de migratie, waarin organisaties elk certificaat met de clientAuth EKU moeten identificeren in hybride, multi-cloud en on-premises implementaties.

Conclusie

Chrome's Root Program Policy v1.6 is niet zomaar een technische wijziging. Het markeert een fundamentele verschuiving in de manier waarop digitale identiteit en vertrouwen op het internet worden beheerd. De deadline van 15 juni 2026 staat vast en de handhaving is strikt: Chrome zal elke PKI-hiërarchie die in strijd blijkt te zijn met de regels, uitfaseren en certificaten weigeren die meer dan 90 dagen na de constatering van een overtreding zijn uitgegeven.

Als uw organisatie nog steeds openbare certificaten gebruikt voor clientauthenticatie, is het nu tijd om actie te ondernemen. De weg vooruit is duidelijk: voer een audit uit van uw certificatenportfolio, implementeer een private CA, migreer authenticatieworkflows en implementeer certificaatlevenscyclusbeheer om het proces te automatiseren en toekomstige hiaten te voorkomen. In combinatie met de verkorte levensduur van certificaten volgens het CA/Browser Forum (47 dagen in 2029), is de noodzaak voor geautomatiseerd CLM nog nooit zo groot geweest.

Veelgestelde Vragen / FAQ

Wat is de belangrijkste conclusie uit dit bericht over Chrome Root Program Policy v1.6?

Vanaf 15 juni 2026 zal Chrome elk nieuw, publiekelijk vertrouwd TLS-certificaat weigeren dat de volgende inhoud bevat: id-kp-clientAuth EKU. Organisaties die openbare CA's gebruiken voor VPN-, Wi-Fi-, mTLS- of SSO-authenticatie, moeten deze workflows vóór deze datum migreren naar een privé-CA. Bestaande certificaten blijven geldig tot hun natuurlijke vervaldatum, maar nieuwe dual-EKU-certificaten worden niet meer vertrouwd.

Waarom is Chrome Root Program Policy v1.6 belangrijk voor PKI-teams binnen bedrijven?

Enterprise PKI-teams moeten elk certificaat in hun omgeving controleren op de clientAuth EKU, vaststellen welke services ervan afhankelijk zijn en een migratie naar een private CA plannen vóór 15 juni 2026. Als er niet wordt gehandeld, worden nieuwe certificaten die na deze deadline worden uitgegeven, door Chrome geweigerd, waardoor VPN-, Wi-Fi-, mTLS API- en SSO-authenticatieprocessen binnen de organisatie ongemerkt worden verbroken.

Welke risico's nemen toe als deze migratie handmatig wordt uitgevoerd?

Handmatige methoden brengen het risico met zich mee van gemiste certificaatvernieuwingen, een onvolledige inventarisatie van de betreffende certificaten en ongecoördineerde migraties waardoor sommige services na de deadline nog steeds gebruikmaken van niet-conforme certificaten. Volgens de Trust Pulse Survey van DigiCert (2 juli 2025) heeft bijna de helft van de bedrijven het afgelopen jaar te maken gehad met downtime als gevolg van certificaatproblemen. Zonder geautomatiseerde detectie en lifecyclemanagement lopen organisaties het risico op authenticatiefouten en serviceonderbrekingen.

Welke teams moeten verantwoordelijk zijn voor de migratie naar Chrome v1.6?

PKI-beheerders zijn verantwoordelijk voor de implementatie van de private CA en de workflows voor certificaatuitgifte. Beveiligingsarchitecten definiëren het nieuwe authenticatievertrouwensmodel en het certificaatbeleid. Platform- en DevOps-teams werken CI/CD-pipelines, service meshes en Kubernetes-workloads bij om certificaten van private CA's te gebruiken. Compliance-teams controleren of alle betrokken certificaten zijn geïnventariseerd en gemigreerd. CISO's zijn verantwoordelijk voor het deadline-risico en moeten ervoor zorgen dat de migratie gefinancierd en als formeel project wordt gevolgd.

Hoe is Chrome Root Program Policy v1.6 gekoppeld aan certificaatlevenscyclusbeheer?

De migratie vereist het opsporen van alle certificaten met de clientAuth EKU, het bijhouden van hun vervaldatum, het migreren van de uitgifte naar een private CA en het waarborgen dat toekomstige verlengingen voldoen aan het nieuwe beleid. Dit is precies waarvoor CertSecure Manager is ontworpen: geautomatiseerde detectie, beleidshandhaving en verlenging in alle omgevingen. Zonder CLM kunnen teams hun risico's niet betrouwbaar controleren of de migratie op grote schaal uitvoeren.

Hoe moeten organisaties het succes na een migratie meten?

Succesindicatoren zijn onder andere: nul publiekelijk vertrouwde TLS-certificaten met de clientAuth EKU die na 15 juni 2026 zijn uitgegeven; 100% van de clientauthenticatieworkflows die worden afgehandeld door privécertificaten uitgegeven door een certificeringsinstantie; geen authenticatiefouten tijdens de migratie; een volledig certificaatoverzicht met eigenaar, vervaldatum en CA-bron, bijgehouden in een CLM-platform; en auditbewijs dat bevestigt dat alle getroffen certificaten zijn vervangen.

Wat moet er na de migratie regelmatig worden gecontroleerd of gemonitord?

Continue monitoring: certificaatuitgifte om ervoor te zorgen dat er geen clientAuth EKU in openbare TLS-certificaten voorkomt; vervaldatums voor alle gemigreerde certificaten; en nieuwe service-implementaties die mogelijk onbedoeld certificaten aanvragen bij een openbare CA. Kwartaalcontrole: volledige certificaatinventarisatie voor EKU-conformiteit, nauwkeurigheid van de CA-bron en eigendomstoewijzing. Gebruik CertSecure Manager om beleid af te dwingen en automatisch auditrapporten te genereren.

Welke invloed heeft Chrome Root Program Policy v1.6 op cloud-, hybride- of multi-CA PKI-omgevingen?

In hybride en multi-CA-omgevingen kunnen certificaten van openbare en private CA's naast elkaar bestaan, waardoor het gemakkelijk is om getroffen certificaten over het hoofd te zien tijdens een audit. Cloudworkloads die gebruikmaken van openbare ACME-providers zoals Let's Encrypt voor authenticatieworkflows worden hierdoor ook getroffen. Een uniform CLM-platform dat inzicht biedt in alle CA-bronnen is essentieel om elk certificaat met de clientAuth EKU te identificeren, ongeacht de uitgever of de implementatieomgeving.

Welke veelgemaakte fouten moeten teams vermijden tijdens een migratie?

De meest voorkomende fouten zijn: ervan uitgaan dat de migratie slechts een klein aantal certificaten betreft zonder een volledige detectie uit te voeren; een private CA implementeren zonder de vertrouwensarchieven van de applicatie bij te werken om deze te vertrouwen; oude publieke certificaten na de migratie niet intrekken; de verlenging van nieuwe private CA-certificaten niet automatiseren; en de authenticatiestromen na de migratie niet testen vóór de deadline van 15 juni 2026.

Wat moet er elk kwartaal worden vernieuwd om aan de regelgeving te blijven voldoen?

Elk kwartaal bijwerken: volledige inventarisatie van certificaten met de clientAuth EKU die mogelijk zijn gemist; privé CA-beleid en certificaatprofielen; configuratie van de vertrouwensopslag op alle clients en services; en CLM-beleidsregels om de uitgifte van niet-conforme certificaten te blokkeren. Controleer ook de pagina Chrome Root Program Policy voor updates, aangezien het beleid al is geüpgraded van versie 1.6 naar de huidige versie 1.8.