Verwijdering van clientAuth EKU: Waar mTLS faalt en hoe te migreren naar een private PKI

Uw mTLS-mesh kan alle gezondheidscontroles doorstaan, alle certificaten volgens schema vernieuwen en toch 's nachts stoppen met het authenticeren van clients. Niets wordt gehackt. Niets verloopt voortijdig. Een certificaat wordt weliswaar vernieuwd, maar mist vervolgens stilletjes één Extended Key Usage-waarde, waardoor de volgende handshake die ervan afhankelijk is, mislukt. Dat is hoe de clientAuth-uitfasering eruit gaat zien, en die is al begonnen.

TL; DR Het Chrome Root Program Policy v1.8, sectie 1.3.2, verwijdert de clientAuth Extended Key Usage (EKU) van publiekelijk vertrouwde TLS-bladcertificaten. Nieuwe ondergeschikte CA's moeten sinds 15 juni 2026 alleen serverAuth ondersteunen, en elk nieuw publiek bladcertificaat moet uiterlijk 15 maart 2027 serverAuth-only zijn. Uw certificeringsinstantie zal vrijwel zeker al vóór de deadline van Chrome zelf overschakelen. DigiCert, Sectigo, Let's Encrypt, Google Trust Services en SSL.com hebben allemaal eerdere interne deadlines vastgesteld, sommige al in september 2025. De fout is opzettelijk stil: bestaande certificaten blijven werken tot ze verlopen, dus de breuk wordt pas zichtbaar bij de volgende routinevernieuwing, niet op een beleidsdatum, en kan uren of dagen later opduiken in een andere infrastructuur. Het opnieuw uitgeven of vastzetten van het bladcertificaat biedt geen oplossing. Verificatiesystemen berekenen de effectieve EKU als de intersectie van elk certificaat in de keten. Zodra uw uitgevende hiërarchie overgaat op serverAuth-only, wordt de clientAuth OID van het blad niet langer erkend, zelfs als deze nog steeds op het certificaat staat. De duurzame oplossing is een private PKI die u beheert voor client- en machine-identificatie, intern ontwikkeld of afgenomen als PKI-as-a-Service, gemigreerd via een vierfasenplan zonder downtime.

Key Takeaways

• Ken de opdracht: Chrome Root Program Policy v1.8 is de bron. Op 15 juni 2026 zijn sub-CA-hiërarchieën voor specifieke doeleinden al van kracht geworden. 15 maart 2027 is de harde grens voor bladcertificaten. Uw eigen CA zal waarschijnlijk eerder dan een van beide data overstappen.
• Inventaris op dit moment, niet bij verlenging: Vind alle clientAuth-gebruikers in mTLS, service mesh, IoT, VPN, 802.1X, SIP en traditionele machine-to-machine-systemen.
• Sla de doodlopende wegen over: Opt-in-vlaggen, heruitgiften op het laatste moment en niet-browser-roots stellen de afgrond slechts uit. Een private PKI is de enige optie die u EKU's en een uitgiftebeleid biedt waarover u daadwerkelijk controle hebt.
• Controleer de hele keten, niet alleen het blad: Een tussenliggend certificaat dat de clientAuth-status verliest, kan een leaf-certificaat ongeldig maken voordat de eigen verlengingstermijn van dat leaf-certificaat aanbreekt.
• Zoek verder dan uw eigen certificatenvoorraad: Certificate Transparency-logboeken brengen vergeten en niet-bestaande certificaten aan het licht die niet in uw eigen administratie zijn opgenomen.
• Migreer bewust: Ontdekken, ontwerpen, implementeren, vervolgens overschakelen met parallel vertrouwen en de volledige keten valideren in de testomgeving voordat een vernieuwing naar productie de kwestie voor u afdwingt.

Wat verandert er eigenlijk?

Jarenlang kon één publiekelijk vertrouwd TLS-certificaat twee Extended Key Usage-waarden tegelijk bevatten: id-kp-serverAuth (OID 1.3.6.1.5.5.7.3.1) en id-kp-clientAuth (OID 1.3.6.1.5.5.7.3.2), zoals gedefinieerd in RFC 5280 Sectie 4.2.1.12. Een enkel certificaat kon HTTPS als server beëindigen en tevens authenticeren als client in mTLS-, service-to-service- en machine-identiteitsstromen.

Volgens Chrome Root Program Policy v1.8, sectie 1.3.2, verdwijnt die dubbele rol. Nieuwe publiekelijk vertrouwde TLS-bladcertificaten zullen alleen serverAuth bevatten. Bestaande certificaten met een dubbele functie blijven geldig tot ze verlopen, maar elke verlenging die na de handhavingsdatum van uw CA wordt uitgegeven, zal standaard alleen serverAuth bevatten.

Twee data zijn van belang op beleidsniveau: nieuwe ondergeschikte CA's die aan de CCADB worden gemeld, moeten sinds 15 juni 2026 alleen serverAuth ondersteunen, en elk abonnementscertificaat (bladcertificaat) dat op of na 15 maart 2027 wordt uitgegeven, moet alleen serverAuth ondersteunen. Google bracht deze splitsing voor het eerst ter sprake tijdens de F2F-63-bijeenkomst van het CA/Browser Forum in oktober 2024 en legde het vervolgens vast als beleid voor het Chrome Root Program in plaats van via een stemming van het CA/Browser Forum. Chrome vertegenwoordigt nog steeds ongeveer twee derde van de wereldwijde browsermarkt, dus een publieke CA die het rootprogramma van Chrome negeert, riskeert het vertrouwen van het grootste deel van het web te verliezen. Daarom beschouwt elke grote CA het beleid als verplicht.

Dit artikel gaat ervan uit dat u dit al weet. Voor de volledige geschiedenis van het mandaat, de rol van het CA/Browser Forum en de beleidstekst van Chrome, sectie voor sectie, raadpleegt u de gedetailleerde analyses van Encryption Consulting over Chrome Root Program Policy v1.8 en het mandaat van het CA/Browser Forum . Wat volgt is het deel dat in de meeste berichtgeving over deze wijziging wordt overgeslagen: waar uw infrastructuur precies wankelt, hoe u elk risicovol certificaat kunt vinden en hoe u clientidentiteiten naar een permanente locatie kunt verplaatsen voordat een verlenging het probleem in productie afdwingt.

De deadline van je certificeringsinstantie, niet die van Chrome, is de daadwerkelijke deadline.

Openbare certificeringsinstanties lopen ver vooruit op de handhavingsdata van Chrome zelf. Bestaande certificaten blijven werken tot ze verlopen, maar de eerste verlenging na de deadline van uw certificeringsinstantie is alleen nog serverAuth-compatibel, en dat is het moment waarop clientauthenticatie stilletjes stopt.

Certificate Authority	clientAuth is standaard uitgeschakeld.	Strikte beëindiging (geen clientAuth verleend)
DigiCert	October 1, 2025	1 maart 2027 (alle DigiCert-merken)
Sectigo	October 7, 2025	10 februari 2027, zonder uitzonderingen
Laten we versleutelen	11 februari 2026 (standaard ACME-profiel)	8 juli 2026 (tlsClient bridge-profiel buiten gebruik gesteld)
Google Trust Services	10 november 2025 (CSR's afgewezen)	13 april 2026, zonder uitzonderingen
SSL.com	15 september 2025	Afgestemd op Chrome, 15 maart 2027

Raadpleeg de adviespagina van uw eigen CA (Central Authority) rechtstreeks; verschillende van deze data zijn al eerder vervroegd dan oorspronkelijk aangekondigd, en CA's schromen niet om de planning verder te versnellen.

Waarom de splitsing eigenlijk de juiste beslissing is

Het is verleidelijk om dit af te doen als bureaucratische rompslomp van een browserleverancier. Dat is het echter niet, en het is de moeite waard om te begrijpen waarom voordat je er een oplossing voor ontwerpt. Dezelfde logica zou namelijk bepalend moeten zijn voor het ontwerp van de private PKI waarnaar je migreert.

Validatie is geen autorisatie: de uitgifte van een openbaar certificaat bewijst domeincontrole, via methoden zoals ACME HTTP-01 en DNS-01 zoals gedefinieerd in RFC 8555 secties 8.3 en 8.4, of organisatie-identiteit voor OV- en EV-certificaten, volgens Baseline Requirements sectie 3.2.2.4. Geen van deze methoden verifieert dat een bepaald systeem geautoriseerd is om als client te fungeren ten opzichte van uw infrastructuur. Een openbaar clientAuth-certificaat adverteerde altijd een vertrouwenseigenschap die de uitgevende CA nooit daadwerkelijk valideerde.

Dual EKU verdubbelt de impact van één gestolen sleutel: een certificaat met zowel serverAuth als clientAuth betekent dat een gecompromitteerde privésleutel een aanvaller in staat stelt zich voor te doen als uw server en zich lateraal te verplaatsen als een vertrouwde client, waarbij dezelfde sleutel voor beide wordt gebruikt. Door certificaten, sleutels en levenscycli te scheiden op basis van hun doel, wordt dit tweede aanvalspad volledig geëlimineerd. Het is in feite het principe van minimale bevoegdheden toegepast op certificaten, geen nieuw idee, maar nu eindelijk afgedwongen op EKU-niveau.

Waar de mTLS-handshake daadwerkelijk vastloopt

Dit is het detail dat de meeste uitleggers van deze wijziging overslaan, terwijl het juist het belangrijkste is wanneer je om 2 uur 's nachts een webpagina aan het debuggen bent.

Bij een wederzijdse TLS-handshake stuurt de server een CertificateRequest, de client antwoordt met zijn Certificate en stuurt vervolgens een CertificateVerify, een handtekening die bewijst dat de client de bijbehorende privésleutel bezit (dit is de TLS 1.3-flow; TLS 1.2 voegt een niet-versleutelde ClientKeyExchange-stap toe, maar het faalpunt is identiek). De verificator voert hier twee volledig gescheiden controles uit, en het samenvoegen daarvan is waar de meeste analyses achteraf misgaan.

Eerst wordt padvalidatie uitgevoerd zoals gedefinieerd in RFC 5280 Sectie 6, waarbij de keten naar een vertrouwde root wordt opgebouwd en gecontroleerd. Deze stap slaagt. De certificaatketen is volledig geldig. RFC 5280 definieert de EKU-extensie zelf in Sectie 4.2.1.12, maar vereist geen verificator om het EKU-doel te controleren als onderdeel van de padvalidatie.

Die doelcontrole wordt door de specifieke TLS-implementatie toegevoegd en is niet verplicht volgens de RFC. Belangrijke bibliotheken, waaronder OpenSSL, Java's JSSE, Go's crypto/tls en Rust's rustls, voeren standaard EKU-doelvalidatie uit: ze zoeken naar clientAuth in het aangeboden certificaat, vinden het niet en wijzen het certificaat direct af. Dit is een harde authenticatiefout, geen waarschuwing, en gebeurt meestal zodra de verificator de EKU van het clientcertificaat evalueert, vaak direct bij het Certificate-bericht in plaats van pas na CertificateVerify. Er worden geen applicatiegegevens verzonden voordat deze controle is uitgevoerd.

De handhaving is opzettelijk, niet toevallig. Go's eigen issue tracker documenteert een geval (golang/go#23884) waarbij een serverAuth-only clientcertificaat correct werd geweigerd onder RequireAndVerifyClientCert in Go 1.9.4, maar vervolgens ten onrechte werd geaccepteerd na een regressie in Go 1.10. De beheerders van Go beschouwden de regressie als een bug en hebben deze verholpen, wat een duidelijke bevestiging is dat EKU-handhaving het beoogde standaardgedrag is binnen het ecosysteem, en geen uitzondering die genegeerd kan worden.

De kettingval: het opnieuw uitdelen van het blad zal je niet redden.

Hier is het detail dat teams die denken tijd te hebben gewonnen, in de problemen brengt. Verificatiesystemen zoals Chrome en de onderliggende TLS-stacks controleren niet alleen de EKU van het bladcertificaat. Ze valideren de hele keten, en de effectieve EKU van een certificaat is de intersectie van de doeleinden die door elk certificaat in het pad erboven zijn toegestaan.

Neem bijvoorbeeld een bladcertificaat waarop zowel serverAuth als clientAuth nog vermeld staan, uitgegeven door een intermediaire CA die is overgestapt naar een hiërarchie met alleen serverAuth:

{ serverAuth } ∩ { serverAuth, clientAuth } = { serverAuth }

De clientAuth OID van het bladcertificaat staat nog steeds op het certificaat afgedrukt. Deze wordt echter genegeerd, omdat geen enkel certificaat boven het bladcertificaat een EKU mag bevatten die clientAuth uitsluit om die reden en zo de keten kan overleven. Stilte is voldoende: een intermediair CA-certificaat zonder EKU-extensie is onbeperkt. Het is een expliciete EKU die clientAuth weglaat die alles daaronder verstoort.

Het praktische gevolg: u kunt clientAuth niet in stand houden door uw bestaande leaf-certificaat opnieuw uit te geven of vast te zetten zodra de hiërarchie van uw uitgevende CA overgaat op serverAuth-only. Een tussenliggende certificeringsinstantie kan de clientAuth-functionaliteit voor alles daaronder verliezen voordat de verlengingsdatum van een individueel leaf-certificaat is bereikt. Als u alleen de vervaldatums van leaf-certificaten bijhoudt, houdt u de verkeerde tijd in de gaten.

Welke werkbelastingen vallen stilletjes uit?

De impact is groter dan de meeste certificaatinventarissen aannemen, en de handhaving verschilt per leverancier. Juist daarom is het lastig om dit alleen met een spreadsheet in kaart te brengen.

Werkdruk	Waarom het afhangt van clientAuth	Handhavingsnotities
mTLS / service mesh	Sidecars authenticeren elkaar met clientcertificaten voor oost-westverkeer.	Doorgaans strikt; daar waar storingen het meest zichtbaar zijn.
Partner- en B2B-API's	Gateways presenteren clientcertificaten om de identiteit te bewijzen in mTLS-communicatie tussen organisaties.	Contractueel strikt bij de meeste integraties.
IoT en apparaatidentiteit	Elk apparaat presenteert een clientcertificaat om aan te tonen tot welk vlootlid het behoort.	Strikt; het is lastig om apparaatparken snel te updaten.
VPN-clientauthenticatie	Clients authenticeren zich bij de gateway met een certificaat (OpenVPN, AnyConnect, Fortinet).	Leveranciersafhankelijk, over het algemeen strikt
Wi-Fi / 802.1X (EAP-TLS)	Het certificaat van de aanvrager (het apparaat) bevat doorgaans clientAuth.	RFC 5216 §5.3 beveelt de controle aan, maar accepteert ook helemaal geen EKU.
SIP / SBC / uniforme communicatie	Sommige providers vereisen clientAuth voor vertrouwen in de Session Border Controller.	Afhankelijk van de provider; de documentatie van Microsoft Teams Direct Routing accepteert momenteel SBC-certificaten zonder clientAuth.
Loadbalancers	Controleer clientcertificaten, maar dwing clientAuth alleen af ​​als dit expliciet is geconfigureerd.	F5 BIG-IP dwingt het EKU-doel alleen af ​​als een beheerder die regel inschakelt.
Verouderde machine-naar-machine middleware	Oudere systemen verwachten één certificaat voor twee functies.	Vaak het moeilijkst te repareren; vaak niet in bezit van een huidig ​​team.

De eerlijke conclusie is dat handhaving echt afhankelijk is van de leverancier. Controleer uw eigen infrastructuur in plaats van ervan uit te gaan dat elke workload in deze tabel op dezelfde dag vastloopt; sommige workloads kunnen door een technisch probleem blijven functioneren totdat een toekomstige update dat probleem ook oplost.

Het stille faalpatroon

Het gevaarlijkste aspect van deze verandering is dat er geen aankondiging van is. De reeks fouten ziet er als volgt uit:

1. De beleidsdag is aangebroken: Er gebeurt niets. Bestaande dual-EKU-certificaten blijven geldig tot ze afzonderlijk verlopen.
2. Weken verstrijken: De implementaties lijken volledig stabiel. De geautomatiseerde ACME-verlengingen verlopen nog steeds zoals altijd.
3. Een routinematige vernieuwing van de werkzaamheden: Het certificaat wordt succesvol vernieuwd, maar het geeft alleen de status 'serverAuth' terug. Het is een volledig geldig certificaat. Het mist alleen de functionaliteit die voor deze workload van belang was.
4. De volgende mTLS-handshake mislukt: De EKU-controle wijst het certificaat af de volgende keer dat het wordt gebruikt voor clientauthenticatie, wat uren of dagen na de verlenging kan zijn, op een infrastructuur die volledig los lijkt te staan ​​van degene die het certificaat heeft verlengd.

Omdat de rotatie volledig geautomatiseerd is, kan één vernieuwingscyclus bij één certificeringsinstantie een complete servicemesh platleggen. Het is bovendien erg lastig om de oorzaak te achterhalen, omdat het certificaat alle controles doorstaat, behalve de controle die er echt toe doet. De ketenvalidatie is geslaagd. De vervaldatum is in orde. De handtekening is geldig. Het betreft een serverAuth-only certificaat en niemand lette specifiek op dat veld.

Hoe vind je de blootstelling van je clientAuth-account?

Je kunt niet migreren wat je niet hebt gevonden. Zes manieren om een ​​echte inventaris op te bouwen, ongeveer in volgorde van benodigde inspanning:

1. Inventaris per EKU: Inventariseer alle openbaar uitgegeven TLS-certificaten die u bezit en markeer alles wat clientAuth bevat. Een cryptografische stuklijstworkflow (CBOM) maakt dit schaalbaar voor een grote omgeving.
2. Zoek in Certificate Transparency-logboeken: Het beleid van Chrome vereist dat CT-logboeken worden bijgehouden voor alle publiekelijk vertrouwde TLS-certificaten. Een aggregator zoals crt.sh zal daarom de volledige uitgiftegeschiedenis voor uw domeinen weergeven, inclusief vergeten of 'shadow-IT'-certificaten die niemand zich herinnert te hebben aangevraagd.
3. Controleer de hele keten, niet alleen het blad: Controleer wat de tussenliggende CA's van uw uitgevende certificeringsinstantie (CA) daadwerkelijk beweren. De bevoegdheid kan bij de tussenliggende CA vervallen voordat de leaf-certificering zelf wordt vernieuwd.
4. Breng de afhankelijkheidsgrafiek in kaart: Identificeer welke wederzijdse authenticatiestromen in uw omgeving daadwerkelijk gebruikmaken van clientAuth, en niet alleen welke certificaten de EKU bevatten.
5. Bevestig de ondersteuning voor dubbele certificaten per applicatie: Kan elke applicatie aparte client- en servercertificaten bevatten, of wordt ervan uitgegaan dat één certificaat beide functies dekt? Zo niet, dan is het tijd om dit nu met de leverancier te bespreken, en niet pas in maart 2027.
6. Automatiseer de ontdekking met een CLM-platform: Handmatige controles zijn niet schaalbaar voor meer dan een handvol certificaten. Een platform voor certificaatlevenscyclusbeheer inventariseert EKU's continu, niet alleen wanneer iemand eraan denkt om een ​​audit uit te voeren.

Drie commando's dekken de meeste snelle controles en zijn allemaal compatibel met Windows, Linux en macOS:

# Lees de EKU-extensie uit een certificaatbestand op de schijf openssl x509 -in cert.pem -noout -ext extendedKeyUsage   # Controleer de EKU op een certificaat dat wordt aangeboden door een actief TLS-eindpunt echo | openssl s_client -connect :443 -servernaam 2>/dev/null \ | openssl x509 -noout -ext extendedKeyUsage   # Lijst EKU's voor elk certificaat in een Java/PKCS12-sleutelarchief keytool -list -v -keystore -storetype PKCS12

Wat je in de uitvoer zoekt, is de tekenreeks "TLS Web Client Authentication" of de ruwe OID 1.3.6.1.5.5.7.3.2. Als deze er vandaag in staat en het certificaat afkomstig is van een openbare CA, beschouw het dan als blootgesteld.

Waarom de gebruikelijke oplossingen doodlopende wegen zijn.

Drie verleidelijke sluiproutes, en waar ze ophouden te bestaan.

Opt-in-opties: DigiCert en Sectigo bieden beide nog steeds de mogelijkheid om clientAuth in te schakelen tijdens de inschrijving, voorlopig. Deze opties verdwijnen bij de harde deadline van elke certificeringsinstantie, zelfs voor verlengingen van certificaten die u al bezit. Dit is geen oplossing, maar een aftelling met een vaste einddatum.

Vroegtijdig opnieuw uitgeven: Door vandaag opnieuw uit te geven, blijft clientAuth nog één certificaatlevensduur geldig. Maar de levensduur van openbare certificaten wordt tegen maart 2029 teruggebracht tot 47 dagen volgens CA/Browser Forum Ballot SC-081v3, dus uw volgende verlenging valt nog steeds na de deadline. De grens komt steeds dichterbij elke keer dat u deze truc gebruikt; hij verdwijnt nooit helemaal.

Niet-browsergebaseerde rootcertificaten: Hiërarchieën zoals X9 PKI ondersteunen nog steeds dual EKU-certificaten, maar Chrome en Firefox vertrouwen ze niet automatisch. Je zou dat vertrouwen zelf moeten verspreiden naar elk apparaat dat ervan afhankelijk is, wat een certificaatprobleem inruilt voor een volledig probleem met de verspreiding van vertrouwen. Dat is zelden een betere ruil.

Het patroon bij alle drie is hetzelfde: de identiteit van de klant was nooit het primaire doel van publiek webvertrouwen. Het was gekoppeld aan een certificaat dat voor een andere taak was ontworpen. De duurzame oplossing is een vertrouwensmodel dat je daadwerkelijk beheert.

Deskundig advies: Creëer de scheiding die je toch al wilde hebben.

Laten we het hier maar meteen duidelijk stellen: deze migratie is een goede reden om de architectuur te bouwen die je eigenlijk al had moeten hebben. Een private PKI, speciaal ontworpen voor client- en machine-identificatie, biedt je EKU- en profielcontrole die publieke CA's nooit zouden bieden: standaard serverAuth- en clientAuth-profielen voor één specifiek doel, een dubbel EKU-profiel dat alleen als tijdelijke oplossing voor de migratie wordt gebruikt in plaats van een permanente oplossing, en certificaatlevensduren van enkele uren tot dagen zodra de uitgifte geautomatiseerd is. Dit is een verbetering van de beveiliging, geen last.

Het ontkoppelt je ook van publieke veranderingen waar je geen controle over hebt. Het 47-daagse levensduurschema en wat de volgende beleidswijziging van het basisprogramma ook moge zijn, vormen geen noodsituatie meer voor je, omdat de afhankelijke partijen van jou zijn, de vertrouwensankers in je eigen systemen staan ​​en de regels door jou worden opgesteld. En omdat je de hiërarchie beheert, worden hybride en ML-DSA post-quantum profielen iets wat je nu al kunt testen, vóór de uitrol van PQC door het publieke ecosysteem, in plaats van een apart project voor de toekomst.

Dat betekent niet dat we weer zomaar certificaten voor tweeërlei gebruik mogen uitgeven. Dezelfde logica van minimale bevoegdheden die de scheiding van serverAuth en clientAuth in openbare TLS rechtvaardigde, geldt ook binnen uw eigen hiërarchie.

Wat een volwaardige particuliere PKI daadwerkelijk vereist

"Een private CA bouwen" klinkt makkelijk, maar is in de praktijk erg lastig. Een slechte uitvoering kan leiden tot een storing en daarmee een deadline. Zes vereisten die een productieklare private PKI onderscheiden van een certificeringsinstantie die zelf een incident wordt:

eis	Wat het eigenlijk betekent
HSM-beveiligd sleutelmateriaal	De root- en uitgevende CA-sleutels worden gegenereerd en bewaard in FIPS 140-3 gevalideerde HSM's, de root-sleutel wordt offline bewaard, met gedocumenteerde sleutelceremonies.
Uitgiftelaag ontworpen voor doorvoer	Ontworpen voor een reëel certificaatvolume met hoge beschikbaarheid; ondersteuning voor ACME, SCEP en EST zorgt ervoor dat geautomatiseerde uitgifte gelijke tred houdt met de korte geldigheidsduur.
Intrekkingsinfrastructuur	CRL-distributiepunten en OCSP-responders; stapling helpt bij het valideren van servercertificaten, maar clientcertificaatcontroles in mTLS zijn doorgaans door de verificator geïnitieerde CRL- of OCSP-zoekopdrachten.
Vastgepinde certificaatprofielen	Elk profiel bevat expliciete EKU's, algoritmen en geldigheidsperioden, waarbij de rollen van client en server gescheiden zijn per profiel of sub-CA.
CP/CPS en auditgereedheid	Een certificeringsbeleid, een verklaring over de certificeringspraktijk, belangrijke ceremonieverslagen en een sjabloon voor governance die bestand zijn tegen een externe beoordelaar.
Levenscyclusinzicht en automatisering	Continue detectie plus geautomatiseerde verlenging en rotatie; handmatige registratie kan het tempo van certificaten, gemeten in uren of dagen, niet bijhouden.

Het voldoen aan alle zes vereisten vergt een aanzienlijke technische inspanning, voortdurende operationele inzet en gespecialiseerde cryptografische expertise waarover de meeste interne teams niet beschikken. Dat is de eerlijke reden waarom veel organisaties kiezen voor een beheerde PKI (PKIaaS) in plaats van dit zelf vanaf nul op te zetten.

Het migratieplan zonder downtime

Vier fasen, zo ontworpen dat er niets misgaat tijdens de vertrouwensoverdracht. De overkoepelende regel voor alle vier de fasen: houd uw oude en nieuwe certificaatketens parallel tijdens de overgangsperiode, trek niets in totdat elke gebruiker de nieuwe keten vertrouwt, en voltooi de migratie vóór de ingangsdatum van uw certificeringsinstantie, niet op de ingangsdatum zelf.

Fase	Focus	Concrete stappen
01. Ontdekken	Zoek blootstelling	Inventariseer bladcertificaten per EKU, breng blad- en tussenliggende ketens in kaart, identificeer elke mTLS-stroom, registreer verlengingstermijnen.
02. ontwerp	Definieer profielen	Stel expliciete EKU's in, scheid client- en serverprofielen, definieer algoritmen en sleutelgroottes, ontwerp de CRL/OCSP-strategie.
03. Implementeren	Vertrouwen op te bouwen	Implementeer de root- en uitgevende laag (of breid uit via PKIaaS waar dat zinvol is), automatiseer de ACME-, SCEP- en EST-registratie en distribueer vertrouwensankers.
04. Oversnijden	Schakel veilig over	Voer oude en nieuwe certificaatketens parallel uit, valideer volledige paden in de testomgeving, roteer certificaten geleidelijk en beëindig het oude vertrouwensmodel nadat de acceptatie is bevestigd.

Er zijn twee mogelijke faalscenario's waartegen expliciet ontworpen moet worden: migreren op de ingangsdatum in plaats van ervoor, en de oude keten intrekken voordat elke gebruiker de nieuwe daadwerkelijk heeft geaccepteerd. Beide scenario's veranderen een geplande migratie in een storing.

Hoe de PKIaaS-oplossing van Encryption Consulting aansluit op deze migratie

De implementatiefase hierboven is waar de meeste teams ofwel snel aan de slag gaan, ofwel maandenlang vastlopen door de aanschaf van hardware, het bemensen van 24/7-operaties en het helemaal opnieuw schrijven van CP/CPS-documentatie. PKI-as-a-Service van Encryption Consulting is ontworpen om dit knelpunt weg te nemen: een volledig beheerde, zeer beschikbare PKI voor één tenant, met CA-sleutels beveiligd in FIPS 140-3 Level 3 HSM's, en CertSecure Manager , EC's CA-agnostische platform voor certificaatlevenscyclusbeheer, erbovenop voor zichtbaarheid en automatisering binnen de gehele organisatie.

Basis: Uw root-CA, ondergeschikte CA's en OCSP/CRL-services worden volledig gehost, zonder dat u een eigen CA-infrastructuur hoeft te onderhouden. HSM-as-a-Service betekent dat EC de FIPS 140-3 Level 3-hardware levert en onderhoudt; CA-sleutels blijven binnen de HSM en kunnen nooit naar software worden geëxporteerd, terwijl u de controle en het eigendom van de sleutels behoudt.

Operationele aspecten: CertSecure Manager biedt volledig inzicht in uw certificaatomgeving en automatiseert de detectie, registratie, verlenging en intrekking van openbare, private en PKIaaS-certificaten via ACME, SCEP en EST. Omdat de service volledig beheerd wordt, bewaakt EC 24/7 de status van de certificeringsinstantie (CA), de verlenging van certificatenreferenties (CRL's), de status van de hardwaremanagementsystemen (HSM's) en de vervaldatum van certificaten. Hierdoor worden problemen opgespoord voordat ze leiden tot de eerder in dit artikel beschreven stille storingen.

Governance: EC biedt CP/CPS-documentatie en sjabloonbeheer, op rollen gebaseerde toegangscontrole en bekrachtigde, gedocumenteerde sleutelceremonies, hetzelfde beheer waar een auditor tijdens een audit om zal vragen. Certificaatprofielen zijn speciaal ontworpen voor deze migratie, met ingebouwde crypto-flexibiliteit zodat hybride en PQC-compatibele certificaatprofielen beschikbaar zijn naarmate standaarden evolueren, in plaats van dat er later een nieuw migratieproject nodig is.

Afgestemd op het vierfasenplan: Ontdekken en Ontwerpen is doorgaans een gezamenlijke oefening met uw team; Implementeren is waar PKIaaS het meeste werk verricht, door binnen enkele weken een beheerde hiërarchie op te zetten in plaats van de maanden die een volledig nieuwe implementatie normaal gesproken kost; en Overgang wordt ondersteund door de automatisering van CertSecure Manager, zodat een parallelle uitrol geen handmatige, foutgevoelige uitrol wordt.

Veelgestelde Vragen / FAQ

Wat is de clientAuth EKU en waarom wordt deze verwijderd uit openbare TLS-certificaten?

De clientAuth Extended Key Usage (OID 1.3.6.1.5.5.7.3.2) maakt het mogelijk dat een TLS-certificaat zich als client authenticeert, naast de rol van serverAuth om een ​​server te authenticeren bij browsers. Chrome Root Program Policy v1.8 verwijdert deze functie uit openbare leaf-certificaten, omdat openbare uitgifte alleen de domein- of organisatie-identiteit valideerde en nooit de clientautorisatie, en omdat een certificaat met een dubbele functie de mogelijkheden van een gestolen sleutel verdubbelt.

Is mijn echte deadline 15 maart 2027 volgens Chrome, of iets anders?

Vrijwel zeker iets eerder. Openbare certificeringsinstanties zoals DigiCert, Sectigo, Let's Encrypt, Google Trust Services en SSL.com hebben allemaal hun eigen deadlines vastgesteld vóór de handhavingsdatum van Chrome, waarvan sommige al in 2025. Raadpleeg de adviespagina van uw specifieke certificeringsinstantie in plaats van alleen te vertrouwen op de branchebrede datum.

Kan ik clientAuth werkend houden door mijn huidige certificaat opnieuw uit te geven of vast te zetten?

Nee. Verificatiesystemen berekenen de effectieve EKU als de intersectie van elk certificaat in de keten. Zodra de hiërarchie van uw uitgevende CA overgaat naar serverAuth-only, kan een tussenliggend certificaat clientAuth uitsluiten voor alles daaronder, en het opnieuw uitgeven of vastzetten van het bladcertificaat verandert daar niets aan.

Wat gaat er als eerste kapot als clientAuth uit mijn certificaten verdwijnt?

Alles wat afhankelijk is van wederzijdse TLS voor machine- of clientidentificatie: service mesh sidecars, partner API gateways, IoT-apparaten, VPN-clients en elke load balancer of middleware die expliciet is geconfigureerd om de clientAuth EKU af te dwingen. De fout treedt niet op op de handhavingsdatum, maar bij de volgende certificaatvernieuwing en de daaropvolgende mTLS-handshake.

Draagt ​​de migratie naar een private PKI ook bij aan de paraatheid na de kwantumcrisis?

Ja, indirect maar wel nuttig. Omdat je de hiërarchie beheert, kun je hybride en ML-DSA-certificaatprofielen binnen je eigen private PKI testen, ruim voordat het publieke certificaatecosysteem deze uitrolt na de quantumuitrol. Hierdoor krijg je een voorsprong in plaats van dat het later een apart project wordt.

Ben je klaar om te zien waar je staat?

Doorloop deze week de bovenstaande checklist voor certificaatbeheer aan de hand van uw eigen certificatenportfolio. Wanneer u klaar bent om de private PKI-kant te ontwerpen en te implementeren, bekijk dan hoe PKI-as-a-Service aansluit op deze specifieke migratie , of neem contact op met het PKI-team van Encryption Consulting voor een beoordeling van uw certificaatbeheer en migratie.