Managementsamenvatting
In deze blogpost worden de komende wijzigingen besproken met betrekking tot het verwijderen van Client Authentication Extended Key Usage (EKU) uit openbaar vertrouwde SSL/TLS-certificaten . Deze verschuiving wordt veroorzaakt door zorgen over de beveiliging en de behoefte aan duidelijker rollen in cryptografische bewerkingen.
Vanaf september 2025 zullen de belangrijkste certificeringsinstanties (CA’s) de Client Authentication EKU geleidelijk uitfaseren bij de openbare uitgifte van certificaten. De definitieve sluitingsdatum voor deze uitbreiding is medio 2026.
Het primaire doel van deze wijzigingen is volgens het CA/B-forum het verminderen van de beveiligingsrisico ’s die gepaard gaan met certificaten voor twee doeleinden en het afdwingen van strengere richtlijnen voor het gebruik ervan. Organisaties die vertrouwen op wederzijdse TLS of clientauthenticatie, zullen speciale clientcertificaten moeten implementeren om naleving te garanderen en een veilige bedrijfsvoering te handhaven. Deze blogpost beschrijft de implicaties van deze wijzigingen, de beveiligingsvoordelen die ze bieden en de stappen die organisaties kunnen ondernemen om zich op deze overgang voor te bereiden.
Introductie
Beveiliging en compliance zijn van cruciaal belang voor organisaties die cryptografische certificaten gebruiken voor authenticatie en communicatie. De verwijdering van de Client Authentication Extended Key Usage (EKU) uit SSL-certificaten zal het gebruik van deze certificaten veranderen, met name in scenario’s met wederzijdse TLS ( mTLS ). Deze blogpost biedt een uitgebreid overzicht van de Client Authentication EKU, de implicaties ervan en de tijdlijn voor de uitfasering ervan . Door deze aankomende veranderingen te begrijpen, kunnen organisaties de nodige maatregelen nemen om ervoor te zorgen dat ze compliant en veilig blijven, en tegelijkertijd de duidelijkheid van hun certificaatbeheer verbeteren.
Wat is Client Authentication Extended Key Usage (EKU)?
De EKU (Extended Key Usage) voor clientauthenticatie is een certificaatuitbreiding die een digitaal certificaat toewijst voor het verifiëren van een client (zoals een gebruiker of apparaat) bij een server. Deze uitbreiding wordt vaak gebruikt in mTLS -scenario’s (mutual TLS).
Het is een functie die aan digitale certificaten wordt toegevoegd en die specificeert waarvoor een openbare sleutel gebruikt mag worden. Het creëert een duidelijke lijst met goedgekeurde toepassingen, zodat de sleutel alleen voor bepaalde cryptografische taken wordt gebruikt. De toegestane toepassingen worden geïdentificeerd door unieke nummers, zogenaamde Object Identifiers (OID’s), die elk specifiek doel categoriseren, zoals codeondertekening, serverauthenticatie, clientauthenticatie of beveiligde e-mail.
Wanneer iemand een certificaat verifieert, kijkt hij of zij naar de EKU om de OID te vinden. Door de EKU-extensie toe te voegen, beperkt een certificeringsinstantie (CA) waarvoor het certificaat gebruikt kan worden, door elk doel aan een specifieke OID te koppelen. Hier zijn een paar voorbeelden:
- TLS-webserverauthenticatie : het certificaat kan worden gebruikt om een server te verifiëren, bijvoorbeeld voor een HTTPS-website. De OID voor serverauthenticatie is 1.3.6.1.5.5.7.3.1 .
- TLS Web Client Authentication : Het certificaat kan door een client worden gebruikt om zichzelf te verifiëren bij een server, zoals in wederzijdse TLS. De OID voor clientauthenticatie is 1.3.6.1.5.5.7.3.2 .
Normaal gesproken hebben browsers en servers alleen de serverAuth EKU nodig om een beveiligde HTTPS-verbinding tot stand te brengen. Veel TLS-servercertificaten bevatten echter in het verleden zowel serverAuth als clientAuth EKU’s.
EKU-gebruik in PKI
- EKU’s beperken de toegestane rollen van een certificaat, zoals serverauthenticatie, clientauthenticatie, codeondertekening of e-mailbeveiliging.
- Wanneer clientauthenticatie vereist is (bijvoorbeeld mTLS ), geeft de aanwezigheid van de clientAuth EKU aan een systeem door dat het certificaat voor dat doel vertrouwd kan worden.
- Historisch gezien bevatten sommige TLS-servercertificaten zowel serverAuth- als clientAuth -EKU’s, maar deze praktijk wordt afgeschaft om beveiligingsrisico’s te verminderen en cryptografische rollen te verduidelijken.
Veranderingen in de industrie
- Vanaf 2025-2026 vereisen grote CA’s en browser root-programma’s (zoals Google Chrome) scheiding van server- en clientauthenticatie-EKU’s. Dit betekent dat openbare TLS-certificaten alleen een serverAuth- EKU mogen hebben en niet een clientAuth-EKU . Dit voorkomt misbruik en verbetert de beveiliging.
- Organisaties die clientauthenticatie nodig hebben, hebben nu speciale clientcertificaten met de clientAuth EKU nodig.
Impact van het verwijderen van Client Authentication EKU op SSL-certificaten
Door de Client Authentication EKU uit SSL-certificaten te verwijderen, worden toekomstige openbare servercertificaten uitsluitend gebruikt voor serverauthenticatie en niet voor client-side doeleinden zoals mutual TLS ( mTLS ).
Impact op het gebruik van SSL-certificaten
- Servercertificaten die na medio 2025 worden uitgegeven, bevatten alleen de serverAuth EKU. Hiermee wordt dubbelzinnig of onveilig gebruik als clientauthenticatiereferentie voorkomen.
- Bestaande certificaten (die vóór de deadline zijn afgegeven) blijven geldig tot de vervaldatum. Ze worden niet met terugwerkende kracht ingetrokken.
- Standaard HTTPS-webservers worden niet beïnvloed, omdat browsers (zoals Chrome en Firefox) alleen controleren op serverauthenticatie en de clientAuth EKU voor websitetoegang negeren.
- Voor omgevingen die afhankelijk zijn van mTLS of client-/apparaatverificatie met openbare SSL-certificaten, is in de toekomst een afzonderlijk clientverificatiecertificaat vereist.
Beveiligings- en nalevingsvoordelen
- Vermindert het risico op misbruik en onbedoeld dubbel gebruik, waardoor de scheiding tussen het openbare internet en interne PKI-infrastructuren wordt verbeterd.
- Zorgt ervoor dat alle certificeringsinstanties (CA’s) en browsers voldoen aan strengere richtlijnen die veilige certificaten voor één doel ondersteunen.
Stappen voor organisaties
- Controleer certificaatinventarissen om te bepalen welke systemen afhankelijk zijn van dual-use /servercertificaten voor clientauthenticatie.
- Werk systemen bij zodat ze speciale clientcertificaten (met clientAuth EKU) gebruiken voor wederzijdse TLS, apparaatverificatie of server-naar-serververbindingen.
- Pas certificaataanvraagprocessen en -documentatie aan, zodat toekomstige verlengingen voldoen aan het nieuwe beleid en serviceonderbrekingen worden voorkomen.
Effectentabel
| Gebruiksscenario |
Wijziging na EKU-verwijdering |
Vereiste actie |
| HTTPS-websites |
Geen impact; standaard SSL blijft bestaan |
Geen |
| Wederzijdse TLS ( mTLS ) |
Servercertificaten kunnen clients niet verifiëren |
Overschakelen naar speciale clientcertificaten |
| Legacy/Enterprise-systemen |
Certificaten voor dubbel gebruik afgewezen; mogelijke incompatibiliteit |
Systemen bijwerken, speciale clientcertificaten gebruiken |
Het verwijderen van de client-authenticatie EKU is een beveiligingsmaatregel om ervoor te zorgen dat SSL-certificaten worden gebruikt waarvoor ze bedoeld zijn. De impact hiervan is minimaal voor de meeste gebruikers, met uitzondering van gebruikers die afhankelijk zijn van mTLS of gemengde authenticatieomgevingen.
Wanneer stoppen CA’s met het uitgeven van certificaten met Client Authentication EKU?
Certificeringsinstanties (CA’s) beginnen vanaf september 2025 met het geleidelijk afschaffen van SSL/TLS-certificaten met de Client Authentication EKU. De definitieve sluitingsdatum is medio 2026, afhankelijk van de CA.
Belangrijke hoogtepunten van de CA-tijdlijn
- 15 september 2025: De meeste grote CA’s, waaronder Sectigo en Trustico , zullen standaard stoppen met het opnemen van de Client Authentication EKU in nieuwe SSL-certificaten.
- 1 oktober 2025: DigiCert stopt standaard met het uitgeven van openbare TLS-certificaten met de ClientAuth EKU. Speciale verzoeken kunnen tot 1 mei 2026 worden gehonoreerd. Daarna kunnen geen openbare certificaten meer met de ClientAuth EKU worden uitgegeven.
- 13-15 mei 2026: Definitieve deadlines voor de hele sector; alle grote certificeringsinstanties (waaronder Let’s Encrypt, Sectigo , DigiCert en Trustico ) zullen de Client Authentication EKU permanent verwijderen uit nieuwe openbare SSL/TLS-certificaatuitgiftes, inclusief verlengingen en heruitgiftes.
- 15 juni 2026: Vanaf deze datum vertrouwt het rootprogramma van Google Chrome alleen nog openbare SSL-certificaten met serverAuth EKU. Vanaf deze datum worden certificaten met ClientAuth EKU afgewezen.
Samenvattingstabel
| CA-naam |
Standaard stopdatum |
Harde deadline |
| Sectigo |
15 september 2025 |
15 mei 2026 |
| DigiCert |
1 oktober 2025 |
1 mei 2026 |
| Laten we encrypteren |
Begin 2026 |
13 mei 2026 |
| Trustico |
15 september 2025 |
15 mei 2026 |
Na deze deadlines zullen geen nieuwe of vernieuwde openbare SSL/TLS-certificaten van grote CA’s meer de Client Authentication EKU bevatten, wat de sectorbrede overgang markeert.
Welke beveiligingsvoordelen brengt het verwijderen van ClientAuth EKU met zich mee?
Volgens het CA/B-forum brengt het verwijderen van de ClientAuth EKU uit openbaar vertrouwde SSL-certificaten verschillende belangrijke beveiligingsvoordelen met zich mee, omdat het certificaatdoelspecifieke regels afdwingt en de risico’s op misbruik of verkeerde configuratie worden verkleind.
Scheiding van vertrouwensrollen
- Openbare servercertificaten worden uitsluitend gebruikt voor serverauthenticatie, niet voor client- of apparaatauthenticatie.
- Hiermee wordt de kans geminimaliseerd dat certificaten voor een andere toepassing worden gebruikt dan waarvoor ze bedoeld zijn. Zo wordt het principe van minimale voorrechten nageleefd.
Minder risico op verkeerde configuratie
- Sommige systemen accepteerden voorheen elk certificaat met een ClientAuth EKU voor clientauthenticatie, wat leidde tot mogelijke ongeautoriseerde toegang als een openbaar servercertificaat ten onrechte werd vertrouwd.
- Door EKU’s te beperken tot het beoogde gebruik, wordt de PKI-architectuur duidelijker en robuuster voor onderhoud en audits.
Verbeterde PKI-hygiëne en -naleving
- Door afzonderlijke certificaathiërarchieën voor server- en clientrollen af te dwingen, kunnen certificeringsinstanties (CA’s) voldoen aan de browservereisten en moderne PKI-standaarden.
- Vermindert de complexiteit en het aanvalsrisico van multifunctionele certificaten, waardoor het eenvoudiger wordt om openbare en privé PKI-implementaties te beheren en beveiligen.
Preventie van misbruik van multifunctionele certificaten
- Certificaten voor gemengd gebruik (met zowel serverAuth- als clientAuth -EKU’s) kunnen worden misbruikt als ze worden gebruikt in onbedoelde authenticatieschema’s, wat mogelijk laterale verplaatsing of escalatie van bevoegdheden mogelijk maakt.
- Door voor elk doel aparte certificaten te vereisen, kunnen organisaties gevoelige toegangsscenario’s beter bewaken, controleren en beheersen.
Samenvattingstabel
| Veiligheidsvoordeel |
Beschrijving |
| Rolscheiding (minste privilege) |
Voorkomt dat certificaten buiten het bereik worden gebruikt |
| Vermindert het risico op verkeerde configuratie |
Voorkomt onbedoelde overlapping van client/server EKU |
| Verbetert de PKI-architectuur |
Maakt duidelijke PKI-scheiding en beleidshandhaving mogelijk |
| Verlaagt het aanvalsoppervlak |
Staat onbedoelde toegang via multifunctionele certificaten niet toe |
Kortom, door ClientAuth EKU uit SSL-servercertificaten te verwijderen, wordt de beveiliging versterkt doordat het certificaatgebruik wordt verduidelijkt, naleving wordt afgedwongen en het risico wordt verkleind dat openbare certificaten worden misbruikt voor gevoelige clientauthenticatiescenario’s.
Hoe bereidt u uw systemen voor op het afschaffen van EKU?
Om systemen voor te bereiden op de afschaffing van Client Authentication EKU , moeten organisaties proactieve stappen ondernemen om te zorgen voor voortdurende veilige werking en naleving vóór de deadlines van 2025-2026.
Voorbereidingsstappen
- Inventaris huidige certificaten en gebruik
- Controleer alle bestaande SSL/TLS-certificaten om te bepalen welke een Client Authentication EKU bevatten .
- Bepaal welke toepassingen afhankelijk zijn van deze certificaten voor clientauthenticatie (bijvoorbeeld wederzijdse TLS, apparaatauthenticatie).
- Bepaal of en hoe deze applicaties, die zowel een openbaar vertrouwd ServerAuth- als ClientAuth-certificaat nodig hebben, de configuratie van afzonderlijke ClientAuth- en ServerAuth-certificaten (en sleutels) daadwerkelijk ondersteunen. Zo niet, neem dan contact op met de leverancier van de applicatie wanneer deze functie wel wordt ondersteund.
- Plan voor certificaatsegmentatie
- Scheid de rollen voor clientauthenticatie en serverauthenticatie door voor elk doel speciale certificaten te gebruiken.
- Verkrijg clientcertificaten met de ClientAuth EKU uitsluitend voor clientverificatie en servercertificaten met de ServerAuth EKU uitsluitend.
- Systemen en applicaties bijwerken
- Pas client- en serversoftware aan om afzonderlijke certificaten voor gemeenschappelijke TLS en andere clientauthenticatiemethoden te ondersteunen.
- Zorg ervoor dat toepassingen EKU-waarden correct valideren om te voorkomen dat onjuiste certificaten worden geaccepteerd.
- Pas certificaatbeheerprocessen aan
- Werk het interne beleid en de documentatie bij zodat deze de nieuwe beperkingen op het gebruik van EKU weerspiegelen.
- Coördineer met CA’s voor certificaatuitgifte zonder ClientAuth EKU in servercertificaten na de deadline.
- Testen en valideren
- Voer tests uit met geplande certificaatwijzigingen in staging- of ontwikkelomgevingen vóór de uitrol in productie.
- Controleer of alle authenticatiestromen, inclusief wederzijdse TLS, correct functioneren met de nieuwe certificaatconfiguraties.
- Communiceer veranderingen
- Informeer belanghebbenden, waaronder IT, beveiligingsteams en applicatie-eigenaren, over de impact van de EKU-afschaffing.
- Geef training of begeleiding over nieuwe certificaatafhandeling en PKI-praktijken.
Samenvattingstabel
| Actie |
Beschrijving |
| Certificaatinventaris |
Certificaten identificeren met ClientAuth EKU |
| Gebruik speciale certificaten |
Scheid client- en serverrollen met relevante EKU’s |
| Systeem-/applicatie-updates |
Ondersteun en handhaaf EKU-specifiek certificaatgebruik |
| Beleids-/procesaanpassing |
EKU-afschrijving weerspiegelen in uitgifte-/verlengingsbeleid |
| Testen en valideren |
Bevestig de functionaliteit met nieuwe certificaatinstellingen |
| Stakeholdercommunicatie |
Informeer teams over EKU-wijzigingen en naleving |
Door deze routekaart te volgen, kunnen organisaties operationele verstoringen tot een minimum beperken en een sterke PKI-beveiliging handhaven tijdens de overgang naar de afschaffing van Client Authentication EKU.
Specifieke informatie voor KeyTalk-klanten
Met de certificaat- en sleutelbeheeroplossing van KeyTalk kunt u certificaten (en privésleutels) automatisch vernieuwen. Bovendien biedt het de mogelijkheid om deze certificaten automatisch door te sturen, te installeren en te configureren op uw doeleindpunt voor een doelapplicatie.
KeyTalk-klanten die behoefte hebben aan openbaar vertrouwde ClientAuth-certificaten, wordt het volgende geadviseerd:
- Maak een nieuwe, speciale certificaatsjabloon aan voor het aanvragen van openbaar vertrouwde ClientAuth-certificaten. De eenvoudigste manier is om uw bestaande multifunctionele certificaatsjabloon te kopiëren en het product te wijzigen naar een ClientAuth-certificaat voor de relevante openbare CA. Vergeet niet uw nieuwe certificaatsjabloon te koppelen aan de Internal Db Registration Authority.
- Definieer handmatig de FQDN’s voor de toepassingen die ClientAuth-certificaten nodig hebben als KeyTalk SEAT’s, of laat deze automatisch aanmaken bij geverifieerde nieuwe certificaataanvragen.
- Controleer of de inschrijving succesvol is en of uw KeyTalk CKMS het juiste type certificaat heeft.
- Schakel ACME in indien van toepassing voor uw nieuwe ClientAuth-certificaatsjabloon en noteer de unieke KeyTalk ACME-server-url
- Configureer waar van toepassing uw bestaande ACME-agents die draaien op de eindpunten die de applicaties hosten die het extra ClientAuth-certificaat nodig hebben, om een extra certificaat aan te vragen dat afkomstig is van de nieuw ingeschakelde ACME-URL
- Configureer waar van toepassing uw bestaande KeyTalk Enterprise-agents die draaien op de eindpunten die de applicaties hosten die het extra ClientAuth-certificaat nodig hebben, om een extra certificaat aan te vragen dat afkomstig is van de nieuw ingeschakelde certificaatsjabloon, EN werk waar nodig de verbonden PowerShell- of Bash-scripts bij om het verkregen ClientAuth-certificaat correct toe te passen op de doelapplicatie.
- Test of de geautomatiseerde ClientAuth-certificaten correct worden opgehaald en correct worden toegepast op uw doelapplicatie(s).
Heeft u vragen over dit artikel of hoe KeyTalk CKMS u helpt bij het vereenvoudigen van het beheer en de automatisering van digitale certificaten? Ons ondersteuningsteam is 24/7 beschikbaar om u te helpen en te begeleiden bij het implementeren van een volledig geautomatiseerde PKI-architectuur via e-mail of via ons contactpagina.
Het KeyTalk Team
