Overzicht
Sinds 15 september 2025 is SSL.com's TLS Servercertificaten zijn uitgegeven zonder de extensie voor uitgebreid sleutelgebruik (EKU) voor clientauthenticatie. Deze wijziging werd ingegeven door de Beleid voor het rootprogramma van Google ChromeHier leggen we uit wat EKU's zijn, waarom deze wijziging heeft plaatsgevonden, hoe deze serveromgevingen beïnvloedt en welke acties u mogelijk moet ondernemen. We bieden ook een FAQ en technische handleidingen voor verschillende scenario's.
update: Het verwijderen van de clientAuth EKU is een vereiste van CA/Browser Forum, geen wijziging die alleen voor Chrome geldt. Belangrijke openbare certificeringsinstanties, waaronder SSL.com, hebben de clientAuth EKU al verwijderd uit nieuwe en verlengde certificaten. TLS servercertificaten worden sinds eind 2025 niet meer gebruikt en de definitieve deadline voor de verwijdering hiervan is 15 maart 2027. Als uw systemen afhankelijk zijn van de clientAuth EKU voor wederzijdse authenticatie, dan is dit niet het geval. TLSVoor VPN-authenticatie of een vergelijkbaar gebruiksscenario is het raadzaam om dat scenario over te zetten naar een speciaal clientauthenticatiecertificaat voordat uw huidige certificaten worden vernieuwd. Certificaten die vóór de uiterste datum van de betreffende certificeringsinstantie zijn uitgegeven, blijven geldig tot ze verlopen.
Als u ClientAuth gebruikt in een van uw TLS Voor servercertificaten raden we u aan contact op te nemen met ons team, zodat we samen de beste oplossing voor uw organisatie kunnen vinden.
Wat zijn Extended Key Usages (EKU's)?
Uitgebreid sleutelgebruik (EKU), is een certificaatuitbreiding die de beoogde functie van een openbare sleutel binnen een digitaal certificaat definieert. Het stelt een gestructureerde set van toegestane toepassingen vast, waardoor wordt gewaarborgd dat de sleutel alleen wordt gebruikt voor specifieke cryptografische bewerkingen. Deze functionaliteit wordt beheerd door Objectidentificatoren (OID's)—unieke numerieke identificatiegegevens die elk toegestaan gebruik categoriseren, zoals codeondertekening, serverauthenticatie, clientauthenticatie of beveiligde e-mail. Wanneer authenticatie op basis van certificaten plaatsvindt, controleert de verifiërende entiteit het certificaat om de Object Identifier (OID) binnen de EKU te identificeren. Door de EKU-extensie in te sluiten, Certificate Authority (CA) beperkt de reikwijdte van het certificaat tot vooraf gedefinieerde rollen, waarbij elk aangewezen doel expliciet wordt toegewezen aan een OID.
Bijvoorbeeld:
- TLS Webserver-authenticatie – Geeft aan dat het certificaat kan worden gebruikt om een server te verifiëren (bijvoorbeeld een HTTPS-website). De OID die overeenkomt met Server Authenticatie is 1.3.6.1.5.5.7.3.1
- TLS Webclient-authenticatie – Geeft aan dat het certificaat door een client kan worden gebruikt om zich te verifiëren bij een server (bijvoorbeeld een clientcertificaat voor wederzijdse verificatie). TLS). De OID die is toegewezen aan clientauthenticatie is 1.3.6.1.5.5.7.3.2
Browsers en servers hebben alleen de serverAuth EKU naar oprichten een beveiligde verbinding voor HTTPS maar historisch gezien veel TLS servercertificaten bevatten zowel de serverAuth en clientAuth EKU's. Hieronder is een voorbeeld van zo'n certificaat:
Wat is gebeurt er?
Vanaf september 15, 2025, SSL.com zal kwestie TLS certificaten die alleen de serverAuth EKU (En niet clientAuth) voor servercertificaten. Met andere woorden, nieuwe SSL/TLS certificaten voor uw website of server zijn expliciet alleen bedoeld voor “serverauthenticatie”.
Waarom de clientAuth EKU van servercertificaten?
Er zijn verschillende redenen voor dit mandaat:
- Beveiliging en reikwijdte: Publieke TLS certificaten zijn alleen bedoeld om servers te authenticeren op het web. De verwijdering zorgt voor een duidelijke scheiding tussen server- en clientfunctionaliteit. De ClientAuth EKU wordt gebruikt voor authenticatie van machines en gebruikers met Mutual TLS (mTLS) en andere authenticatiescenario's.
- Voorkom verkeerde configuratie: Sommige systemen vertrouwen mogelijk elke certificaat van een openbare CA voor clientauthenticatie als de EKU aanwezig is, wat een beveiligingsrisico kan vormen.
- Browservereisten: De belangrijkste browsers vereisen of controleren de clientAuth EKU niet in het certificaat van een website.
- Vereenvoudigd PKI architectuur: Door het scheiden van gebruiksdoeleinden kunnen CA's afzonderlijke certificaathiërarchieën voor servers onderhouden TLS versus andere doeleinden.
Naleving van de branche
Deze beleidswijziging is een vereiste van CA/Browser Forum die gefaseerd in de hele branche wordt ingevoerd, waarbij het Chrome Root Program de definitieve handhavingsdatum heeft vastgesteld op 15 maart 2027. TLS server certificaten.
Impact op serveromgevingen
Voor de overgrote meerderheid van de serverimplementaties zal deze wijziging van kracht zijn lage impact or geen impact. Dit is wat je kunt verwachten:
- Standaard webservers (HTTPS): Geen impact. De bijgewerkte certificaten blijven normaal functioneren.
- Bestaande certificaten: Elk afgegeven certificaat vaardigheden De afsluiting blijft van kracht totdat deze verloopt.
- Wederzijds TLS (mTLS) en clientcertificaatscenario's: Als u een TLS servercertificaat voor client authenticatie, moet u een apart certificaat verkrijgen met de clientAuth EKU van een andere bron.
- Bedrijfssystemen die beide EKU's nodig hebben: Sommige legacy- of enterprisesystemen verwachtten beide EKU's. U moet controleren of er updates nodig zijn om te voldoen aan de nieuwe regels.
- Certificaten voor API-clients, IoT-apparaten, enz.: Als uw use case afhankelijk is van clientAuth EKU, moet u een speciaal clientauthenticatiecertificaat verkrijgen. SSL.com biedt Clientauthenticatiecertificaten.
Vereiste acties voor klanten
- Inventariseer uw certificaten: Identificeer er een TLS certificaten in gebruik en controleer op de clientAuth EKU.
- Identificeer eventuele gevallen van dubbel gebruik: Bepaal of een van uw systemen afhankelijk is van een TLS certificaat voor clientauthenticatie.
- Plan voor certificaatvernieuwing/heruitgifte: Toekomstige certificaten worden standaard zonder clientAuth EKU uitgegeven.
- Indien nodig eerder opnieuw uitgeven: Als u uw certificaten proactief wilt bijwerken, kunt u ze vóór de deadline opnieuw uitgeven.
- Verkrijg indien nodig clientverificatiecertificaten: Beveilig een apart certificaat met de clientAuth EKU indien nodig.
- Documentatie en configuratie bijwerken: Wijzig alle geautomatiseerde scripts voor certificaataanvragen of documentatie die er eerder van uitgingen dat beide EKU's aanwezig zouden zijn.
FAQ (Meest Gestelde Vragen)
V1. Wat is de “Client Authentication” EKU en waarom stond deze in mijn certificaat?
De EKU “Client Authentication” geeft aan dat een certificaat door een client kan worden gebruikt om te authenticeren bij een server. Sommige CA's hebben het historisch opgenomen in TLS certificaten standaard, maar dit was nooit vereist voor normale websitebeveiliging.
Q2. Worden mijn certificaten door browsers geweigerd als ze de clientAuth EKU bevatten?
Nee. Browsers weigeren geen bestaande certificaten met de clientAuth EKU. De wijziging van september 2025 had alleen betrekking op de uitgifte van nieuwe certificaten. Een certificaat dat vóór die datum is uitgegeven, blijft geldig tot de vervaldatum.
Q3. Mijn huidige TLS certificaat zegt "Client Authentication" onder zijn Extended Key Usage. Is het nu ongeldig?
Nee, het blijft geldig. U hoeft het niet direct te vervangen. Wanneer u verlengt, bevat het nieuwe certificaat simpelweg niet de clientAuth EKU.
V4. Hoe kan ik controleren of een certificaat de clientAuth EKU heeft?
U kunt de certificaatgegevens inspecteren met OpenSSL, PowerShell of GUI-tools om te controleren of de Uitgebreid sleutelgebruik verlenging.
Q5. Ons systeem vereist dat het servercertificaat zowel serverAuth als clientAuth EKU's heeft. Wat moeten we doen?
U moet uw systeem updaten zodat alleen serverAuth voor servercertificaten. Als clientauthenticatie nodig is, verkrijg dan een apart certificaat met de clientAuth EKU van SSL.com.
V6. Kan ik nog steeds een openbaar vertrouwd certificaat krijgen met alleen Client Authentication EKU?
Sommige CA's, zoals SSL.com, bieden speciale client-authenticatiecertificaten. Deze zijn los van TLS certificaten en worden doorgaans gebruikt voor bedrijfsauthenticatie.
V7. Heeft dit gevolgen voor andere EKU's of certificaattypen (codeondertekening, e-mail, enz.)?
Nee, deze wijziging is specifiek voor TLS server certificatenVoor codeondertekening en e-mailcertificaten gelden eigen EKU-vereisten.
Q8. We gebruiken client certificaat authenticatie op onze website. Heeft deze verandering daar invloed op?
Nee, wederzijds TLS (mTLS) authenticatie werkt nog steeds. Zorg er echter voor dat clientcertificaten die door gebruikers worden gepresenteerd nog steeds de clientAuth EKU indien vereist.
V9. Heeft dit te maken met de aanstaande wijziging naar kortere certificaatlevensduur (certificaten van 90 dagen)?
Nee, dit zijn afzonderlijke veranderingen in de sector, hoewel ze beide gericht zijn op het verbeteren van de beveiliging en het beheer van certificaten.
V10. Waar kan ik de officiële vereisten voor deze wijziging vinden?
De Beleid voor het rootprogramma van Google Chrome geeft richtlijnen over het verbod op de clientAuth EKU in TLS server certificaten.
Samenvatting
Het verwijderen van de clientAuth EKU uit TLS servercertificaten is een sectorbrede beleidswijziging die de beveiliging zal verbeteren en misbruik zal voorkomen. Voor de meeste gebruikers zal er geen merkbare impact zijn. Als u echter afhankelijk bent van de clientAuth EKU, moet u proactieve stappen ondernemen om het juiste type certificaat voor uw behoeften te verkrijgen.
Als u vragen heeft of hulp nodig heeft, neem dan contact op met ons ondersteuningsteam via ondersteuning@ssl.com.
