Waarom verwijdert GoDaddy ClientAuth EKU en gaat het over naar de R1 -hoofdhiërarchie voor DV TLS -uitgifte?

Vanaf 15 juni 2026 mogen openbaar vertrouwde SSL/TLS -certificaten die zijn uitgegeven voor servergebruik niet langer het uitgebreide sleutelgebruik "Client Authentication" (EKU: clientAuth) bevatten. Hier zijn de belangrijkste punten om te begrijpen:

• De wijziging maakt deel uit van de update van het Chrome Root Program -beleid: nieuwe certificaten mogen alleen de EKU voor serververificatie bevatten.
• Nieuwe openbare certificaten die na die datum zijn uitgegeven en die clientAuth bevatten, worden niet vertrouwd door Chrome.
• Certificaten die vóór 15 juni 2026 zijn uitgegeven met clientAuth worden niet beïnvloed door deze wijziging en blijven geldig tot ze verlopen of worden ingetrokken.
• Privé-CA-certificaten (voor intern gebruik) worden niet beïnvloed door deze wijziging & mdash; deze is alleen van toepassing op openbaar vertrouwde certificaten.

Kort gezegd: als je organisatie openbare TLS -certificaten gebruikt voor clientauthenticatie (via clientAuth EKU), moet je voor 15 juni 2026 handelen. Voor standaard website -TLS -gebruik (alleen serverauthenticatie) vereist deze wijziging geen actie. Het is echter een tijdige herinnering om je certificaat van gebruik te bekijken, functies op de juiste manier te scheiden en ervoor te zorgen dat je in lijn bent met het zich ontwikkelende vertrouwensmodel.

Hoe GoDaddy deze wijziging implementeert

Onze huidige G2 -ondertekenings-/uitgevende tussenpersonen hebben geen EKU -lijst, waardoor deze hiërarchie niet voldoet aan de vereisten van het Chrome Root Program. Als gevolg hiervan moet de uitgifte van de betrokken G2 -tussenproducten op die datum zijn gestopt.

In plaats van nieuwe uitgiftetussenproducten te maken voor de G2 -keten & mdash; die naar verwachting verloopt/beëindigd wordt bij Google in april 2027 & mdash; verplaatsen we DV -uitgifte naar onze nieuwe R1 -hiërarchie om te voldoen aan de toekomstige beleidsbeperkingen.

We wijzigen de openbare DV -uitgifteketen, zodat nieuwe DV -leaf -certificaten worden uitgegeven vanuit de GoDaddy TLS Root CA - R1 -hiërarchie, met behulp van de GoDaddy TLS Intermediate CA DV - R1v1 die CA -certificaten afgeeft. godaddy.com. Dit betekent dat de issuer -keten die wordt weergegeven door servers (leaf + intermediate) kan verschillen van wat sommige systemen in het verleden hebben gezien, en alle interne tools die uitgaan van een specifieke legacy tussenliggende naam of ketenvolgorde moeten worden bijgewerkt om de nieuwe R1 -keten te accepteren.

Bovendien bevatten leaf -certificaten die vanuit deze hiërarchie zijn uitgegeven geen ClientAuth EKU. Elke werkstroom die afhankelijk was van DV -leaf -certificaten die bruikbaar waren voor TLS -clientverificatie, moet worden gemigreerd naar een geschikt certificaatprofiel/PKI -pad. Tijdens de uitrol blijven certificaten operationeel in browsers omdat clients valideren met behulp van het vereiste cross-signing-pad R1 → G2 dat is gepubliceerd in onze repository (certs.godaddy.com).

Hoe certificaten browser-operationeel blijven tijdens de R1-overgang (R1 → G2-kruisteken)

Terwijl we openbare DV TLS -uitgifte migreren naar de R1 -hiërarchie, wordt de R1 -hoofdmap nog steeds breed vertrouwd/gedistribueerd in vertrouwensarchieven van browsers en besturingssystemen. Om ervoor te zorgen dat nieuw uitgegeven R1-certificaten onmiddellijk werken in browsers, vertrouwen we op een kruiselings ondertekend vertrouwenspad terug naar de al vertrouwde G2-hoofdmap.

In de praktijk wordt het leaf -certificaat uitgegeven onder de R1 DV -uitgevende CA, maar clients valideren het door een keten te bouwen naar GoDaddy Class 2 Root - G2 met behulp van het gepubliceerde R1 → G2 -kruiscertificaat. De relevante artefacten in de repository zijn het G2-vertrouwensanker (gdroot-g2), het kruiscertificaat (gd_tls_root-r1-cross-g2), het R1 DV-uitgevende tussenproduct (gd_tls_issuing_dv-r1v1) en de systeemeigen hiërarchie-root (gd_tls_root-r1) ) certs.godaddy.com. Deze cross-sign-benadering stelt browsers in staat om de keten vandaag te valideren (verankering bij G2), terwijl R1-vertrouwen zich in de loop van de tijd voortplant.

Waarom wordt deze wijziging doorgevoerd?

Er zijn verschillende redenen om af te stappen van certificaten die zowel serverAuth als clientAuth ondersteunen (ook wel certificaten voor gemengd gebruik genoemd):

• Door serververificatie te scheiden van clientverificatie, wordt het vertrouwensmodel voor certificaten eenvoudiger.
• Verbeterde veiligheidshygiëne: Certificaten met te veel doelen verhogen het risico (dat wil zeggen misbruik van clientAuth op onbedoelde manieren).
• Het gebruik van speciale PKI -hiërarchieën voor verschillende functies helpt om duidelijkere vertrouwensgrenzen te behouden, in lijn met bredere PKI -best practices (Public Key Infrastructure).

Wat zijn de voordelen van deze wijziging?

• Verminderd risico van multifunctionele certificaten: door openbare certificaten te beperken tot alleen serverAuth, wordt het aanvalsoppervlak verkleind en zijn de vertrouwensgrenzen duidelijker.
• Betere naleving & Beheer: organisaties hebben een duidelijkere scheiding tussen serververificatie en clientverificatie, wat een betere controle en certificaatlevenscyclusbeheer kan ondersteunen.
• Verbeterde operationele duidelijkheid: wanneer clientAuth -functionaliteit wordt opgesplitst in geschikte certificaten of infrastructuur, is het eenvoudiger om rollen, intrekkingen en verlengingen te beheren en ervoor te zorgen dat het juiste certificaat wordt gebruikt voor het juiste doel.
• Toekomstige paraatheid: Deze wijziging sluit aan bij de evoluerende PKI / browser -vertrouwensmodellen en helpt organisaties te positioneren voor nieuwere beveiligingsmodellen en automatisering.

Wie heeft er geen last van?

De meeste websites die certificaten alleen voor serverauthenticatie gebruiken (dat wil zeggen, typische TLS/HTTPS) worden niet beïnvloed. Als je het certificaat alleen gebruikt om je website te beveiligen voor gebruikers, is er geen actie vereist voor deze wijziging.

Wie heeft er last van?

Deze wijziging is van invloed op organisaties die openbaar vertrouwde servercertificaten gebruiken voor clientverificatie (ook wel wederzijdse TLS / mTLS genoemd) of server-naar-server-verificatie die afhankelijk zijn van de clientAuth EKU. Deze wijziging kan bijvoorbeeld gevolgen hebben voor sommige financiële services, SaaS-services of multi-tenant API's.

Wat je moet doen

• Als je gehost wordt buiten GoDaddy : Zorg ervoor dat de volledige bundel geleverd door de download -eindpunten of de klantinterface wordt geïnstalleerd wanneer je je volgende certificaat bijwerkt.
• Als je certificaten gebruikt die afhankelijk zijn van ClientAuth (mTLS) : Zorg ervoor dat je die werkstromen migreert om een zelfondertekend certificaat of een privé-CA-oplossing te gebruiken.

Teams moeten ook bevestigen dat geen enkele interne functie of documentatie ervan uitgaat dat DV-leaf-certificaten ClientAuth EKU bevatten, aangezien R1-uitgegeven leaf-certificaten dit niet bevatten.

Betekent dit dat alle certificaten die na 15 juni 2026 zijn uitgegeven, ongeldig zijn?

Nee. Certificaten die voor 15 juni 2026 zijn uitgegeven en die clientAuth bevatten, blijven geldig (tot de vervaldatum) onder het bestaande vertrouwensmodel. De wijziging is alleen van invloed op nieuwe openbare certificaten die op of na die datum zijn uitgegeven.

Moet ik iets doen als ik mijn certificaat alleen gebruik voor een typische HTTPS -website (serververificatie)?

Als je hosting buiten GoDaddy ligt, moet je er nog steeds voor zorgen dat de bundel correct wordt gebruikt.

Wat is "cliëntauthenticatie" precies in deze context?

Clientauthenticatie verwijst naar het gebruik van een certificaat door een client (gebruiker, apparaat of een andere server) voor authenticatie bij de server. Het wordt vaak gebruikt bij mTLS (wederzijdse TLS) of server-to-server API-verificatie waarbij de server het certificaat moet verifiëren dat wordt aangeboden door de verbindende client.

Kan ik nog steeds clientAuth -certificaten gebruiken?

Ja & mdash; maar voor openbaar vertrouwen moet u een certificaat gebruiken dat specifiek is uitgegeven voor clientauthenticatie (d.w.z. dedicated clientAuth EKU) of u moet een privé -CA gebruiken voor uw interne systemen. Openbare servercertificaten met clientAuth EKU worden niet langer vertrouwd in Chrome als ze zijn uitgegeven na 15 juni 2026.

Zullen andere browsers deze wijziging afdwingen of alleen Chrome?

Het beleid is afkomstig van het Chrome Root Program, maar wijzigingen in het openbare PKI -ecosysteem hebben vaak invloed op andere browsers en trustwinkels. Het is verstandig om een bredere toepasbaarheid aan te nemen, anders is toekomstige compliance van belang voor alle platforms.

Is dit van toepassing op interne/privé CA -certificaten?

Nee & mdash; de wijziging heeft alleen betrekking op openbaar vertrouwde SSL/TLS-certificaten (die worden vertrouwd door de openbare rootopslagplaatsen). Privé -CA -infrastructuur die wordt gebruikt voor interne clientverificatie wordt niet rechtstreeks beïnvloed.

Wanneer moeten we klaar zijn voor deze wijziging?

De beoogde tijdlijn is 27 mei 2026. Op die datum moeten de verantwoordelijke teams de gereedheidsvalidatie hebben voltooid (uitgifteconfiguratie, bundel-/download -correctheid, installatierichtlijnen voor de implementatieketen, bewaking en EKU -afhankelijkheidscontroles), zodat de uitrol kan worden voortgezet zonder dat de service wordt onderbroken.

Meer informatie

• Mijn SSL-certificaat instellen en installeren
• Als jij of je klanten "niet -vertrouwde root" of certificaatketenfouten zien, raadpleeg dan onze stappen om het probleem op te lossen .