Bouw een private PKI voor mTLS voordat publieke certificaten de clientAuth-functionaliteit laten vervallen.

Jarenlang was er een handige, onopvallende manier die veel machine-to-machine authenticatie mogelijk maakte: organisaties hergebruikten hun openbare TLS-certificaten voor wederzijdse TLS. Een certificaat dat voor een webserver was uitgegeven, bevatte vaak zowel de uitgebreide sleutel voor serverauthenticatie als voor clientauthenticatie, waardoor hetzelfde certificaat dat een openbaar eindpunt beveiligde, ook een client kon authenticeren tijdens een mTLS-handshake. Deze truc gaat binnenkort niet meer werken en de systemen die ervan afhankelijk zijn, zullen niet met een waarschuwing, maar bij de volgende verlenging falen.

Dit artikel legt de EKU-cliff voor clientauthenticatie uit, waarom deze bestaat, wanneer deze precies toeslaat en wat eraan te doen is. De oplossing voor de meeste getroffen organisaties is om te stoppen met het lenen van openbare certificaten voor clientauthenticatie en een eigen, private PKI op te zetten die specifiek voor dit doel is ontworpen. We bespreken de tijdlijn, de technische reden waarom publiek en privaat vertrouwen uiteenlopen, de risico's van nietsdoen en een praktische route om vóór de deadline een private PKI mTLS te bouwen.

Kort antwoord: Wat is de clientAuth EKU Cliff en hoe kun je deze vermijden?

Openbare certificeringsinstanties verwijderen de clientAuth EKU (OID 1.3.6.1.5.5.7.3.2) uit publiek vertrouwde TLS-certificaten tot en met 2026. mTLS-systemen die openbare dual-EKU-certificaten hergebruikten voor clientauthenticatie, zullen stilzwijgend falen bij verlenging . Particuliere PKI's zijn expliciet vrijgesteld van deze wijziging en kunnen clientAuth-certificaten vrijelijk uitgeven. Ingangsdata: Let's Encrypt 13 mei 2026; Sectigo 15 mei 2026; DigiCert 1 maart 2027; Chrome leaf enforcement 15 maart 2027.

Key Takeaways

• De vervaldatum van clientAuth EKU wordt bepaald door de certificeringsinstantie die uw certificaten verlengt, niet door de door Chrome aangegeven datum. Let's Encrypt verwijdert clientAuth uit certificaten die op of na 13 mei 2026 zijn uitgegeven; Sectigo verwijdert het vóór 15 mei 2026; DigiCert is er op 1 oktober 2025 mee gestopt en zal het volledig verwijderen op 1 maart 2027. De vervaldatum van Chrome voor leaf-certificaten is 15 maart 2027. Systemen die afhankelijk zijn van een Let's Encrypt- of Sectigo-certificaat dat na half mei 2026 wordt verlengd, kunnen maanden vóór de vervaldatum van Chrome al problemen ondervinden.
• Private PKI wordt expliciet niet beïnvloed door de wijziging in het publieke vertrouwen. De uitzondering is technisch gezien expliciet: de verwijdering van de clientAuth EKU is alleen van toepassing op publiekelijk vertrouwde certificaten. Een private CA waarvan de root alleen binnen de eigen organisatieomgeving wordt vertrouwd, kan vrijelijk certificaten met de clientAuth EKU uitgeven, zonder beperkingen van het CA/Browser Forum of het Chrome Root Program. Private PKI is geen noodoplossing; het is de beoogde oplossing.
• Uit de DigiCert Trust Pulse Survey (juli 2025) bleek dat 45 procent van de bedrijven in het voorgaande jaar te maken had met uitval als gevolg van certificaatproblemen. Het onmerkbaar verwijderen van EKU's bij verlenging, waarbij mTLS niet meer werkt omdat een vernieuwd certificaat geen clientAuth meer bevat, is een vorm van ditzelfde uitvalpatroon. De mTLS-storing treedt onverwacht op, omdat het vernieuwde certificaat verder wel geldig is.
• Ontdekking is de eerste en meest urgente taak. Hergebruik van openbare certificaten voor mTLS is vaak ongedocumenteerd, jaren geleden opgezet door teams die inmiddels vertrokken zijn, en ingebed in service-to-service-koppelingen die prima werken totdat een verlenging de EKU verwijdert. Zonder een certificaatinventaris die registreert welke certificaten clientAuth bevatten en waar ze als clientidentiteiten worden gebruikt, kan een organisatie de migratie niet in kaart brengen.
• Het opzetten van een private PKI zonder automatisering van de levenscyclus ruilt het ene probleem in voor het andere. Een private CA die handmatig clientcertificaten uitgeeft, leidt tot een wildgroei aan certificaten en een ongecontroleerde interne vertrouwensbasis. Geautomatiseerde inschrijving via EST, ACME of SCEP en dekking door het CLM-platform vanaf dag één zijn essentiële voorwaarden voor een private PKI die op grote schaal beheerd blijft. Voor planning van de migratie van private clientcertificaatprofielen na de introductie van kwantumalgoritmen, conform NIST FIPS 203, 204 en 205 (13 augustus 2024), raadpleegt u de volgende informatie: PQC Centrum van Uitmuntendheid.

Voor wie is de clientAuth EKU-migratie relevant?

De EKU-wijziging voor clientAuth raakt elk team dat verantwoordelijk is voor mTLS, certificaatbeheer, serviceauthenticatie en infrastructuurbeveiliging. Als de migratie niet vóór de deadline voor verwijdering door een uitgevende CA plaatsvindt, ontstaan ​​er onmerkbare mTLS-authenticatieproblemen die moeilijk te diagnosticeren zijn zonder voorafgaande kennis van de EKU-wijziging.

Rol	Waarom het uitmaakt	Actie-item
PKI- en certificeringsteams	Verantwoordelijk zijn voor het ontwerp en de implementatie van de private CA: het selecteren van het CA-platform, het definiëren van het clientAuth-certificaatprofiel met de juiste EKU (OID 1.3.6.1.5.5.7.3.2), het configureren van HSM-ondersteunde sleutelopslag voor de private root en het instellen van geautomatiseerde inschrijving via EST, ACME of SCEP; tevens verantwoordelijk zijn voor het opsporen van bestaande publieke certificaten die clientAuth ondersteunen binnen het certificaatportfolio voordat de migratie kan worden uitgevoerd.	Voer een volledige certificaatinventarisatie uit met CBOM Secure Alle certificaten met de clientAuth EKU en hun verlengingsdatums identificeren; de privé-CA-hiërarchie ontwerpen met een aparte clientAuth-uitgevende CA, los van de server-CA-hiërarchie; geautomatiseerde inschrijving configureren vóór de migratie van een mTLS-service; alle uitgegeven privé-clientcertificaten toevoegen aan CertSecure Manager vanaf dag een
Beveiligingsarchitecten	Het ontwerpen van het vertrouwensmodel is uw verantwoordelijkheid: bepalen welke systemen de nieuwe private root vertrouwen, ervoor zorgen dat de private root niet per ongeluk wordt verspreid naar openbare vertrouwensarchieven, de private client-CA-hiërarchie scheiden van de publieke server-CA-hiërarchie en het private CA-ontwerp afstemmen op de principes van zero-trust-architectuur. De overgang van openbare dual-EKU-certificaten naar dedicated private clientcertificaten biedt tevens de mogelijkheid om kortstondige clientcertificaten en geautomatiseerde rotatie te implementeren.	Ontwerp een aparte privé-CA-hiërarchie voor clientAuth die gescheiden is van de openbare server-CA-hiërarchie; specificeer dat de privé-root niet mag worden verspreid naar openbare browsers of externe apparaten; definieer de geldigheidsperiode en het rotatiebeleid van het clientcertificaat met behulp van geautomatiseerde inschrijving; neem de cryptografische inventaris van de privé-CA op in CBOM Secure; plan de adoptie van post-kwantumalgoritmen voor privé-clientcertificaatprofielen via PQC-gereedheid beoordeling
Platform- en DevOps-teams	Het integreren van de private CA-inschrijving in serviceprovisioning-pipelines en het bijwerken van mTLS-configuraties om private clientcertificaten te gebruiken in plaats van publieke dual-EKU-certificaten is een uitdaging. In gedistribueerde systemen zoals Kafka, Cassandra en API-gateways, waar certificaatrotatie geautomatiseerd is, kan een enkele vernieuwing zonder de verwachte clientAuth EKU leiden tot authenticatiefouten in een heel cluster als de migratie niet is voltooid vóór de CA-deadline.	Controleer alle serviceprovisioneringspipelines en mTLS-configuraties op verwijzingen naar openbare certificaten die als clientidentiteiten worden gebruikt; werk elke pipeline bij om certificaten aan te vragen bij de nieuwe private CA via EST of ACME; test mTLS-handshakes van begin tot eind met private clientcertificaten voordat de productieservices worden overgezet; voeg monitoring van het succespercentage van mTLS-handshakes toe aan de platformwaarschuwingen.
Compliance	Er moet worden aangetoond dat de migratie is voltooid vóór de deadline voor het verwijderen van clientAuth door de uitgevende CA; CA/Browser Forum Ballot SC-081v3 (goedgekeurd op 14 april 2025) en Chrome Root Program Policy v1.8 (van kracht vanaf 15 juni 2026 voor ondergeschikte CA's, vanaf 15 maart 2027 voor leaf-certificaten) zijn de geldende beleidsdocumenten; een productieomgeving waarin mTLS na de verwijderingsdeadline van de CA nog steeds afhankelijk is van openbare dual-EKU-certificaten, vormt een compliance-tekortkoming ten opzichte van het gepubliceerde industriebeleid.	Neem de voltooiing van de clientAuth EKU-migratie op in het bewijsmateriaal voor PKI-naleving, met deadlines die zijn afgestemd op de verwijderingstermijn van elke uitgevende CA; bevestig dat de private CA CP/CPS het clientAuth-certificaatprofiel en het uitgiftebeleid documenteert; neem de private clientcertificaatpopulaties op in de driemaandelijkse certificaatnalevingscontrole.
CISO's	Interne mTLS-authenticatie die afhankelijk is van het beleid van de publieke CA is gekoppeld aan externe CA-gebeurtenissen en beslissingen van het rootprogramma die niets te maken hebben met interne beveiligingsvereisten; de clientAuth-cliff is het mechanisme van de industrie om de scheiding van server- en clientvertrouwenshiërarchieën af te dwingen; organisaties die de migratie voltooien, verkrijgen een private authenticatie-infrastructuur die ze volledig beheren, losgekoppeld van intrekkingsgebeurtenissen van de publieke CA en wijzigingen in het beleid van het rootprogramma; de planning voor private clientcertificaatalgoritmen na de quantummigratie is de volgende stap.	Financier de clientAuth EKU-migratie als een apart programma met aangewezen verantwoordelijken voor ontdekking, implementatie van een privé-CA, servicemigratie en CLM-beheer; vereis dat PKI als een service wordt geëvalueerd voor organisaties die een beheerde private CA nodig hebben zonder de infrastructuur intern te bouwen en te beheren; vereist dat de private CA vanaf dag één wordt gedekt door CLM-tools; volgt de planning voor de migratie van private clientcertificaten na de quantumcrisis. PQC Centrum van Uitmuntendheid

Checklist voor clientAuth EKU-migratie: probleem, impact op de bedrijfsvoering, aanbevolen actie en verantwoordelijke

Gebruik deze checklist om te bepalen welke migratiehiaten van toepassing zijn op uw omgeving, de zakelijke gevolgen van inactiviteit te begrijpen en de verantwoordelijkheid voor de herstelwerkzaamheden toe te wijzen voordat de verwijderingsdeadline van een uitgevende CA leidt tot een stille mTLS-storing.

Issue	Business Impact	Aangeraden actie	Eigenaar
Er is geen certificaatinventaris beschikbaar waaruit blijkt welke openbare certificaten de clientAuth EKU bevatten.	Migratie is niet te controleren; niet-ontdekte mTLS-afhankelijkheden zorgen voor problemen bij verlenging na de CA-deadline zonder voorafgaande waarschuwing; nooddetectie onder productiedruk is een hoog risico.	Voer een volledige certificaatdetectie uit met CBOM Secure om elk certificaat, de bijbehorende EKU's en de systemen die ervan afhankelijk zijn, in kaart te brengen; koppel de verlengingsdatum van elk clientAuth-certificaat aan de verwijderingsdeadline van de uitgevende CA om de migratievolgorde te prioriteren.	PKI-team
Er is geen private CA ingezet voor clientAuth-uitgifte.	Er bestaat geen conform alternatief wanneer de openbare CA de EKU verwijdert; alle mTLS-afhankelijkheden van openbare dual-EKU-certificaten zullen bij verlenging niet meer werken, zonder vervangende certificaatbron.	Implementeer een privé-CA-hiërarchie met een aparte clientAuth-uitgevende CA, los van de server-CA-hiërarchie; gebruik een beheerde PKIaaS-oplossing om de implementatie te versnellen als de bouwtijd van de interne CA-infrastructuur de migratiedeadline overschrijdt.	PKI-team + beveiligingsarchitect
De privé-CA-root wordt niet beschermd door HSM-ondersteunde sleutelopslag.	Het compromitteren van een onbeveiligde privé-CA-root maakt alle clientcertificaten die eronder zijn uitgegeven ongeldig; herstel vereist het opnieuw uitgeven van alle clientcertificaten en het opnieuw distribueren van de nieuwe root naar alle vertrouwende systemen.	Veranker de privésleutel van de CA-root in een FIPS 140-3 Level 2 of hoger gevalideerde HSM of gebruik een HSM-ondersteunde PKIaaS-oplossing; markeer de privésleutel als niet-exporteerbaar.	PKI-team + beveiligingsarchitect
Er is geen geautomatiseerde inschrijving geconfigureerd voor privéclientcertificaten.	Handmatig beheer van privécertificaten op grote schaal faalt op dezelfde manier als handmatig beheer van openbare certificaten: een wildgroei aan certificaten, gemiste verlengingen en ongecontroleerde vervaldatums leiden tot dezelfde storingen die de migratie juist moest voorkomen.	Configureer EST-, ACME- of SCEP-inschrijving voor alle private clientcertificaatpopulaties voordat u mTLS-services migreert; integreer de inschrijving in serviceprovisioneringspipelines, zodat private clientcertificaten automatisch worden uitgegeven en verlengd zonder handmatige stappen.	PKI-team + platformteam
De mTLS-serviceconfiguraties zijn niet bijgewerkt om privéclientcertificaten te gebruiken.	Zelfs nadat de private CA is geïmplementeerd, zullen services die nog steeds geconfigureerd zijn om publieke dual-EKU-certificaten als clientidentiteiten te presenteren, bij de volgende verlenging niet meer werken wanneer het publieke certificaat niet langer clientAuth bevat.	Controleer alle mTLS-serviceconfiguraties en werk ze bij zodat ze een privéclientcertificaat van de nieuwe privé-CA presenteren; test de mTLS-handshake van begin tot eind met het privéclientcertificaat voordat de productie wordt opgestart; bevestig dat beide uiteinden van elke mTLS-verbinding de privéroot vertrouwen;	Platformteam
Certificaten voor privéklanten die niet in de CLM-platforminventaris zijn opgenomen.	Zonder CLM-dekking leiden vervaldatumgebeurtenissen van privéclientcertificaten na de migratie tot dezelfde stille fouten als die welke de verwijdering van de EKU voor openbare certificaten eerder veroorzaakte; de ​​nieuwe privé-PKI wordt een nieuwe bron van niet-gecontroleerde certificaten.	Voeg alle privéclientcertificaten toe aan CertSecure Manager met vervaldatumbewaking en verlengingswaarschuwingen vanaf de eerste dag van uitgifte; controleer of de automatische verlenging actief is voor alle privéclientcertificaten voordat u de productieservices migreert.	PKI-team
De privé-CA-root is per ongeluk verspreid naar openbare vertrouwensarchieven of externe apparaten.	Een private CA-root in een openbare vertrouwensopslag stelt de private CA in staat certificaten uit te geven die door externe partijen worden vertrouwd. Dit vergroot de impact van een CA-compromis en schendt het private-trust-model dat de migratie juist beoogt te creëren.	Bevestig dat de privé-CA-root alleen wordt verspreid naar interne systemen onder organisatiebeheer; controleer de configuratie van de vertrouwensopslag op alle apparaten en services die zijn bijgewerkt om de privé-root te vertrouwen; dien de privé-root niet in bij een openbaar rootprogramma.	Beveiligingsarchitect
Er vindt geen driemaandelijkse beoordeling meer plaats van nieuwe openbare certificaten met clientAuth die na de migratie zijn toegevoegd.	Nieuwe services die na de migratie worden geïmplementeerd, kunnen afhankelijkheden van openbare dual-EKU-certificaten opnieuw introduceren die tijdens de migratie niet aanwezig waren; zonder een driemaandelijkse audit wordt de afhankelijkheid ongemerkt opnieuw opgebouwd tot de volgende mislukte verlenging.	Plan driemaandelijkse controles van de certificaatinventaris om eventuele nieuwe openbare certificaten met de clientAuth EKU te identificeren die sinds de laatste controle zijn toegevoegd; neem deze controle op in het driemaandelijkse PKI-nalevingsbewijspakket.	PKI-team + Compliance-team

Waarom dit nu van belang is

Drie factoren maken dit urgent in plaats van theoretisch. De openbare certificeringsinstanties die de meeste TLS-certificaten uitgeven, verwijderen de clientAuth EKU tot en met 2026, Chrome rondt de overstap naar dedicated server-only hiërarchieën af, en de certificeringsfouten treden stilletjes op bij de verlenging in plaats van op een aangekondigde datum. Samen veranderen ze een onopvallend configuratiedetail in een deadline die certificaat voor certificaat nadert.

Chrome stelt de deadlines.

Het Chrome Root Program van Google stuurt deze verandering aan door over te stappen op dedicated, server-only TLS-hiërarchieën. Volgens het beleid van het Chrome Root Program moet elk nieuw intermediair (ondergeschikt) CA-certificaat vanaf 15 juni 2026 alleen de serverAuth EKU bevatten, en elk nieuw uitgegeven leaf-certificaat moet vanaf 15 maart 2027 alleen de serverAuth-eigenschap bevatten. Op die datum vertrouwt Chrome geen openbare TLS-certificaten meer die de clientAuth EKU bevatten. Certificaten die vóór deze data zijn uitgegeven, blijven geldig tot hun vervaldatum. Dit maakt het een geleidelijke afgrond: er gaat niets kapot op de deadline zelf, maar elke verlenging daarna ontneemt de functionaliteit waarop mTLS vertrouwde.

De CA's handelen nog eerder.

De praktische deadline ligt eerder dan de door Chrome aangegeven datum, omdat verschillende certificeringsinstanties de EKU al ruim voor die datum verwijderen. Let's Encrypt verwijdert de clientAuth EKU uit certificaten die op of na 13 mei 2026 worden uitgegeven, en Sectigo verwijdert deze uiterlijk 15 mei 2026. DigiCert stopte met het standaard opnemen ervan op 1 oktober 2025, geeft deze nu alleen nog uit op expliciet verzoek en zal deze volledig verwijderen op 1 maart 2027. De effectieve deadline wordt daarom bepaald door de certificeringsinstantie die uw certificaat uitgeeft, niet door de door Chrome aangegeven datum: als uw mTLS afhankelijk is van een Let's Encrypt- of Sectigo-certificaat dat na half mei 2026 wordt verlengd, kan het systeem maanden vóór de handhaving door Chrome niet meer werken, omdat het verlengde certificaat simpelweg geen clientAuth meer bevat.

Dit maakt deel uit van een bewuste verschuiving naar specifieke hiërarchieën.

De verandering is niet willekeurig. Het weerspiegelt een sectorbrede verschuiving naar dedicated, single-purpose PKI-hiërarchieën, zoals gepresenteerd in de beleidsupdates van het Chrome Root Program. Het doel is om certificaatvertrouwensketens voor meerdere doeleinden te elimineren om de beveiliging van servercertificaten te verbeteren en het beheer ervan te vereenvoudigen. Het tijdperk van één certificaat voor meerdere doeleinden loopt bewust ten einde. Deze richting werd bepaald tijdens de discussies van het CA/Browser Forum in oktober 2024 en geformaliseerd in opeenvolgende beleidsversies van het Chrome Root Program. Naar verwachting zullen de andere belangrijke rootprogramma's, waaronder die van Apple en Mozilla, zich hierbij aansluiten, dus dit is een sectorbrede trend en geen voorkeur van één leverancier.

Hoe mTLS en de clientAuth EKU werken

Voordat u de migratie plant, is het nuttig om te begrijpen wat de uitgebreide sleutelgebruiksregels inhouden, waarom wederzijdse TLS specifiek de oorzaak is van de problemen en waarom private PKI hiervan is uitgezonderd. De onderstaande paragrafen behandelen elk van deze punten, samen met een uitleg waarom publiek vertrouwen sowieso niet de juiste methode was voor interne clientauthenticatie.

Wat de EKU doet

Het uitgebreide sleutelgebruik is een certificaatuitbreiding die aangeeft waarvoor een certificaat mag worden gebruikt voor authenticatie. Twee waarden zijn hierbij cruciaal en worden geïdentificeerd door object-ID's: serverauthenticatie, id-kp-serverAuth, is OID 1.3.6.1.5.5.7.3.1, en clientauthenticatie, id-kp-clientAuth, is OID 1.3.6.1.5.5.7.3.2. Jarenlang werden openbare TLS-certificaten uitgegeven met beide uitgebreide sleutelgebruiken, wat precies de reden was dat één certificaat kon fungeren als zowel de identiteit van een server als die van een client in een wederzijdse TLS-verbinding. Browsers controleren alleen de serverAuth EKU om een ​​HTTPS-verbinding tot stand te brengen, dus het verwijderen van clientAuth uit openbare servercertificaten kost niets voor gewone webservers en sluit tegelijkertijd een reële mogelijkheid tot misbruik af.

Waarom wederzijdse TLS de oorzaak is van de problemen

Bij gewone TLS presenteert alleen de server een certificaat; de client authenticeert zich op een andere manier of helemaal niet. Bij mutual TLS presenteren beide partijen certificaten en moet het certificaat van de client de clientAuth EKU bevatten om als clientidentiteit te worden geaccepteerd. Organisaties die hun openbare servercertificaten met twee EKU's hergebruikten voor de clientzijde van mTLS, of voor server-naar-server authenticatie, vertrouwden erop dat de clientAuth-waarde aanwezig was. Zodra certificeringsinstanties (CA's) deze waarde niet meer opnemen, bevat een vernieuwd certificaat alleen nog serverAuth en mislukt de mTLS-handshake die een client-EKU verwachtte. Deze wijziging heeft gevolgen voor organisaties die servercertificaten gebruiken voor clientauthenticatie, zoals mutual TLS en server-naar-server authenticatie. Mutual TLS is nu de standaard authenticatiemethode in zero-trust- en service-mesh-architecturen, en in gedistribueerde systemen zoals Kafka, Cassandra en API-gateways waar certificaatrotatie geautomatiseerd is, kan één enkele vernieuwing leiden tot authenticatiefouten in een heel cluster.

De cruciale uitzondering: private PKI blijft onaangetast.

Het allerbelangrijkste technische gegeven voor de planning is dat deze wijziging alleen van toepassing is op publiekelijk vertrouwde certificaten. De uitzondering is expliciet: deze wijzigingen hebben geen invloed op clientauthenticatie via private PKI, omdat ze alleen betrekking hebben op publiekelijk vertrouwde certificaten. Een private certificeringsinstantie, waarvan de root alleen binnen uw eigen omgeving wordt vertrouwd en niet door openbare browsers, kan vrijelijk certificaten met de clientAuth EKU uitgeven. De 'cliff' is een fenomeen van publiek vertrouwen, en private PKI is de ontworpen oplossing hiervoor. Een private CA kan draaien op platforms zoals Microsoft AD CS , HashiCorp Vault, AWS Private CA of een beheerde service, en clientcertificaten kunnen automatisch worden geregistreerd en verlengd via EST, ACME of SCEP , wat ervoor zorgt dat kortstondige clientcertificaten praktisch bruikbaar blijven op grote schaal.

Waarom publiek vertrouwen sowieso niet het juiste instrument was voor mTLS.

De wijziging is tevens een correctie. Openbare certificaten waren nooit het juiste middel voor interne clientauthenticatie, en het bredere certificatenecosysteem heeft dat punt al langer benadrukt. DigiCert's eigen richtlijnen voor het verminderen van het risico op intrekking pleiten ervoor om verbonden apparaten en interne services niet langer te laten vertrouwen op openbare certificaten. Ze merken op dat er geen intrekkingstermijn van vijf dagen geldt voor privécertificaten en dat interne apps en communicatie met apparaten in een privénetwerk geen openbaar vertrouwen vereisen. Het gebruik van openbare certificaten voor mTLS stelde interne systemen bloot aan intrekkingsgebeurtenissen van openbare CA's en wijzigingen in het rootprogrammabeleid die niets te maken hebben met het interne gebruik. Een privé- PKI verwijdert die koppeling volledig. Het positioneert interne authenticatie ook voor de bredere verschuiving naar kortstondige certificaten en geautomatiseerde uitgifte, waarbij handmatige certificaatverwerking niet langer haalbaar is.

Risico's en valkuilen

De clientAuth-problematiek vormt een risico voor zowel degenen die niets doen als degenen die overhaast migreren. De onderstaande tabel laat zien waar het bij elk van deze scenario's vaak misgaat.

Risico	Veroorzaken	consequentie
Stille mislukking bij verlenging	Het openbare certificaat wordt vernieuwd zonder de clientAuth EKU nadat de uitgevende CA deze heeft laten vervallen.	mTLS-handshakes mislukken; service-to-service-authenticatie werkt niet meer.
Verborgen afhankelijkheid	Er is geen inventarisatie van waar openbare certificaten worden gebruikt voor mTLS.	Een systeemstoring waarvan niemand wist dat die te wijten was aan een sluiproute.
Gehaaste migratie	De afhankelijkheid wordt pas ontdekt op het moment van vernieuwing.	Noodomschakeling met weinig testen en een hoog risico op fouten.
Koppeling van publiek vertrouwen	Interne mTLS gekoppeld aan openbaar CA-beleid en intrekking.	Interne storingen veroorzaakt door externe CA-gebeurtenissen.
Niet-beheerde privé-CA	Het opzetten van een eigen PKI zonder levenscyclusbeheer.	Nieuwe sleutelwildgroei en een niet-gecontroleerde interne vertrouwensbasis.

Het gevaar is dat de afhankelijkheid onzichtbaar is.

Het lastigste aan het clientAuth-probleem is niet de oplossing zelf, maar weten waar je kwetsbaar bent. Het hergebruik van openbare certificaten voor mTLS is vaak ongedocumenteerd, jaren geleden opgezet door een team dat inmiddels vertrokken is, en ingebed in service-to-service-koppelingen die prima werken tot een verlenging de EKU verwijdert. Zonder een inventarisatie die bijhoudt welke certificaten clientAuth bevatten en waar ze als clientidentiteiten worden gebruikt, kan een organisatie niet weten welke systemen bij de volgende verlenging problemen zullen ondervinden, totdat het daadwerkelijk gebeurt. Ontdekking is de eerste en meest urgente taak.

De financiële dienstverlening en soortgelijke sectoren worden onevenredig zwaar getroffen.

Sommige sectoren leunen meer op dit patroon dan andere. De verandering treft met name sectoren zoals financiële dienstverlening en technologiediensten die servercertificaten gebruiken voor clientauthenticatie, en organisaties in deze sectoren zouden de ontdekkingstocht met spoed moeten aanpakken. Voor diegenen die daadwerkelijk publiek gerootte clientauthenticatie over organisatiegrenzen heen nodig hebben, kan een dedicated X9 PKI, beheerd volgens de ASC X9-standaarden en buiten de Chrome Root Store opererend, nog steeds certificaten uitgeven die beide EKU's bevatten, en deze wordt in de financiële sector juist voor dit doel gebruikt.

Beste praktijken voor implementatie

Het bouwen van private-PKI mTLS vóór de crisis is een afgebakend project als het begint met onderzoek en eindigt met automatisering. De zeven onderstaande stappen worden in volgorde uitgevoerd, omdat je niet kunt onderzoeken wat je nog niet hebt onderzocht, en je niet veilig kunt overschakelen naar iets wat je nog niet hebt getest.

1. Ontdek alle mTLS-afhankelijkheden van openbare certificaten: Inventariseer welke certificaten de clientAuth EKU bevatten en waar ze worden gebruikt als clientidentiteiten of voor server-naar-server-authenticatie. Dit geeft u een exact beeld van de omvang van de problemen en wanneer deze zich zullen voordoen, gebaseerd op de verlengingsdatum van elk certificaat. (Encryption Consulting's) CBOM Secure Dit automatiseert de ontdekking door elk certificaat, de bijbehorende EKU's en de systemen die ervan afhankelijk zijn, te catalogiseren.
2. Controleer de verlengingsdata aan de hand van de CA-deadlines: Koppel de verlengingsdatum van elk betrokken certificaat aan de datum waarop de uitgevende CA wordt verwijderd: 13 mei voor Let's Encrypt en 15 mei voor Sectigo. DigiCert verstrekt clientAuth-certificaten alleen op aanvraag tot de verwijdering op 1 maart 2027, zodat u weet welke afhankelijkheden de kortste levensduur hebben.
3. Zet een eigen CA op voor clientauthenticatie: Stel een private PKI in waarvan de root alleen binnen uw omgeving wordt vertrouwd, en geef clientcertificaten uit die de clientAuth EKU bevatten. Private PKI wordt expliciet niet beïnvloed door de wijziging van het publieke vertrouwen en is de beoogde route voor interne mTLS. Encryption Consulting's PKI-as-a-Service Het biedt precies dat: een beheerde, private CA die clientAuth-certificaten uitgeeft zonder de last van het bouwen en beheren van de infrastructuur.
4. Scheid het vertrouwen tussen server en client op een duidelijke manier: Gebruik openbare, serverAuth-only certificaten voor publiekelijk toegankelijke servers en privé clientcertificaten voor de clientzijde van mTLS. Omarm hiermee het dedicated-hierarchy model in plaats van ertegen te vechten. In de praktijk betekent dit een openbaar, serverAuth-only certificaat op de load balancer en een privé, clientAuth-certificaat op elke service die zich als client authenticeert.
5. Bescherm de privéroot en automatiseer de uitgifte: Veranker de ondertekeningssleutels van de private CA in een HSM en gebruik een geautomatiseerd inschrijvingsprotocol zoals EST of ACME, zodat kortstondige clientcertificaten zonder handmatige tussenkomst worden uitgegeven en verlengd. Een private CA zonder automatisering van de levenscyclus ruilt het ene probleem in voor het andere. HSM-as-a-Service CertSecure Manager verankert de privé-root in gevalideerde hardware en automatiseert de uitgifte en verlenging, zodat kortstondige clientcertificaten nooit verlopen.
6. Migreer en valideer vóór de verlengingsdatum: Verplaats elke mTLS-afhankelijkheid naar privéclientcertificaten en test de volledige handshake ruim voordat het openbare certificaat zonder de EKU zou worden vernieuwd. Zo is de wijziging gepland en wordt deze niet veroorzaakt door een storing.
7. Beheer de private PKI als productie-infrastructuur: Houd een inventaris bij van uitgegeven clientcertificaten, handhaaf eigendom en rotatie, en monitor de private root, zodat de nieuwe PKI geen nieuwe bron van onbeheerd vertrouwen wordt. CertSecure Manager biedt dit beheer vanuit één centrale plek, met een actuele inventaris van uitgegeven clientcertificaten, inclusief eigendom, rotatie en monitoring.

Hoe encryptieconsultancy kan helpen

Het probleemloos overleven van de clientAuth-problematiek komt neer op drie dingen: vaststellen waar openbare certificaten worden gebruikt voor mTLS, deze vervangen door certificaten van een beheerde private CA, en de uitgifte automatiseren zodat de nieuwe clientcertificaten zichzelf vernieuwen. Dit is precies waar de PKI-as-a-Service van Encryption Consulting van pas komt. Het biedt een volledig beheerde private certificeringsinstantie die clientAuth-certificaten uitgeeft onder uw controle, met de profielcontrole, het uitgiftebeleid en het levenscyclusbeheer die interne mTLS vereist, en zonder de last van het helemaal zelf bouwen en beheren van een CA.

Rondom de private CA wordt dezelfde aanpak ingezet op een gecoördineerd pakket aan diensten op het gebied van encryptieconsulting, waarbij elk een eigen rol speelt:

• PKI-as-a-Service biedt een volledig beheerde, particuliere certificeringsinstantie die clientAuth-certificaten uitgeeft onder uw controle, met de profielcontrole, het uitgiftebeleid en het levenscyclusbeheer die interne mTLS-systemen nodig hebben, zonder de last van het zelf bouwen en beheren van een CA.
• CBOM Secure Het systeem ontdekt elke verborgen mTLS-afhankelijkheid van publiek vertrouwen, catalogiseert elk certificaat, de EKU's die het bevat en de systemen die ervan afhankelijk zijn, zodat u precies weet wat de omvang van de problemen zal zijn en wanneer.
• CertSecure Manager Het automatiseert de uitgifte en verlenging van certificaten voor zowel openbare als particuliere certificeringsinstanties en houdt een actuele inventaris bij met eigendoms-, rotatie- en monitoringgegevens, zodat kortstondige klantcertificaten nooit verlopen en de particuliere PKI onder controle blijft.
• HSM-as-a-Service Dit verankert de nieuwe interne vertrouwensbasis in gevalideerde hardware, waardoor de ondertekeningssleutels van de private CA worden beschermd zonder dat er nieuwe apparaten hoeven te worden geïnstalleerd en onderhouden.

Het overkoepelende principe is dat interne authenticatie moet berusten op een infrastructuur die u beheert, die geautomatiseerd en losgekoppeld is van het beleid van de publieke CA. Zo wordt een wijziging zoals de stopzetting van clientAuth geen noemenswaardige gebeurtenis, maar een storing. Om uw risico's in kaart te brengen en een private PKI mTLS te implementeren vóór uw volgende verlenging, kunt u contact opnemen met Encryption Consulting voor een certificaatdetectie en een private-PKI-assessment.

Conclusie

Het einde van de clientAuth EKU is een schoolvoorbeeld van een handige snelkoppeling die op het punt staat te verdwijnen. Het hergebruiken van openbare TLS-certificaten voor wederzijdse TLS werkte jarenlang, maar de overstap van de industrie naar dedicated, single-purpose hiërarchieën heeft hier een einde aan gemaakt. Chrome zal vanaf 15 juni 2026 geen openbare certificaten meer vertrouwen die de clientAuth EKU bevatten. Tussenliggende hiërarchieën zullen vanaf 15 juni 2026 server-only zijn en bladcertificaten vanaf 15 maart 2027. Omdat verschillende CA's de EKU al eerder in 2026 verwijderen, zal mTLS dat afhankelijk is van deze snelkoppeling bij de volgende verlenging stilzwijgend en zonder waarschuwing niet meer werken.

De oplossing is duidelijk: ontdek waar u afhankelijk bent van openbare certificaten voor clientauthenticatie, zet een private PKI op die vrijelijk clientAuth-certificaten kan uitgeven omdat deze niet wordt beïnvloed door de wijziging in het publieke vertrouwen, scheid het vertrouwen van servers en clients en automatiseer de uitgifte zodat de nieuwe clientcertificaten zichzelf vernieuwen. Begin nu met de inventarisatie, want uw effectieve deadline wordt bepaald door de CA die uw certificaten vernieuwt, niet door één enkele datum. Bouw uw private PKI mTLS bewust vóór de overgang, zodat de verandering een geplande modernisering wordt naar een infrastructuur die u beheert, in plaats van een onverwachte storing.

Veelgestelde Vragen / FAQ

Wat is de belangrijkste conclusie uit "Bouw een private PKI voor mTLS voordat publieke certificaten clientAuth laten vallen"?

Openbare certificeringsinstanties (CA's) verwijderen de clientAuth EKU (OID 1.3.6.1.5.5.7.3.2) uit openbaar vertrouwde TLS-certificaten tot en met 2026. Let's Encrypt vanaf 13 mei 2026; Sectigo vanaf 15 mei 2026; DigiCert vanaf 1 maart 2027. mTLS-systemen die openbare dual-EKU-certificaten hergebruikten voor clientauthenticatie, zullen stilzwijgend falen bij verlenging wanneer het vernieuwde certificaat geen clientAuth meer bevat. Privé-PKI's worden expliciet niet beïnvloed en zijn de beoogde oplossing: een privé-CA kan vrijelijk clientAuth-certificaten uitgeven omdat de root ervan niet in de openbare browservertrouwensopslag staat.

Waarom is de verwijdering van clientAuth EKU van belang voor PKI-teams binnen bedrijven?

Enterprise PKI-teams die niet hebben bijgehouden welke publieke certificaten clientAuth bevatten, worden geconfronteerd met stille mTLS-fouten bij verlenging zonder waarschuwing. Uit de DigiCert Trust Pulse Survey (juli 2025) bleek dat 45 procent van de bedrijven in het voorgaande jaar te maken had met downtime als gevolg van certificaatproblemen; het stilletjes verwijderen van EKU bij verlenging is een vorm van diezelfde downtime. De wijziging vereist ook het opzetten van een private PKI-infrastructuur die veel organisaties nooit formeel hebben ontworpen, waardoor een certificaatverlenging een infrastructuurproject wordt met een deadline die wordt bepaald door de certificeringsinstantie die als eerste certificaten verlengt.

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

Vier specifieke risico's nemen toe: het mislukken van de ontdekking van verborgen afhankelijkheden (zonder een certificaatinventaris kan een organisatie de migratie niet in kaart brengen); het risico van een noodmigratie (het ontdekken van de afhankelijkheid op het moment van verlenging dwingt tot een noodmigratie met weinig testen); het risico van een onbeheerde private CA (een private CA zonder automatisering van de levenscyclus zorgt voor een ongecontroleerde wildgroei aan certificaten); en een cascadefout in geautomatiseerde omgevingen (in systemen zoals Kafka en API-gateways kan een enkele verlenging zonder de verwachte clientAuth EKU leiden tot authenticatiefouten in een heel cluster).

Welke teams moeten verantwoordelijk zijn voor de migratie van clientAuth EKU naar een private PKI?

De PKI- en certificaatteams zijn verantwoordelijk voor het ontwerp van de private CA, het clientAuth-certificaatprofiel, de HSM-ondersteunde opslag van de root-sleutel en de geautomatiseerde inschrijving via EST, ACME of SCEP. Beveiligingsarchitecten zijn verantwoordelijk voor het vertrouwensmodel: een dedicated private CA-hiërarchie die losstaat van de server-CA, een private root-vertrouwensscope en zero-trust-afstemming. De platform- en DevOps-teams zijn verantwoordelijk voor het bijwerken van de serviceprovisioning-pipelines en mTLS-configuraties om private clientcertificaten te gebruiken. De compliance-teams zijn verantwoordelijk voor het bewijs dat de migratie is voltooid vóór de deadline voor verwijdering van elke CA. CISO's zijn verantwoordelijk voor het governance-mandaat dat de migratie een gefinancierd en traceerbaar programma is.

Hoe is de clientAuth EKU-migratie gekoppeld aan certificaatlevenscyclusbeheer?

De migratie vereist twee afzonderlijke CLM-functionaliteiten: ontdekking (identificeren welke certificaten clientAuth bevatten en waar ze worden gebruikt als clientidentiteiten) en doorlopend beheer (het bijhouden van privéclientcertificaten met vervaldatumbewaking, automatische verlenging en eigendomsmetadata). CertSecure Manager biedt beide: certificaatontdekking met catalogisering van EKU's en afhankelijke systemen, en geautomatiseerde uitgifte en verlenging van kortstondige privéclientcertificaten, zodat ze na de migratie nooit verlopen.

Hoe moeten organisaties het succes van de clientAuth EKU-migratie meten?

Belangrijkste meetwaarden: volledigheid van de ontdekking (alle certificaten met clientAuth geïdentificeerd met verlengingsdatums gekoppeld aan de deadlines voor verwijdering door de CA); volledigheid van de migratie (alle mTLS-afhankelijkheden gemigreerd naar privéclientcertificaten vóór de deadline van de uitgevende CA, geen systemen die vastlopen bij verlenging na de deadline); dekking van de inventaris van privé-CA's (alle privéclientcertificaten in het CLM-platform met actieve vervaldatumbewaking en automatische verlenging); en geen ongeplande mTLS-authenticatiefouten die toe te schrijven zijn aan de verwijdering van de EKU nadat de migratie is voltooid.

Wat moet er na de migratie naar een private PKI voor mTLS regelmatig worden gecontroleerd of gemonitord?

Continue monitoring: vervaldatum van privéclientcertificaten met verlengingswaarschuwingen; geldigheids- en intrekkingsstatus van privé-CA-root- en intermediaire certificaten; en succespercentages van mTLS-handshakes op gemigreerde services. Kwartaalcontrole: scan op nieuwe openbare certificaten met clientAuth die sinds de laatste controle zijn toegevoegd; bevestig dat de automatische inschrijving van privé-CA's functioneert; controleer of de privé-root is vertrouwd in de verwachte vertrouwensarchieven en niet in onbedoelde openbare vertrouwensarchieven; en beoordeel de privé-CA CP/CPS op afstemming met het huidige beveiligingsbeleid van de organisatie.

Welke gevolgen heeft de verwijdering van de clientAuth EKU voor cloud-, hybride- of multi-CA PKI-omgevingen?

In cloud- en hybride omgevingen moeten cloudworkloads die authenticeren als mTLS-clients met behulp van openbare certificaten, worden gemigreerd naar privéclientcertificaten die zijn uitgegeven door de nieuwe privé-CA. In omgevingen met meerdere CA's moet de privé-CA voor clientAuth een aparte hiërarchie vormen, los van de CA-hiërarchie van de openbare server. CBOM Secure biedt de benodigde cryptografische inventarisatie voor alle omgevingen om alle cloud- en hybride clientAuth-afhankelijkheden te identificeren vóór de CA-deadlines verstrijken.

Welke veelgemaakte fouten moeten teams vermijden bij de migratie naar een private PKI voor mTLS?

De meest voorkomende fouten: het overslaan van de ontdekking en ervan uitgaan dat alle mTLS-afhankelijkheden bekend zijn; het opzetten van een private CA zonder HSM-ondersteunde root-sleutelopslag; het niet configureren van geautomatiseerde inschrijving vóór de migratie (handmatig beheer van private certificaten op grote schaal faalt op dezelfde manier als handmatig beheer van publieke certificaten); het implementeren van de private root in een onbedoelde publieke vertrouwensopslag; en het niet scheiden van de private client-CA-hiërarchie van de publieke server-CA-hiërarchie, wat het dedicated-hierarchy-model ondermijnt waar de industrie naar streeft.

Wat moet er elk kwartaal worden bijgewerkt voor het beheer van private PKI mTLS?

Driemaandelijks: voer een certificaatinventarisatiescan uit om te controleren of er sinds de laatste audit nieuwe openbare certificaten met clientAuth zijn toegevoegd; controleer het uitgiftelogboek van de private CA op onverwachte certificaatprofielen of ongeautoriseerde uitgifte; bevestig dat de automatische inschrijving actief is voor alle gemigreerde mTLS-services; controleer de vervaldatums van private clientcertificaten; raadpleeg de aankondigingen van het CA/Browser Forum en het Chrome Root Program voor beleidswijzigingen; en bekijk de roadmap voor post-quantummigratie voor algoritmen voor private clientcertificaten volgens NIST FIPS 203, 204 en 205 (13 augustus 2024). Raadpleeg het PQC Center of Excellence voor planning na de quantummigratie.