Het mandaat van het CA/Browser Forum: Het einde van Dual-EKU-certificaten

CA/Browser Forum-stemming SC-081v3 werd in april 2025 unaniem aangenomen met steun van alle vier de grote forumleden, waaronder Google, Apple, Microsoft en Mozilla , en 25 stemgerechtigde certificeringsinstanties. Deze stemming introduceerde een ingrijpende reeks wijzigingen in de TLS Baseline Requirements (TBR's), waarbij de scheiding van Client Extended Key Usage (EKU) een van de meest structureel belangrijke was.

Het Chrome Root Program Policy v1.8 , dat fungeert als handhavingsmechanisme voor de rootcertificaatopslag van Google Chrome , gaat nog een stap verder. Het schrijft niet alleen voor dat bladcertificaten geen clientAuth mogen bevatten, maar dat complete PKI-hiërarchieën moeten worden gereorganiseerd. Dit houdt in dat intermediaire CA's die verbonden zijn met rootcertificaten in de Chrome Root Store geen dubbele EKU-waarden meer mogen hebben. De scheiding moet plaatsvinden op CA-niveau, niet alleen op certificaatniveau.

Voordat we dieper ingaan op de vereisten, is het nuttig om eerst de technische basisprincipes te bespreken. Extended Key Usage (EKU) is een veld in een X.509 digitaal certificaat dat de specifieke doeleinden definieert waarvoor de publieke sleutel van een certificaat mag worden gebruikt. Systemen die certificaten valideren, controleren de EKU-waarden om te bepalen of een aangeboden certificaat geautoriseerd is voor de beoogde bewerking.

Er staan ​​twee EKU-waarden centraal in deze opdracht:

• Serverauthenticatie (OID 1.3.6.1.5.5.7.3.1): Geeft aan dat het certificaat geldig is voor de authenticatie van een server bij een client. Dit is wat uw HTTPS-website gebruikt. Browsers controleren deze EKU bij het tot stand brengen van een TLS-verbinding.
• Clientverificatie (OID 1.3.6.1.5.5.7.3.2): Geeft aan dat het certificaat geldig is voor authenticatie van een client bij een server. Dit wordt gebruikt in mTLS, apparaatauthenticatie en scenario's waarbij de client zijn identiteit moet bewijzen in plaats van alleen de server.

Openbare certificeringsinstanties gaven TLS-certificaten uit die dubbele EKU-waarden bevatten . Het certificaat ziet er als volgt uit:

Eén certificaat bevatte zowel serverAuth als clientAuth . Deze dubbele EKU-praktijk was handig; één certificaat kon twee functies vervullen, maar het was architectonisch onverantwoord en het CA/Browser Forum heeft het nu formeel uit de openbare PKI verwijderd.

Kort antwoord: Wat houdt de verplichting tot het behalen van het Dual-EKU-certificaat in?

De verplichting tot dual-EKU-certificaten van het CA/Browser Forum SC-081v3 (april 2025) en het Chrome Root Program Policy v1.8 schrapt clientAuth uit publiekelijk vertrouwde TLS-certificaten. Vanaf 15 juni 2026 mag geen enkele nieuwe intermediaire CA nog dual-EKU-waarden bevatten. Vanaf 15 maart 2027 moet elk nieuw uitgegeven publiekelijk vertrouwd TLS-bladcertificaat alleen nog serverAuth bevatten . Clientauthenticatie moet overgaan naar een dedicated private PKI-hiërarchie.

Key Takeaways

• CA/Browser Forum Ballot SC-081v3 werd in april 2025 unaniem aangenomen met steun van Google, Apple, Microsoft, Mozilla en 25 stemgerechtigde CA's. Chrome Root Program Policy v1.8 dwingt de scheiding af op het niveau van de CA-hiërarchie, niet alleen op het niveau van het bladcertificaat. Vanaf 15 juni 2026 mag geen enkele nieuwe intermediaire CA die aan de CCADB wordt bekendgemaakt, zowel serverAuth als clientAuth bevatten. Vanaf 15 maart 2027 moet elk nieuw uitgegeven, publiekelijk vertrouwd TLS-bladcertificaat alleen de serverAuth EKU bevatten.
• Uit de DigiCert Trust Pulse Survey (2 juli 2025) bleek dat 45 procent van de organisaties in het voorgaande jaar te maken had met uitval als gevolg van certificaatproblemen, en dat 37.5 procent de oorzaak van de storing toeschreef aan een verlopen certificaat. De verplichting tot dubbele EKU introduceert een nieuwe en moeilijker te diagnosticeren foutmodus: een certificaat dat is vernieuwd zonder clientAuth is geldig, niet verlopen en vertrouwd, maar faalt stilzwijgend bij alle clientauthenticatie met generieke fouten (TLS-handshake mislukt, toegang geweigerd, peerverificatie mislukt) die de ontbrekende EKU niet als oorzaak aanwijzen.
• CA/Browser Forum SC-081v3 verlaagt ook de maximale TLS-geldigheidsduur van 200 dagen (maart 2026) naar 100 dagen (maart 2027) naar 47 dagen (maart 2029). Bij een geldigheidsduur van 47 dagen wordt een certificaat ongeveer acht keer per jaar vernieuwd. Elke vernieuwing van een dual-EKU-certificaat dat nog niet is gemigreerd naar een private PKI, vormt een potentieel stille authenticatiestoring. De verplichting en de verkorting van de geldigheidsduur volgen hetzelfde schema, wat het risico vergroot voor organisaties die de ontdekking en migratie uitstellen.
• Acht gebruikscategorieën worden geconfronteerd met verstoringen: wederzijdse TLS (mTLS), RADIUS- en IEEE 802.1X-netwerkauthenticatie, certificaatgebaseerde VPN (OpenVPN, Cisco Secure Client, Fortinet), server-naar-servercommunicatie met Microsoft Exchange, Remote Desktop en RDP Gateway, IoT en apparaatidentificatie, API- en server-naar-serverauthenticatie, en CI/CD- en DevOps-workloads. De gevaarlijkste afhankelijkheden zijn de ongedocumenteerde: systemen die afhankelijk zijn van clientAuth omdat openbare certificaten dit historisch gezien standaard bevatten, zonder dat deze afhankelijkheid formeel is vastgelegd.
• NIST FIPS 203, 204 en 205 (definitief vastgesteld op 13 augustus 2024) vereisen de vervanging van RSA- en elliptische-curve-algoritmen in alle PKI-hiërarchieën volgens de NIST IR 8547-afschrijvingstermijn. Privé-CA-hiërarchieën die zijn gebouwd om te voldoen aan het dual-EKU-mandaat moeten ook post-quantum migratieplanning voor privé-CA-sleutelalgoritmen omvatten. Volg de migratievereisten voor privé-CA-sleutelalgoritmen via de PQC Centrum van Uitmuntendheid.

Wie zou zich druk moeten maken over het Dual-EKU-mandaat?

Het mandaat voor dubbele EKU is geen wijziging van een certificaatsjabloon. Het is een wijziging in de PKI-architectuur die gecoördineerde actie vereist van PKI-teams, beveiligingsarchitecten, platformontwikkelaars, compliance-teams en CISO's. Elk team is verantwoordelijk voor een specifiek onderdeel van de transitie, en tekortkomingen op welk gebied dan ook leiden tot de stille authenticatiefouten die het grootste operationele risico van het mandaat vormen.

Rol	Waarom het uitmaakt	Actie-item
PKI- en certificeringsteams	Beheer het ontwerp van de private CA-hiërarchie en de scheiding van certificaatsjablonen: het Chrome Root Program Policy v1.8 vereist scheiding op CA-niveau, niet alleen op het niveau van het bladcertificaat. Dit betekent dat PKI-teams een private hiërarchie moeten ontwerpen en beheren met dedicated uitgevende CA's voor clientauthenticatie (alleen clientAuth EKU, geen serverAuth), gescheiden van de publieke TLS-hiërarchie (alleen serverAuth). Standaard CA-platformen voor bedrijven vereisen expliciete sjabloonconfiguratie om EKU-scheiding af te dwingen en dubbele EKU-uitgifte te voorkomen. De deadline van 15 maart 2027 is absoluut voor nieuw uitgegeven certificaten, zonder mogelijkheid tot verlenging voor organisaties die de migratie nog niet hebben voltooid.	Controleer de volledige certificateninventaris op openbaar vertrouwde certificaten die zowel de EKU-waarden serverAuth als clientAuth bevatten. CertSecure Manager; ontwerp de private CA-hiërarchie met dedicated uitgevende CA's voor clientauthenticatie, gebruikersidentiteit, apparaatidentiteit en workloadidentiteit; configureer certificaatsjablonen om EKU-scheiding af te dwingen (openbare sjablonen alleen voor serverAuth, privésjablonen alleen voor clientAuth) waarbij dubbele EKU-uitgifte niet mogelijk is; gebruik CBOM Secure voor een volledige ontdekking van cryptografische activa, inclusief alle door CA's uitgegeven certificaten in cloud-, on-premises- en multi-cloudomgevingen; evaluatie PKIaaS voor de private CA-hiërarchie als de interne PKI-capaciteit beperkt is
Beveiligingsarchitecten	Beheer het PKI-architectuurbeheer: de opdracht vereist niet alleen een nieuwe certificaatsjabloon, maar ook een nieuwe private CA-hiërarchie met een eigen root-CA, uitgevende CA's, HSM-ondersteunde sleutelbescherming, een strategie voor de distributie van de vertrouwensopslag, een CRL/OCSP-infrastructuur en de selectie van het inschrijvingsprotocol. Beveiligingsarchitecten moeten ook de grens ontwerpen tussen openbare TLS-certificaten (alleen serverAuth, door de browser vertrouwd) en private clientcertificaten (alleen clientAuth, privé vertrouwd) om ervoor te zorgen dat geen enkel systeem een ​​openbaar certificaat kan gebruiken voor clientauthenticatie en vice versa. De post-quantummigratie van private CA-sleutelalgoritmen (ECDSA naar ML-DSA volgens NIST FIPS 204, definitief vastgesteld op 13 augustus 2024) moet ook worden meegenomen in de architectuurontwerpfase.	Ontwerp de architectuur van de private CA-hiërarchie: offline root-CA, afzonderlijke uitgevende CA's voor elk authenticatiescenario voor clients (mTLS, apparaat, gebruiker, workload, API), HSM-ondersteunde sleutelbescherming die voldoet aan de FIPS 140-3 Level 3-vereisten, CRL- en OCSP-infrastructuur en een distributieplan voor de trust store; specificeer de inschrijvingsprotocollen voor elk scenario (WSTEP voor machines die zijn gekoppeld aan Windows AD, ACME voor cloud-native workloads, SCEP voor mobiele apparaten/IoT, EST voor algemene inschrijving); plan het migratiepad na de quantum-update voor private CA-sleutelalgoritmen. PQC Centrum van Uitmuntendheid; definieer de beleidsgrens die voorkomt dat een systeem na 15 maart 2027 een openbaar TLS-certificaat gebruikt voor clientauthenticatie.
Platform- en DevOps-teams	Neem de migratie op applicatieniveau in eigen hand: elk systeem dat momenteel een openbaar TLS-certificaat presenteert voor clientauthenticatie, moet opnieuw geconfigureerd worden om in plaats daarvan een privé-clientcertificaat te presenteren. Dit omvat mTLS-endpoints in microservice-architecturen, RADIUS-servers en 802.1X-authenticatie-infrastructuur, VPN-gateways (OpenVPN, Cisco Secure Client, Fortinet), IoT-platforms en apparaatbeheersystemen, Kubernetes-servicemeshconfiguraties, API-gateways met certificaatgebaseerde clientauthenticatie en CI/CD-pipelines die authenticeren bij registries, artifactrepositories en Kubernetes-clusters. Platformteams moeten ook de inschrijving voor privécertificaten (WSTEP, ACME, SCEP, EST) integreren in de workflows voor infrastructuurprovisionering, zodat nieuwe systemen automatisch privé-clientcertificaten ontvangen.	Breng alle mTLS-configuraties, RADIUS-implementaties, VPN-gateways, Kubernetes-servicemeshbeleid, API-gateway-authenticatieconfiguraties en CI/CD-pipelinecertificaatgebruik in kaart om te identificeren welke use cases openbare certificaten presenteren voor clientauthenticatie; herconfigureer elk systeem om een ​​privécertificaat te presenteren dat alleen voor clientauthenticatie is bedoeld, afkomstig uit de nieuwe privé-PKI-hiërarchie; integreer de inschrijving van privécertificaten in infrastructuurprovisioneringspipelines (cert-manager voor Kubernetes, ACME voor cloud-native, WSTEP voor Windows AD-gekoppelde systemen); voeg monitoring van het authenticatiesuccespercentage toe voor mTLS-, RADIUS- en VPN-use cases om fouten bij het verwijderen van clientauthenticatie te detecteren voordat ze leiden tot storingen die klanten treffen.
Compliance	Er moet vóór de deadline van 15 maart 2027 auditbewijs worden overlegd dat de migratie is voltooid: gereguleerde sectoren die mTLS (PCI DSS 4.0 Vereiste 4), certificaatgebaseerde netwerkauthenticatie (HIPAA, DORA) of apparaatidentificatie (CMMC) implementeren, lopen risico op nalevingsproblemen als clientauthenticatiecertificaten worden vernieuwd zonder clientAuth en authenticatiefouten worden herleid tot een niet-conforme certificaatuitgifte; uit de DigiCert Trust Pulse Survey (2 juli 2025) bleek dat 45 procent van de bedrijven te maken had met certificaatgerelateerde downtime, en auditbevindingen met betrekking tot tekortkomingen in certificaatbeheer zijn een direct gevolg van onontdekte dual-EKU-afhankelijkheden.	Neem de migratiestatus van dual-EKU op in het driemaandelijkse compliance-bewijspakket: het percentage publiekelijk vertrouwde certificaten dat nog steeds clientAuth bevat, het percentage clientauthenticatie-usecases dat is gemigreerd naar privécertificaten en incidenten met authenticatiestoringen die toe te schrijven zijn aan de verwijdering van clientAuth; koppel de deadline voor de intermediate CA op 15 juni 2026 en de deadline voor het leaf-certificaat op 15 maart 2027 aan interne compliance-mijlpalen; bevestig dat de private PKI-hiërarchie op aanvraag auditklare rapporten over certificaatbeheer genereert (uitgevende CA, EKU, vervaldatum, eigenaar, inschrijvingsmethode) zonder handmatige samenstelling; controleer de dekking van de geautomatiseerde inschrijving voor private CA's, zodat de geldigheidsduur van 47 dagen vanaf maart 2029 geen handmatige verplichtingen voor certificaatvernieuwing met zich meebrengt.
CISO's	Het dual-EKU-mandaat vormt een operationeel risico op bestuursniveau: authenticatiefouten als gevolg van het verwijderen van clientAuth zullen zich niet manifesteren als certificaatfouten, maar als TLS-handshakefouten, berichten over geweigerde toegang, verlies van VPN-verbinding, offline-gebeurtenissen van IoT-apparaten en CI/CD-pipelinefouten zonder duidelijke oorzaak; uit de DigiCert Trust Pulse Survey (2 juli 2025) bleek dat 37.5 procent van de certificaatgerelateerde storingen te wijten was aan verlopen certificaten, maar de dual-EKU-foutmodus is moeilijker te diagnosticeren dan een verlopen certificaat, omdat het certificaat geldig blijft; de verkorte geldigheidsperiode (47 dagen tot maart 2029) betekent dat vernieuwingsevenementen acht keer per jaar plaatsvinden, waardoor de blootstelling aan onontdekte afhankelijkheden toeneemt.	Financier een programma voor het opsporen en inventariseren van certificaten met behulp van CertSecure Manager Als onmiddellijke prioriteit, voltooid vóór 15 juni 2026; financier de opbouw van de private PKI-hiërarchie of de PKIaaS-implementatie voordat de deadline voor de intermediaire CA noodmaatregelen afdwingt; vereis dat de status van de dual-EKU-migratie, de dekking van de automatisering van de private PKI-inschrijving en de statistieken over authenticatiestoringen die toe te schrijven zijn aan certificaatfouten, worden gerapporteerd als KPI's op bestuursniveau; evalueer PKI als een service Om te voorkomen dat de private CA-hiërarchie onder tijdsdruk een HSM-infrastructuur moet bouwen en beheren, moet worden vastgelegd dat de planning voor de post-quantummigratie van private CA-sleutelalgoritmen wordt opgenomen in de jaarlijkse PKI-programma-evaluatie.

Checklist voor de overgang naar Dual-EKU: Probleem, impact op de bedrijfsvoering, aanbevolen actie en verantwoordelijke

Gebruik deze checklist vóór de deadline voor de tussentijdse CA op 15 juni 2026 en de deadline voor het bladcertificaat op 15 maart 2027 om overgangskloven te identificeren, de zakelijke impact van elke kloof te begrijpen en de verantwoordelijkheid voor de herstelmaatregelen toe te wijzen.

Issue	Business Impact	Aangeraden actie	Eigenaar
Er is geen inventaris van certificaten die zowel de EKU-waarden serverAuth als clientAuth bevatten.	Organisaties kunnen niet vaststellen welke certificaten stilletjes hun clientAuth-rechten verliezen bij verlenging; ontdekking na de deadline betekent dat er onder druk van een storing moet worden gecompenseerd in plaats van dat er een geplande migratie plaatsvindt; uit de DigiCert Trust Pulse Survey (juli 2025) bleek dat 45 procent van de bedrijven te maken had met downtime als gevolg van certificaatproblemen, en onontdekte dual-EKU-afhankelijkheden zijn de belangrijkste oorzaak van die downtime voor deze verplichting.	Implementeren CertSecure Manager Voor volledige certificaatdetectie in alle CA-bronnen, inclusief openbare CA's, AWS Private CA, Azure Key Vault, HashiCorp Vault PKI en on-premises AD CS; filter de inventaris op certificaten met zowel OID 1.3.6.1.5.5.7.3.1 als OID 1.3.6.1.5.5.7.3.2; koppel elk certificaat met twee EKU's aan het systeem dat het presenteert en het systeem dat erop vertrouwt voor clientauthenticatie; genereer een risicogerangschikte migratietijdlijn op basis van vervaldatums.	PKI-team + CISO
Geen private PKI-hiërarchie voor clientauthenticatiecertificaten.	Zonder een eigen CA is er geen conforme bron voor clientAuth-certificaten; organisaties staan ​​voor een harde deadline (15 maart 2027) zonder alternatief: openbare CA's kunnen na die datum geen clientAuth-certificaten meer uitgeven en er is geen respijtperiode voor organisaties die nog geen eigen CA hebben opgezet.	Ontwerp en implementeer een private CA-hiërarchie met dedicated uitgevende CA's voor clientauthenticatie; bescherm de private CA-sleutels met een FIPS 140-3 Level 3 HSM; configureer certificaatsjablonen met alleen clientAuth EKU en zonder serverAuth; of schakel Encryption Consulting in. PKIaaS voor een volledig beheerd particulier CA-kantoor dat is gebouwd, geëxploiteerd en voldoet aan alle regelgeving binnen strakke deadlines.	PKI-team + beveiligingsarchitect
De privé root CA wordt niet gedistribueerd naar alle systemen van de vertrouwende partijen.	Clientcertificaten uitgegeven door de private PKI worden geweigerd door systemen die de private root-CA niet hebben geïnstalleerd; authenticatiefouten treden op, zelfs als het certificaat correct is geconfigureerd met clientAuth, omdat het ontvangende systeem de uitgevende CA-keten niet vertrouwt.	Distribueer de privé root-CA naar alle Windows-systemen die lid zijn van een domein via Groepsbeleid (opslag voor vertrouwde root-certificeringsinstanties); distribueer naar Linux-systemen via update-ca-certificates met Ansible, Chef of Puppet; distribueer naar mobiele en IoT-systemen via MDM; test de authenticatie op representatieve systemen voordat productieworkloads worden gemigreerd; documenteer het plan voor de vertrouwensdistributie en bevestig de dekking vóór elke migratiefase.	Platformteam + PKI-team
Gebruiksscenario's voor clientauthenticatie bij handmatige certificaatvernieuwing	Met een maximale TLS-validiteit van 47 dagen vanaf maart 2029 leidt handmatige verlenging van clientcertificaten tot acht verlengingsmomenten per jaar per certificaat. Handmatige processen met deze frequentie zijn operationeel onhoudbaar en introduceren acht mogelijke uitvalmomenten per certificaat per jaar als een verlenging wordt gemist of vertraagd.	Registreer alle private clientcertificaten voor geautomatiseerde verlenging met behulp van het juiste registratieprotocol: WSTEP voor machines die zijn gekoppeld aan Windows AD (zero-touch via GPO), ACME voor cloud-native en gecontaineriseerde workloads, SCEP voor mobiele en IoT-apparaten, EST voor algemene registratie; integreer de registratie in de infrastructuurprovisioneringspipelines, zodat nieuwe systemen automatisch private clientcertificaten ontvangen zonder handmatige tussenkomst van het PKI-team.	Platformteam + PKI-team
Er is geen monitoring van het succespercentage van authenticatie voor mTLS, RADIUS en VPN.	Fouten bij het verwijderen van ClientAuth manifesteren zich als algemene fouten (TLS-handshakefout, toegang geweigerd, peerverificatiefout, authenticatietime-out) die gemakkelijk verkeerd gediagnosticeerd kunnen worden als netwerk-, cipher suite- of applicatieconfiguratieproblemen; zonder specifieke monitoring van het authenticatiesuccespercentage wordt de hoofdoorzaak pas na langdurige downtime vastgesteld.	Voeg monitoring van het authenticatiesuccespercentage toe voor alle mTLS-eindpunten, RADIUS-authenticatiegebeurtenissen, VPN-verbindingspogingen en IoT-apparaat-check-ins; configureer waarschuwingen voor wijzigingen in het authenticatiefoutpercentage die correleren met gebeurtenissen voor certificaatvernieuwing; neem EKU-validatie op in certificaatstatuscontroles, zodat een vernieuwd certificaat zonder clientAuth wordt gemarkeerd voordat het een authenticatiefout in de productieomgeving veroorzaakt.	Platformteam + Beveiligingsarchitect
Algoritmen voor privé-CA-sleutels zijn niet opgenomen in het post-quantummigratieplan.	NIST FIPS 203/204/205 (definitief vastgesteld op 13 augustus 2024) vereisen de vervanging van RSA en ECC in alle PKI-hiërarchieën volgens de NIST IR 8547-afschrijvingstermijn; een private CA-hiërarchie die is opgebouwd vóór de dual-EKU-deadline zonder post-quantum-algoritmeplanning moet opnieuw worden opgebouwd of van nieuwe sleutels worden voorzien vóór de afschrijvingsdeadline, wat de migratielast vergroot.	Classificeer private CA-sleutelalgoritmen (RSA, ECDSA P-256/P-384) aan de hand van de NIST IR 8547-afschrijvingsmijlpalen tijdens het architectuurontwerp; plan de migratie naar ML-DSA (FIPS 204) voor CA-ondertekeningssleutels; gebruik CBOM Secure om alle cryptografische activa in de private PKI-hiërarchie te ontdekken; migratievereisten te volgen via de PQC Centrum van Uitmuntendheid; evalueren PQC-gereedheid diensten voor een gestructureerde migratiebeoordeling	Beveiligingsarchitect + PKI-team

Het mandaat: Wat SC-081 en het Chrome Root-programma vereisen

Openbare certificeringsinstanties mogen geen TLS-servercertificaten meer uitgeven die de uitgebreide sleutelgebruiksregel clientAuth bevatten. Tussenliggende CA-certificaten die zowel serverAuth als clientAuth ondersteunen en verwijzen naar een publiekelijk vertrouwde root, moeten worden uitgefaseerd.

Elke organisatie die authenticatiecertificaten voor klanten nodig heeft, moet deze verkrijgen via een speciaal daarvoor opgezette PKI-hiërarchie. Dit kan per definitie geen openbare CA-hiërarchie zijn die wordt vertrouwd in de rootcertificatenarchieven van browsers.

De belangrijkste datum voor organisaties is 15 juni 2026. ONDERGESCHIKTE/tussenliggende CA-certificaten: elk nieuw tussenliggend certificaat dat op of na die datum aan CCADB wordt bekendgemaakt, moet alleen serverAuth bevatten, en er mogen geen nieuwe dual-EKU-tussenliggende certificaten worden toegevoegd aan de door Chrome vertrouwde hiërarchieën.

Vanaf 15 maart 2027 moet elk nieuw uitgegeven leaf-certificaat dat is gekoppeld aan een door Chrome vertrouwd rootcertificaat, ook alleen serverAuth ondersteunen. Vanaf dat moment zal Chrome openbare TLS leaf-certificaten die nog steeds de clientAuth EKU bevatten, weigeren, en de betreffende handshakes zullen mislukken. Certificaten die vóór de betreffende deadline zijn uitgegeven, blijven geldig tot de vervaldatum, maar bij verlenging worden ze opnieuw uitgegeven zonder clientAuth.

Om in aanmerking te komen als een dedicated TLS-server authenticatie PKI-hiërarchie onder dit beleid:

1. Alle overeenkomstige niet verlopen en niet ingetrokken Ondergeschikte CA-certificaten die worden beheerd onder een bestaande root die is opgenomen in de Chrome Root Store MOETEN:
   • indien bekendgemaakt aan de CCADB vóór 15 juni 2026: inclusief de uitgebreid sleutelgebruik uitbreiding en (a) alleen een uitgebreid KeyUsage-doel van beweren id-kp-serverAuth of (b) alleen de extendedKeyUsage-doeleinden van id-kp-serverAuth bevestigen en id-kp-clientAuth.
   • indien bekendgemaakt aan de CCADB op of na 15 juni 2026: voeg de extendedKeyUsage-extensie toe en stel alleen een extendedKeyUsage-doel van id-kp-serverAuth in.
   • Bevat GEEN openbare sleutel die overeenkomt met een ander, niet verlopen of niet ingetrokken certificaat dat andere extendedKeyUsage-waarden claimt.
2. Alle bijbehorende abonnementscertificaten zijn uitgegeven. op of na 15 maart 2027, MOET de extendedKeyUsage-extensie bevatten en mag alleen een extendedKeyUsage-doel van id-kp-serverAuth claimen.

Vanaf 15 maart 2027 moet elk nieuw uitgegeven, publiekelijk vertrouwd TLS-certificaat slechts één doel dienen: serverauthenticatie. Het mag alleen de serverAuth EKU bevatten, waarbij de clientAuth OID volledig verwijderd moet zijn. Het openbare CA-certificaat moet er als volgt uitzien:

De volgende tabel geeft de vereiste en toegestane velden weer voor TLS-servercertificaten (leafcertificaten) die zijn uitgegeven door publiekelijk vertrouwde CA's, conform het mandaat van het CA/Browser Forum, 7.1.2.7 Abonneecertificaatprofiel (servercertificaat):

Veld / Uitbreiding	Aanwezigheid	Toegestane waarden en vereisten
versie	MUST	v3 (geheel getal 2)
serienummer	MUST	Positief geheel getal, ten minste 64 bits uitvoer van een CSPRNG.
onderwerpAltNaam	MUST	Deze extensie MOET ten minste één item bevatten. Elk item MOET een van de volgende zijn: dNSName or IP-adres zoals beschreven in sectie 7.1.4.2.
basisbeperkingen	MUST	Voor een inschrijfcertificaat (bladcertificaat), cA veld MOET op FALSE worden ingesteld. padLenConstraint Mag niet aanwezig zijn.
sleutelGebruik	MUST	Het is een cruciaal kenmerk. De acceptabele waarden voor Key Usage variëren afhankelijk van of het certificaat onderwerpOpenbareSleutelInfo identificeert een RSA-publieke sleutel of een ECC publieke sleutel. Certificeringsinstanties MOETEN ervoor zorgen dat het sleutelgebruik geschikt is voor de publieke sleutel van het certificaat. De toegestane sleutelgebruiken zijn: digitale handtekening + sleutelversleuteling voor RSA, en alleen digitale handtekening voor ECDSA
uitgebreid sleutelgebruik	MUST	De volgende waarde MOET aanwezig zijn: • id-kp-serverAuth (OID: 1.3.6.1.5.5.7.3.1) De volgende waarde MAG NIET aanwezig zijn: • id-kp-clientAuth (OID: 1.3.6.1.5.5.7.3.2) – Verboden voor nieuw uitgegeven bladcertificaten vanaf 15 maart 2027 onder Chrome Root Program Policy v1.8, Sectie 1.3.2
certificaatbeleid	MUST	Indien aanwezig, MOET de extensie Certificaatbeleid ten minste één certificaatbeleidsregel bevatten. Beleidsinformatie.
autoriteitInformatieToegang	MUST	Het is geen cruciaal vakgebied. • sleutelidentificatie- Moet aanwezig zijn. Moet identiek zijn aan het veld subjectKeyIdentifier van de uitgevende CA. • autoriteitCertificaatUitgever- MAG NIET aanwezig zijn • autorisatieCertificaatSerienummer- MAG NIET aanwezig zijn
onderwerpSleutelIdentifier	MUST	De CA MOET een genereren onderwerpSleutelIdentifier dat uniek is binnen het geheel van alle certificaten die het heeft uitgegeven voor elke unieke publieke sleutel
cRLDistributionPoints	MUST	Deze extensie MOET aanwezig zijn en MAG NIET als kritiek gemarkeerd zijn. De CRL Distribution Points-extensie MOET aanwezig zijn in: • Ondergeschikte CA-certificaten; en • Abonnementscertificaten die 1) niet kwalificeren als "kortstondige abonnementscertificaten" en 2) geen extensie voor toegang tot autoriteitsinformatie bevatten met een id-ad-ocsp accessMethod.

Opmerking over extendedKeyUsage: De CA/Browser Forum TLS Baseline Requirements v2.2.8, sectie 7.1.2.7.10, vermeldt id-kp-clientAuth nog steeds als 'mag', toegestaan ​​maar niet vereist op BR-niveau. Het strikte verbod komt voort uit het Chrome Root Program Policy v1.8, sectie 1.3.2 , dat vereist dat alle abonnementscertificaten die op of na 15 maart 2027 worden uitgegeven, alleen id-kp-serverAuth bevatten. CA's moeten aan dit beleid voldoen om in de Chrome Root Store te blijven, waardoor de beperking praktisch universeel is.

Stemmingsvoorstel SC-081 introduceert ook een gefaseerde verlaging van de maximale geldigheidsduur voor publiekelijk vertrouwde TLS-certificaten. De geldigheidsduur wordt vanaf maart 2026 verlaagd naar 200 dagen, vanaf maart 2027 naar 100 dagen en vanaf maart 2029 naar 47 dagen . Door de kortere geldigheidsduur van certificaten wordt geautomatiseerde registratie via ACME, WSTEP, SCEP en EST een vereiste in plaats van een gemak. Elke organisatie die afhankelijk is van handmatige certificaatvernieuwing zal te maken krijgen met een onhoudbare operationele last naarmate de geldigheidsperioden korter worden. Dit onderstreept de noodzaak van een beheerde private PKI met volledig geautomatiseerd lifecyclemanagement vanaf dag één.

De openbare CA-tijdlijn

De meest cruciale datum voor organisaties is 15 juni 2026. Vanaf dat moment zal Chrome actief openbare TLS-certificaten met de EKU clientAuth weigeren. Elke nieuwe ondergeschikte CA (tussenliggende CA) die op of na deze datum aan de Common CA Database (CCADB) wordt toegevoegd, mag alleen id-kp-serverAuth bevatten . Vanaf deze datum kunnen er geen nieuwe tussenliggende CA's met gemengde EKU's meer worden toegevoegd aan de door Chrome vertrouwde hiërarchieën. Elk systeem dat een dergelijk certificaat presenteert in een door Chrome gevalideerde TLS-handshake zal mislukken. Bestaande certificaten die vóór deze datum zijn uitgegeven, blijven geldig tot de vervaldatum, maar bij verlenging worden ze zonder clientAuth uitgegeven.

Certificeringsinstanties hebben niet gewacht tot de strikte deadline van maart 2027. De meeste grote certificeringsinstanties zijn al ruim voor die datum begonnen met het verwijderen van clientAuth, ingegeven door de deadline van Chrome voor tussentijdse certificeringsinstanties in juni 2026. Hieronder volgt de volledige tijdlijn zoals die er in juni 2026 uitzag:

Datum	CA / Programma	Milestone	Status
15 September 2025	SSL.com	Het standaard uitgeven van clientAuth-verzoeken wordt gestopt.	GESLAAGD
Oktober 1, 2025	DigiCert	Het standaard uitgeven van clientAuth-verzoeken wordt gestopt.	GESLAAGD
Oktober 14, 2025	Sectigo	Het standaard uitgeven van clientAuth-verzoeken wordt gestopt.	GESLAAGD
Februari 11, 2026	Laten we versleutelen	Het standaard ACME-profiel verwijdert clientAuth.	GESLAAGD
15 juni 2026	Google Chrome	Verwerpt openbare TLS-certificaten met clientAuth EKU	KRITISCHE
July 8, 2026	Laten we versleutelen	Het tlsclient-profiel is permanent stopgezet.	BINNENKORT
Februari 10, 2027	Sectigo	Strikte deadline, geen uitzonderingen.	BINNENKORT
1 maart 2027	DigiCert	Volledige verwijdering, zonder uitzonderingen.	BINNENKORT
15 maart 2027	Chrome Root-programma	Uiterste deadline voor de sector	DEADLINE

Waarom wordt de EKU voor clientauthenticatie verwijderd?

Het is verleidelijk om deze verplichting puur als een extra administratieve last te beschouwen. In werkelijkheid dicht het echter een reële en onderschatte beveiligingslacune. Inzicht in de volgende beveiligingsargumenten helpt organisaties te begrijpen waarom deze wijziging wordt doorgevoerd:

• De openbare web-PKI is ontwikkeld voor het authenticeren van servers bij browsers: De domeinvalidatie (DV) en organisatievalidatie (OV) processen die door openbare certificeringsinstanties (CA's) worden gebruikt, zijn ontworpen om domeineigendom en organisatie-identiteit te verifiëren ten behoeve van serverauthenticatie. Ze zijn niet ontworpen om vast te stellen dat een bepaald systeem gemachtigd is om als client te fungeren in een specifieke authenticatiecontext. Het opnemen van clientAuth EKU in een openbaar uitgegeven certificaat impliceert een validatiestandaard die nooit is uitgevoerd.
• Het compromitteren van privésleutels heeft ernstige gevolgen: Wanneer een TLS-servercertificaat zowel serverAuth als clientAuth bevat, kan een gecompromitteerde privésleutel dubbele schade aanrichten. Een aanvaller die de privésleutel van een server bemachtigt, kan zich niet alleen voordoen als die server tegenover clients, maar kan dat certificaat ook presenteren als een geldige clientreferentie aan elk systeem dat de uitgevende CA vertrouwt en controleert op de clientAuth EKU. Eén enkele inbreuk leidt tot laterale verplaatsing. Het verwijderen van clientAuth uit servercertificaten elimineert deze tweede aanvalsvector volledig.
• Scheiding maakt een goed levenscyclusbeheer mogelijk: Servercertificaten en clientcertificaten hebben fundamenteel verschillende levenscyclusvereisten. Servercertificaten zijn gekoppeld aan domeinnamen, worden vernieuwd op openbare infrastructuur en beheerd door webbeheerteams. Clientcertificaten zijn gekoppeld aan systeemidentiteiten en vereisen intrekkingsmogelijkheden die op applicatieniveau worden afgedwongen. Het samenvoegen ervan tot één certificaat maakt het correct beheren van beide lastiger. Scheiding herstelt de duidelijkheid van eigenaarschap en verantwoordelijkheid.

De gevolgen van het verwijderen van de clientauthenticatie-EKU

Het verwijderen van de clientAuth EKU heeft gevolgen voor organisaties die momenteel een publiekelijk vertrouwd TLS-servercertificaat gebruiken voor clientauthenticatie.

Organisaties die openbare certificaten uitsluitend gebruiken voor standaard HTTPS- serverauthenticatie ondervinden over het algemeen geen hinder. Hun websites, portals en publiekelijk toegankelijke applicaties kunnen certificaten blijven gebruiken die alleen de serverAuth EKU bevatten.

Het probleem ontstaat wanneer hetzelfde openbare certificaat ook wordt gebruikt om een ​​gebruiker, apparaat, server, applicatie of workload te authenticeren bij een ander systeem. Wanneer dat certificaat wordt vernieuwd of opnieuw wordt uitgegeven zonder de clientAuth EKU, accepteert het ontvangende systeem het mogelijk niet langer als een geldige clientreferentie.

Belangrijk is dat het certificaat mogelijk nog steeds geldig, niet verlopen en vertrouwd is. De fout treedt op omdat het certificaat niet langer geautoriseerd is voor clientauthenticatie.

Om u te helpen vaststellen wat er mis kan gaan en waarom, geeft de volgende tabel een overzicht van de mogelijke impactgebieden binnen uw organisatie.

Use Case	Potentiële impact
Mutual TLS (mTLS)	Tijdens een mTLS-verbinding kan het ontvangende systeem controleren of het certificaat van de client de clientAuth EKU bevat. Als deze EKU ontbreekt, kan het certificaat worden geweigerd en mislukt de TLS-handshake. Dit kan gevolgen hebben voor microservices, API-gateways, service meshes, business-to-business-integraties en aangepaste applicatie-naar-applicatie-authenticatie. De fout kan zich voordoen als een algemene TLS-handshakefout of certificaatvalidatiefout in plaats van een vervaldatumprobleem.
RADIUS, IEEE 802.1X en EAP-TLS	Bij certificaatgebaseerde netwerkauthenticatie presenteren gebruikers of apparaten een clientcertificaat om hun identiteit te bewijzen. Als de authenticatieserver de clientAuth EKU vereist en het vernieuwde certificaat deze niet bevat, mislukt de authenticatieaanvraag. Hierdoor kunnen de getroffen apparaten mogelijk geen verbinding maken met bedrijfs-Wi-Fi, bekabelde netwerken of VPN-diensten.
OpenVPN, Cisco Secure Client en Fortinet VPN	Bij veel VPN-implementaties op basis van certificaten is het vereist dat het certificaat van de verbindende gebruiker of het apparaat de clientAuth EKU bevat. Als een openbaar certificaat dat eerder voor VPN-authenticatie werd gebruikt, wordt vernieuwd zonder die EKU, kan de VPN-gateway dit weigeren. Gebruikers kunnen dan mogelijk geen beveiligde verbinding voor toegang op afstand tot stand brengen.
Microsoft Exchange en server-naar-servercommunicatie	De SMTP-connector, EWS en partnercommunicatieconfiguraties gebruiken certificaten voor wederzijdse of server-naar-server-authenticatie. Wanneer van de verbindende server wordt verwacht dat het certificaat clientauthenticatie ondersteunt, kan het verwijderen van de clientAuth EKU de authenticatie of de e-mailstroom verstoren. De daadwerkelijke impact hangt af van de Exchange-versie, de connectorconfiguratie en de vereisten voor certificaatvalidatie.
Omgevingen voor extern bureaublad en RDP-gateway	Remote Desktop Gateway gebruikt doorgaans een servercertificaat om zich te authenticeren bij verbindende clients. Omgevingen die echter ook gebruikmaken van certificaatgebaseerde clientauthenticatie, smartcardauthenticatie of aangepaste wederzijdse authenticatiemechanismen, kunnen afhankelijk zijn van specifieke clientcertificaten. Het hergebruiken van een openbaar servercertificaat voor een dergelijk doel kan na verlenging leiden tot authenticatiefouten.
IoT en apparaatidentiteit	IoT-, industriële en embedded apparaten kunnen certificaten gebruiken om zich te authenticeren bij cloudservices, beheerplatformen of apparaatgateways. Als een apparaatcertificaat wordt vernieuwd zonder de vereiste clientAuth EKU, kan het platform de apparaatidentiteit weigeren. Dit kan het inchecken van het apparaat, het verzenden van telemetriegegevens, beheer op afstand, software-updates of het uitvoeren van commando's belemmeren.
API- en server-naar-server-authenticatie	Applicaties en servers fungeren vaak als TLS-clients bij het aanroepen van interne of externe API's. Als ze een openbaar TLS-certificaat presenteren als hun clientidentiteit, kan de ontvangende API het certificaat weigeren zodra clientAuth is verwijderd. Dit kan integraties verstoren, zelfs als hetzelfde certificaat normaal blijft werken voor inkomende HTTPS-verbindingen.
CI/CD- en DevOps-workloads	Buildservers, implementatieagents, containers en automatiseringsplatformen kunnen certificaten gebruiken om zich te authenticeren bij registers, Kubernetes-clusters, artifactrepositories of interne API's. Wanneer een vernieuwd certificaat de clientauthenticatie niet langer ondersteunt, kunnen geautomatiseerde pipelines vastlopen zonder dat er direct een duidelijke oorzaak is die verband houdt met het certificaat.

Waarom deze storingen moeilijk te diagnosticeren kunnen zijn

Het verwijderen van clientAuth levert niet per se een duidelijke melding op dat de EKU ontbreekt. Afhankelijk van de applicatie, het besturingssysteem of de TLS-bibliotheek kan de fout als volgt worden gerapporteerd:

• TLS-handshake mislukt
• Certificaatdoel niet toegestaan
• Niet-ondersteund certificaat
• Ongeldig certificaat
• Toegang geweigerd
• Klantidentiteit afgewezen
• Peerverificatie mislukt
• Authenticatietime-out

Hierdoor kan het probleem gemakkelijk verkeerd worden gediagnosticeerd als een probleem met de vertrouwensketen, de vervaldatum, het netwerk, de cipher suite of de applicatieconfiguratie.

Het grootste risico beperkt zich niet tot certificaten waarvan al bekend is dat ze wederzijdse TLS ondersteunen . Het omvat ook ongedocumenteerde systemen die afhankelijk zijn van de clientAuth EKU , omdat openbare TLS-certificaten deze historisch gezien standaard bevatten.

Organisaties moeten deze afhankelijkheden identificeren voordat de betreffende certificaten worden vernieuwd of opnieuw worden uitgegeven. Wachten tot de vernieuwing kan een routinevervanging van een certificaat veranderen in een onverwachte storing die de applicatieconnectiviteit, netwerktoegang, toegang op afstand of apparaatverificatie beïnvloedt.

De oplossing: overstappen naar een private CA

Openbaar vertrouwde certificeringsinstanties mogen geen TLS-certificaten meer uitgeven voor clientauthenticatie (dat wil zeggen, certificaten die de clientAuth EKU bevatten). Hierdoor kunnen organisaties niet langer vertrouwen op openbare TLS-certificaten voor interne clientauthenticatie, zoals wederzijdse TLS, apparaatauthenticatie, workloadidentificatie, API-authenticatie en server-naar-servercommunicatie.

Een private PKI biedt een oplossing voor dit probleem, omdat deze buiten het door browsers vertrouwde publieke PKI-ecosysteem opereert. De root-CA wordt alleen vertrouwd door de gebruikers, apparaten, applicaties en systemen die door de organisatie zijn geselecteerd. Hierdoor kan de organisatie specifieke clientcertificaten uitgeven die de clientAuth EKU bevatten, zonder dat dit ten koste gaat van of afhankelijk is van het publieke browservertrouwen.

Een private PKI maakt ook een goede scheiding mogelijk tussen de twee certificaatdoeleinden:

• Openbare of privé servercertificaten die alleen de serverAuth EKU bevatten.
• Speciale privéclientcertificaten die alleen de clientAuth EKU (OID 1.3.6.1.5.5.7.3.2) bevatten, zonder serverAuth OID, zoals weergegeven in de onderstaande schermafbeelding:

Deze scheiding zorgt ervoor dat een servercertificaat alleen wordt gebruikt om een ​​server te authenticeren, terwijl een clientcertificaat alleen wordt gebruikt om een ​​gebruiker, apparaat, applicatie of werkstation te authenticeren. Het vermindert de impact van een inbreuk op de privésleutel en biedt meer controle over de uitgifte, het eigendom, de verlenging en de intrekking van certificaten.

Met een private PKI kunnen organisaties ook certificaatbeleid definiëren dat voldoet aan hun specifieke beveiligingsvereisten, waaronder procedures voor identiteitsvalidatie, geldigheidsperioden van certificaten, naamgevingsconventies, goedgekeurde algoritmen, vereisten voor sleutelbescherming en inschrijfmethoden. Certificaten kunnen automatisch worden uitgegeven en verlengd met behulp van protocollen zoals ACME, SCEP, EST, CMP, WSTEP of Microsoft Auto-Enrollment.

Deze verschuiving stelt organisaties in staat authenticatieworkflows te ontwerpen die zijn afgestemd op hun specifieke behoeften, zonder gebonden te zijn aan de beperkingen van openbare CA's. In het volgende gedeelte wordt beschreven hoe de PKI-hiërarchie eruit zou moeten zien.

Hoe de PKI-hiërarchie moet veranderen

Het verwijderen van de clientAuth EKU uit publiekelijk vertrouwde TLS-certificaten is niet zomaar een wijziging van de certificaatsjabloon. Het vereist dat organisaties de authenticatie van de publieke server scheiden van de authenticatie van de interne client op het niveau van de PKI-architectuur.

Volgens het nieuwe model mogen publiekelijk vertrouwde certificaten alleen worden gebruikt voor de authenticatie van servers bij externe clients, zoals browsers die verbinding maken met websites en publiekelijk toegankelijke applicaties. Deze certificaten bevatten alleen de serverAuth EKU en de certificaatketen loopt door naar een publiekelijk vertrouwde root-CA.

Clientauthenticatie moet worden verplaatst naar een aparte, private PKI-hiërarchie. Deze private hiërarchie verstrekt doelspecifieke certificaten aan gebruikers, apparaten, applicaties, workloads en servers die zich als client moeten authenticeren.

De beoogde architectuur moet daarom het volgende omvatten:

• Een openbare TLS PKI-hiërarchie voor servercertificaten die toegankelijk zijn via internet en die alleen serverAuth-certificaten bevat.
• Een privé, offline, niet aan een domein gekoppelde root-CA, beveiligd met een FIPS 140-3 Level 3-compatibele hardwarebeveiligingsmodule.
• Een of meer particuliere certificeringsinstanties (CA's) die specifiek zijn bedoeld voor clientauthenticatie. Beveiliging van de privésleutels van de uitgevende CA's met behulp van een HSM (Hardware Security Module).
• Clientcertificaatprofielen die alleen zijn gekoppeld aan de clientAuth EKU (geen serverAuth OID aanwezig), met Key Usage ingesteld op digitalSignature, waardoor het certificaat onder geen enkele omstandigheid kan worden gebruikt voor serverauthenticatie.

  

• Aparte certificaatprofielen voor apparaten, gebruikers, workloads, API's en andere identiteiten.
• CRL- of OCSP-services voor het intrekken van certificaten, waarbij CDP-eindpunten openbaar of privé worden geconfigureerd, afhankelijk van het gebruiksscenario en de toegankelijkheidsvereisten van de organisatie.
• Geautomatiseerde certificaatregistratie, -vernieuwing en -intrekking
• Distributie van de private root-CA naar systemen die de clientcertificaten moeten vertrouwen.

In deze architectuur heeft een server die beide rollen vervult mogelijk twee aparte certificaten nodig:

1. Een servercertificaat met serverAuth voor het accepteren van inkomende TLS-verbindingen.
2. Een clientcertificaat met clientAuth voor authenticatie bij het verbinden met een ander systeem.

Deze scheiding zorgt ervoor dat elk certificaat en elke privésleutel een duidelijk omschreven doel heeft. Het stelt organisaties ook in staat om verschillende beleidsregels voor identiteitsvalidatie, levenscyclus, intrekking en sleutelbescherming toe te passen op server- en clientidentiteiten.

Het ontwerpen, implementeren en continu beheren van deze private hiërarchie vereist specialistische PKI-expertise, een veilige HSM-infrastructuur, automatisering van de certificaatlevenscyclus, intrekkingsdiensten, monitoring, noodherstel en doorlopend beleidsbeheer. In het volgende deel van deze blog wordt uitgelegd hoe de PKIaaS van Encryption Consulting een volledig beheerde private CA levert die namens u wordt gebouwd, beheerd en compliant gehouden.

PKIaaS van Encryption Consulting

Het opzetten en beheren van een private PKI-hiërarchie is conceptueel niet complex, maar de uitvoering ervan is veeleisend. Dit omvat onder andere de aanschaf van HSM's, offline root CA-ceremonies, CDP/AIA-toegankelijkheid, automatisering van de certificaatlevenscyclus, beleidsdocumentatie en inschrijvingsprocedures.

De PKI-as-a-Service (PKIaaS) van Encryption Consulting kan strakke deadlines halen en een complete private PKI leveren als beheerde service . Encryption Consulting bouwt, beheert en zorgt voor de naleving van de regelgeving, terwijl u volledig eigenaar blijft.

Geen vendor lock-in: uw privésleutels, CA-hiërarchie en certificaten blijven volledig van u. Mocht u besluiten de PKI naar uw eigen omgeving te migreren, dan zal Encryption Consulting een formele, gedocumenteerde sleuteloverdrachtceremonie uitvoeren. Het materiaal met de privésleutels van de CA wordt veilig overgedragen naar uw HSM met behulp van geauthenticeerde, dubbel gecontroleerde exportprocedures.

Uw bestaande certificaten blijven geldig en hoeven niet opnieuw te worden uitgegeven. Het volledige overdrachtsproces wordt volledig gedocumenteerd en is controleerbaar, waardoor operationele continuïteit en volledig eigendom worden gewaarborgd.

U bent eigenaar van de PKI. Wij bouwen, beheren en exploiteren deze namens u. Hieronder leggen we uit hoe onze samenwerking in zijn werk gaat.

Fase 1: Ontdekking en inventarisatie van certificaten

Voordat Encryption Consulting een nieuwe PKI ontwerpt, ontwikkelt het bedrijf een volledig overzicht van de huidige certificaatomgeving van de klant. Dit is cruciaal, omdat veel systemen afhankelijk zijn van clientAuth zonder dat deze afhankelijkheid formeel is vastgesteld.

We ondersteunen meerdere methoden voor het opsporen van certificaten , waaronder netwerkscans, scans zonder agent en op integratie gebaseerde detectie.

Integratiegebaseerde ontdekking biedt een realtime, gezaghebbend overzicht van certificaatgegevens door rechtstreeks verbinding te maken met certificeringsinstanties en cloudplatformen zoals AWS, Microsoft Azure en Google Cloud. Het kan ook applicatieconfiguraties onderzoeken, inclusief mTLS-instellingen, en integreren met Kubernetes-clusters, platforms voor geheimbeheer zoals HashiCorp Vault en CyberArk Conjur, en CI/CD-pipelines, waaronder GitHub Actions, Jenkins en GitLab.

Aanvullende detectiemogelijkheden omvatten passieve monitoring via proxies, firewalls en netwerktaps; directoryscanning via LDAP en Active Directory; en detectie via configuratiebeheertools zoals Ansible, Chef en Puppet.

De output is een complete inventaris van certificaten met daarin de onderwerpen, SAN's, EKU's, uitgevers en vervaldatums van de certificaten. Elk certificaat dat clientAuth bevat, wordt gekoppeld aan zowel het systeem dat het presenteert als het systeem dat er voor authenticatie op vertrouwt.

De bevindingen worden vervolgens georganiseerd in een risicogerangschikte migratietijdlijn. De klant krijgt een duidelijk beeld van welke systemen mogelijk uitvallen, wanneer ze risico lopen en wat de potentiële impact op de bedrijfsvoering is als een certificaat wordt verlengd zonder clientAuth.

Fase 2: PKI-architectuurontwerp

Er wordt niets gebouwd voordat de architectuur is beoordeeld en goedgekeurd. Elke CA, elk certificaatsjabloon en elk intrekkingspunt wordt op papier gespecificeerd voordat er ook maar één sleutel wordt gegenereerd.

De architectuur omvat doorgaans een offline, niet aan een domein gekoppelde root-CA en afzonderlijke uitgevende CA's voor clientauthenticatie, interne TLS en authenticatie van apparaatidentiteit. Deze scheiding zorgt ervoor dat clientcertificaten alleen clientAuth bevatten.

Certificaatprofielen worden gedefinieerd voor elk gebruiksscenario, inclusief algoritmen, geldigheidsperioden, onderwerp- en SAN-formaten, sleutelgebruik, EKU, beleids-OID's en intrekkings-eindpunten. CRL- en OCSP-locaties worden geconfigureerd als openbaar of privé, afhankelijk van waar de certificaten zullen worden gebruikt.

Dit zorgt voor een duidelijke, doelgerichte hiërarchie zonder dubbele EKU-certificaten en zonder onduidelijkheid over waarvoor elk certificaat bevoegd is.

Fase 3: Ceremonie voor de hoofdcertificeringsinstantie en infrastructuuropbouw

De privésleutel van de Root CA wordt gegenereerd en beveiligd in een FIPS 140-3 Level 3-compatibele Hardware Security Module (HSM). De Root CA blijft veilig gehost in het datacenter en wordt offline gehouden tussen geautoriseerde certificaatondertekeningsbewerkingen. Voor noodherstel wordt een versleutelde en met toegangscontrole beveiligde back-up van het sleutelmateriaal bewaard in een geografisch gescheiden HSM-omgeving.

Encryption Consulting bouwt vervolgens de ondersteunende PKI-infrastructuur op, inclusief beveiligde certificeringsinstanties, OCSP-responders, CRL-publicatieservices en mogelijkheden voor certificaatbeheer.

Fase 4: Distributie van de Trust Store

Certificaten uitgegeven door een private PKI worden alleen vertrouwd wanneer de private root-CA is geïnstalleerd op elk systeem dat ze valideert. In deze fase wordt het nieuwe private root-CA-certificaat gedistribueerd naar alle systemen van de vertrouwende partijen binnen het toepassingsgebied.

Windows-systemen die lid zijn van een domein ontvangen de root-CA via Groepsbeleid, die wordt opgeslagen in de opslagplaats voor vertrouwde rootcertificeringsinstanties. Linux-systemen worden bijgewerkt met behulp van `update-ca-certificates`, dat wordt geïmplementeerd via Ansible, Chef of Puppet, afhankelijk van de bestaande configuratiebeheertoolchain.

Na de distributie worden representatieve systemen getest met behulp van nieuw uitgegeven klantcertificaten. Deze fase is pas voltooid nadat de klant heeft bevestigd dat de certificaatketens betrouwbaar zijn en de authenticatie is geslaagd.

Fase 5: Implementatie van de PKIaaS-gateway

In deze fase wordt de PKIaaS Gateway geïmplementeerd, een set componenten voor inschrijving en beheer die in de eigen infrastructuur van de klant worden geïnstalleerd. De gateway vormt de brug tussen de interne systemen van de klant en de door Encryption Consulting gehoste CA-hiërarchie. Alle certificaataanvragen lopen via de gateway. De privésleutels van de CA blijven te allen tijde in de HSM's van Encryption Consulting; de gateway verwerkt alleen verkeer via het inschrijvingsprotocol en nooit ondertekeningsbewerkingen.

De gateway biedt een WS-Trust Enrollment Protocol (WSTEP)-eindpunt, waardoor volledig geautomatiseerde certificaatinschrijving voor Windows-machines mogelijk is zonder tussenkomst van gebruiker of beheerder. De Certificate Enrollment Policy-service (CEP) is geconfigureerd om te bepalen voor welke certificaatsjablonen de machine in aanmerking komt op basis van de Active Directory-identiteit en het groepsbeleidslidmaatschap.

De webservice voor certificaatinschrijving valideert het verzoek aan de hand van het inschrijvingsbeleid, stuurt het via de PKIaaS-gateway door naar de uitgevende certificeringsinstantie en stuurt het ondertekende certificaat rechtstreeks terug naar de machine, die het vervolgens automatisch in het juiste certificaatarchief installeert. Vanaf de GPO-configuratie vereist de volledige levenscyclus – beleidsdetectie, aanvraag, ondertekening, installatie en verlenging – geen handmatige tussenkomst meer.

Een webgebaseerd dashboard waar geautoriseerde gebruikers certificaten kunnen aanvragen, CSR's kunnen indienen, de certificaatinventaris kunnen doorzoeken, certificaten kunnen verlengen, gecompromitteerde of ongebruikte certificaten kunnen intrekken en de certificaatstatus kunnen bekijken.

Het dashboard omvat op rollen gebaseerde toegangscontrole. Certificaatbeheerders kunnen certificaten aanvragen of intrekken, auditors kunnen rapporten en activiteitenlogboeken bekijken en beheerders kunnen goedgekeurde profielen en inschrijvingsbeleid beheren.

Elke inschrijving, verlenging, intrekking, goedkeuring, configuratiewijziging en beheerdersaanmelding wordt vastgelegd in een controleerbaar activiteitenlogboek.

Fase 6: Certificaatmigratie: Systeem voor systeem

Zodra de vertrouwens- en registratiediensten operationeel zijn, begint Encryption Consulting met het vervangen van de openbare dual-EKU-certificaten door speciale privéclientcertificaten.

De migratie begint met de ontwikkel- en testomgevingen. Vervolgens worden interne services en API's gemigreerd, gevolgd door de netwerkinfrastructuur, inclusief VPN, RADIUS en 802.1X. Bedrijfskritieke systemen, zoals Exchange, kernapplicaties en systemen binnen de organisatie, worden pas gemigreerd nadat de test- en terugdraaiprocedures zijn bevestigd.

Elke certificaataanvraag wordt ingediend via de juiste inschrijfmethode, zoals WSTEP, ACME, SCEP, EST of het beheerdashboard. Het nieuwe certificaat wordt alleen met de clientAuth EKU uitgegeven. De applicatie wordt geconfigureerd om het nieuwe certificaat te presenteren en een end-to-end authenticatietest bevestigt dat de verbinding succesvol is.

Na een succesvolle validatie wordt het oude dual-EKU-certificaat, indien van toepassing, verwijderd of ingetrokken en wordt het nieuwe certificaat automatisch verlengd.

Fase 7: Lopende werkzaamheden en naleving

In deze fase levert PKIaaS ook na de initiële implementatie nog steeds toegevoegde waarde.

Het CLM-platform van Encryption Consulting beheert continu de uitgifte, verlenging en intrekking van certificaten, de publicatie van CRL's, de beschikbaarheid van OCSP's, HSM-monitoring, infrastructuuronderhoud, back-upvalidatie en PKIaaS Gateway-activiteiten.

Inschrijvingsdiensten zoals WSTEP, ACME, SCEP en EST worden continu bijgehouden, zodat certificaten zonder handmatige tussenkomst kunnen worden afgegeven en verlengd.

Encryption Consulting houdt ook de beveiligingsvereisten van relevante organisaties, ontwikkelingen binnen CA/Browser Forums, cryptografische standaarden, algoritmeaanpassingen en updates van certificaatbeleid in de gaten, zoals compatibiliteit met post-kwantumcryptografie . Wanneer een wijziging de omgeving van de klant beïnvloedt, worden de PKI-configuratie en certificaatprofielen vóór de betreffende deadline bijgewerkt.

Conclusie

Het verwijderen van de clientAuth EKU uit publiekelijk vertrouwde TLS-certificaten markeert een fundamentele verschuiving in de manier waarop organisaties certificaatgebaseerde authenticatie moeten beheren. Publieke certificaten blijven websites en externe services beveiligen, maar clientauthenticatie voor gebruikers, apparaten, applicaties en workloads moet overstappen naar een speciaal daarvoor ontworpen private PKI. Organisaties die er niet in slagen verborgen dual-EKU-afhankelijkheden te identificeren, lopen het risico op onverwachte storingen wanneer certificaten worden vernieuwd zonder clientAuth; storingen die zich niet zullen manifesteren als certificaatfouten, maar als authenticatietime-outs, TLS-handshakefouten en berichten over geweigerde toegang zonder duidelijke oorzaak.

De PKIaaS-oplossing van Encryption Consulting biedt een compleet traject voor deze transitie. We beoordelen de bestaande omgeving, identificeren de getroffen systemen, ontwerpen en bouwen de private PKI, beschermen CA-sleutels binnen HSM's, implementeren registratieservices, migreren certificaten en beheren de omgeving continu. Geautomatiseerde registratie via WSTEP, ACME, SCEP en EST zorgt ervoor dat certificaten worden uitgegeven, verlengd en ingetrokken zonder extra operationele lasten.

Om te beginnen met een gratis PKI-gereedheidsbeoordeling, kunt u contact met ons opnemen via [email protected] of naar encryptionconsulting.com/pkiaas gaan.

Veelgestelde Vragen / FAQ

Wat is de belangrijkste conclusie uit het mandaat van het CA/Browser Forum: Het einde van dubbele EKU-certificaten?

CA/Browser Forum Ballot SC-081v3 (april 2025) en Chrome Root Program Policy v1.8 verwijderen clientAuth uit publiek vertrouwde TLS-certificaten volgens een vast schema. Vanaf 15 juni 2026 mag geen enkele nieuwe intermediaire CA in een door Chrome vertrouwde hiërarchie dubbele EKU-waarden bevatten. Vanaf 15 maart 2027 moet elk nieuw uitgegeven publiek vertrouwd TLS-bladcertificaat alleen serverAuth bevatten. Organisaties die publieke certificaten gebruiken voor mTLS, RADIUS, VPN, IoT-apparaatidentificatie of server-naar-server-authenticatie, moeten deze toepassingen vóór deze deadlines migreren naar een dedicated private PKI-hiërarchie, anders riskeren ze stille authenticatiefouten bij het vernieuwen van de betreffende certificaten.

Waarom is de verplichting tot dubbele EKU van belang voor PKI-teams binnen bedrijven?

Enterprise PKI-teams worden geconfronteerd met twee samenlopende problemen die voortkomen uit dezelfde stemming. Uit de DigiCert Trust Pulse Survey (2 juli 2025) bleek dat 45 procent van de organisaties het voorgaande jaar te maken had met downtime als gevolg van certificaatproblemen; de verplichting tot dubbele EKU introduceert precies de stille foutmodus die deze downtime veroorzaakt: een certificaat dat is vernieuwd zonder clientAuth blijft werken voor HTTPS, maar faalt bij alle clientauthenticatiescenario's met generieke fouten. Tegelijkertijd verlaagt SC-081v3 de maximale TLS-validiteit tot 47 dagen tegen maart 2029, wat betekent dat vernieuwingsevenementen die afhankelijkheden van dubbele EKU blootleggen tot wel acht keer per jaar voorkomen in plaats van één keer.

Welke risico's nemen toe als de duale EKU-overgang handmatig of reactief wordt uitgevoerd?

Vier risicocategorieën nemen toe: stille authenticatiestoringen (generieke foutmeldingen die gemakkelijk verkeerd kunnen worden geïnterpreteerd); onontdekte afhankelijkheden (systemen die afhankelijk zijn van clientAuth zonder formele documentatie); verkorte hersteltijd (bij een geldigheidsduur van 47 dagen is de periode tussen verlenging en storing zes weken in plaats van twaalf maanden); en hiaten na de kwantummigratie (private CA-sleutelalgoritmen moeten ook migreren naar ML-DSA volgens NIST FIPS 204, definitief vastgesteld op 13 augustus 2024; een ongeplande private PKI is moeilijker op te nemen in het migratieplan).

Welke teams zouden de dual-EKU-transitie moeten leiden?

De PKI- en certificaatteams zijn verantwoordelijk voor het ontwerp van de private CA-hiërarchie en de scheiding van certificaatsjablonen. Beveiligingsarchitecten zijn verantwoordelijk voor het governance-model: de distributie van vertrouwen in private root-CA's, de selectie van inschrijvingsprotocollen en de planning voor post-quantummigratie van private CA-sleutelalgoritmen. De platform- en DevOps-teams zijn verantwoordelijk voor de migratie op applicatieniveau: het herconfigureren van mTLS-, RADIUS-, VPN-, IoT- en CI/CD-systemen. De compliance-teams zijn verantwoordelijk voor het auditbewijs dat bevestigt dat de migratie vóór de deadline van 15 maart 2027 is voltooid.

Hoe verhoudt de verplichting tot dubbele EKU zich tot het beheer van de certificaatlevenscyclus?

Het mandaat betreft een gebeurtenis in de certificaatlevenscyclus: elk openbaar TLS-certificaat dat momenteel clientAuth bevat, verliest die EKU bij de volgende verlenging. Certificaatdetectie en -inventarisatie zijn essentiële voorwaarden voor veilig levenscyclusbeheer: organisaties die niet weten welke certificaten clientAuth bevatten, kunnen de verlengingslevenscyclus niet veilig beheren zonder het risico te lopen authenticatieproblemen te veroorzaken. CertSecure Manager biedt de CLM-laag: geautomatiseerde detectie van clientAuth-afhankelijkheden, beleidshandhaving bij uitgifte (EKU-gescheiden profielen), geautomatiseerde verlenging via WSTEP/ACME/SCEP/EST, intrekkingsbeheer en rapportage die geschikt is voor audits.

Hoe moeten organisaties het succes van de duale EKU-transitie meten?

Belangrijkste meetwaarden: nul publiekelijk vertrouwde certificaten met zowel serverAuth als clientAuth; 100 procent van de clientauthenticatie-usecases gemigreerd naar privécertificaten met alleen clientAuth; nul authenticatiestoringen als gevolg van het verwijderen van clientAuth bij verlenging; dekkingsgraad van geautomatiseerde inschrijving in privé-PKI's (percentage clientcertificaten dat automatisch wordt verlengd); en classificatie van gereedheid na de kwantumfase (privé CA-sleutelalgoritmen geclassificeerd aan de hand van de NIST IR 8547-mijlpalen voor afschaffing, met een gedefinieerd migratietijdschema). Rapporteer deze gegevens elk kwartaal, conform het deadlineschema van het CA/Browser Forum.

Wat moet er regelmatig gecontroleerd of gemonitord worden?

Continue monitoring: inventarisatie van certificaten voor publiekelijk vertrouwde certificaten die zowel serverAuth als clientAuth bevatten, met waarschuwingen voor verlenging die certificaten met dubbele EKU markeren vóór verlenging; succespercentages van mTLS-, RADIUS-, VPN- en IoT-authenticatie voor vroegtijdige detectie van mislukte verwijderingen van clientAuth. Kwartaalcontrole: percentage clientauthenticatie-usecases gemigreerd naar privécertificaten; dekkingsgraad van geautomatiseerde inschrijvingen van privé-CA's; classificatie van sleutelalgoritmen van privé-CA's volgens NIST FIPS 203/204/205 (afgerond op 13 augustus 2024); volledigheid van het bewijsmateriaal voor naleving vóór de deadline van 15 maart 2027.

Welke gevolgen heeft de verplichting tot dubbele EKU voor cloud-, hybride- of multi-CA PKI-omgevingen?

Cloud- en hybride omgevingen hebben doorgaans de hoogste dichtheid aan onontdekte dual-EKU-afhankelijkheden: microservices die mTLS gebruiken met openbare certificaten, cloud-native workloads die certificaatgebaseerde authenticatie gebruiken voor cloud-API's, Kubernetes-clusters die certificaten gebruiken voor service mesh-identiteit en CI/CD-pipelines die authenticeren bij registries. Omgevingen met meerdere CA's hebben een gecentraliseerde CLM-laag nodig die clientAuth-afhankelijkheden ontdekt voor alle CA-bronnen, niet alleen de openbare CA-inventaris, inclusief AWS Private CA, HashiCorp Vault PKI en Microsoft AD CS.

Welke veelgemaakte fouten moeten teams vermijden?

De meest voorkomende fouten: het niet ontdekken van clientAuth-afhankelijkheden voordat certificaten worden vernieuwd; het behandelen van het mandaat als een wijziging van de certificaatsjabloon zonder de PKI-hiërarchie op CA-niveau te scheiden (het Chrome Root Program Policy vereist scheiding op CA-niveau); het niet distribueren van de private root-CA naar alle vertrouwende systemen vóór de migratie; het opzetten van een private PKI onder tijdsdruk zonder te plannen voor post-quantummigratie van private CA-sleutelalgoritmen; en het niet inschrijven van gemigreerde clientcertificaten in geautomatiseerde vernieuwingsprocessen die een geldigheid van 47 dagen vanaf maart 2029 kunnen garanderen.

Wat moet er elk kwartaal vernieuwd worden?

Driemaandelijks: controleer de certificaatinventaris op publiekelijk vertrouwde certificaten die nog steeds clientAuth bevatten; verifieer of de private root-CA is gedistribueerd naar alle nieuwe systemen die sinds de laatste audit zijn toegevoegd; bevestig de dekking van de geautomatiseerde inschrijving van private CA's voor alle use cases voor clientauthenticatie; classificeer private CA-sleutelalgoritmen aan de hand van de NIST-mijlpalen voor de afschaffing na de quantumperiode (ML-DSA volgens FIPS 204, definitief vastgesteld op 13 augustus 2024); verifieer dat er geen nieuwe dual-EKU intermediate CA's zijn bekendgemaakt aan CCADB in Chrome-vertrouwde hiërarchieën (verboden vanaf 15 juni 2026). Raadpleeg het PQC Center of Excellence voor de planning van de migratie van private CA-sleutelalgoritmen na de quantumperiode.