Varför tar GoDaddy bort ClientAuth EKU och övergår till R1-rothierarkin för DV TLS-utfärdande?
Från och med den 15 juni 2026 har offentligt betrodda SSL / TLS-certifikat som utfärdats för serveranvändning inte längre tillåtelse att inkludera användning av den ”utökade nyckeln” Client Authentication (EKU: clientAuth). Här är de viktigaste punkterna att förstå:
- Ändringen är en del av uppdateringen av Chrome-rotprogrammet: nya certifikat får endast innehålla EKU för ”serverautentisering”.
- Nya offentliga certifikat som utfärdats efter det datumet och som inkluderar clientAuth kommer inte att betrodda av Chrome.
- Certifikat som utfärdats med clientAuth före den 15 juni 2026 påverkas inte av den här ändringen och förblir giltiga tills de löper ut eller återkallas.
- Privat-CA-certifikat (för internt bruk) påverkas inte av den här ändringen & mdash; den gäller endast offentligt betrodda certifikat.
Kort sagt: om din organisation använder offentliga TLS-certifikat för klientautentisering (via clientAuth EKU) måste du agera före den 15 juni 2026 . För vanlig TLS-webbplatsanvändning (endast serverautentisering) kräver denna ändring inte någon åtgärd. Det är dock en påminnelse om att granska ditt användningscertifikat, separera funktioner på rätt sätt och se till att du passar in i den föränderliga tillitsmodellen.
Hur GoDaddy kommer att genomföra denna ändring
Våra nuvarande mellanprodukter för G2-signering / utfärdande har ingen EKU listad, vilket gör att hierarkin inte uppfyller kraven för Chrome Root Program. Som ett resultat måste utfärdandet från de påverkade G2-mellanprodukterna upphöra senast det datumet.
Istället för att skapa nya utfärdande mellanprodukter i G2-kedjan & mdash; som är planerad att upphöra / avslutas med Google i april 2027 & mdash; flyttar vi DV-utfärdandet till vår nya R1-hierarki för att möta policybegränsningarna framöver.
Vi håller på att ändra den offentliga DV-utfärdarkedjan så nya DV-certifikat utfärdas från GoDaddy TLS rot CA - R1-hierarkin, med användning av GoDaddy TLS mellanliggande CA DV - R1v1 utfärdande CA-certifikat.godaddy.com. Det innebär att utfärdarkedjan som presenteras av servrar (löv + mellanliggande) kan skilja sig från vad vissa system tidigare har sett, och alla interna verktyg som förutsätter ett specifikt äldre mellanliggande namn eller kedjeordning måste uppdateras för att acceptera den nya R1-kedjan.
Dessutom innehåller lövcertifikat som utfärdats från den här hierarkin inte ClientAuth EKU. Alla arbetsflöden som förlitar sig på att DV-lövcertifikat kan användas för TLS-klientautentisering måste migrera till en lämplig certifikatprofil / PKI-sökväg. Under lanseringen fortsätter certifikaten att fungera i webbläsare eftersom klienter validerar med den obligatoriska korssignerade sökvägen R1 → G2 som publiceras i vårt arkiv (certs.godaddy.com).
Hur certifikat förblir webbläsaroperativa under R1-övergången (R1 → G2-korsmärke)
När vi migrerar offentlig DV TLS-utfärdande till R1-hierarkin håller R1-roten fortfarande på att bli pålitligt / distribuerat i webbläsar- och OS-tillitsbutiker. För att se till att nyligen utfärdade R1-certifikat fungerar omedelbart i webbläsare är vi beroende av en korssignerad tillitsväg tillbaka till den redan pålitliga G2-roten.
I praktiken utfärdas lövcertifikatet under utfärdande CA för R1 DV, men klienter bekräftar det genom att bygga en kedja till GoDaddy klass 2 rot - G2 med det publicerade korscertifikatet R1 → G2. De relevanta artefakterna i arkivet är G2-förtroendeankaren (gdroot-g2), korscertifikatet (gd_tls_root-r1-cross-g2), R1 DV-utfärdande mellanprodukt (gd_tls_issuing_dv-r1v1) och den inbyggda hierarkiroten (gd_tls_root-r1 ) certs.godaddy.com. Det här korsmärket gör det möjligt för webbläsare att validera kedjan idag (förankring vid G2), medan R1-förtroendet sprids över tiden.
Varför görs den här ändringen?
Det finns flera anledningar till att flytta ifrån certifikat som stöder både serverAuth och clientAuth (kallas även blandcertifikat):
- Att separera serverautentisering från klientautentisering underlättar certifikatförtroendemodellen.
- Förbättrad säkerhetshygien: Certifikat med för många syften ökar risken (det vill säga missbruk av clientAuth på oavsiktligt sätt).
- Genom att använda dedikerade PKI-hierarkier för olika funktioner kan du upprätthålla tydligare tillitsgränser och anpassa sig till bredare PKI-metoder (Public Key Infrastructure).
Vilka är fördelarna med den här ändringen?
- Minskad risk från mångsidiga certifikat: Genom att begränsa offentliga certifikat till endast serverAuth minskas attackytan och tillitsgränserna blir tydligare.
- Bättre efterlevnad & styrning: Organisationer skiljer sig tydligare mellan serverautentisering och klientautentisering, vilket kan stödja bättre granskning och certifikatets livscykelhantering.
- Förbättrad operativ tydlighet: När clientAuth-funktionaliteten är uppdelad i lämpliga certifikat eller infrastruktur är det enklare att hantera roller, återkallanden, förnyelser och se till att rätt certifikat används för rätt ändamål.
- Framtidens beredskap: Den här ändringen överensstämmer med föränderliga modeller för PKI / webbläsarförtroende och hjälper organisationer att positionera sig för nyare säkerhetsmodeller och automatisering.
Vem påverkas inte?
De flesta webbplatser som endast använder certifikat för serverautentisering (det vill säga typisk TLS / HTTPS) påverkas inte. Om du bara använder certifikatet för att skydda din webbplats för användarna behöver du inte vidta någon ändring.
Vem påverkas?
Den här ändringen påverkar organisationer som använder offentligt betrodda servercertifikat för klientautentisering (kallas även ömsesidig TLS / mTLS) eller server-till-server-autentisering som är beroende av clientAuth EKU. Till exempel kan vissa finansiella tjänster, SaaS-tjänster eller API för flera klienter påverkas av den här ändringen.
Vad du behöver göra
- Om du ligger utanför GoDaddy : Se till att hela paketet som tillhandahålls av nedladdningspunkterna eller kundgränssnittet installeras när du uppdaterar ditt nästa certifikat.
- Om du använder certifikat i något användningsfall som är beroende av ClientAuth (mTLS) : Se till att du migrerar dessa arbetsflöden för att använda ett självsignerat certifikat eller en privat CA-lösning.
Team bör också bekräfta att ingen intern funktion eller dokumentation förutsätter att DV-certifikat inkluderar ClientAuth EKU, eftersom R1-utfärdade bladcertifikat inte inkluderar det.
Betyder detta att alla certifikat som utfärdats efter den 15 juni 2026 är ogiltiga?
Nej. Certifikat som utfärdats före 15 juni 2026 och som inkluderar clientAuth förblir giltiga (tills de löper ut) enligt den befintliga förtroendemodellen. Ändringen påverkar endast nya offentliga certifikat som utfärdats samma datum eller senare.
Om jag bara använder mitt certifikat för vanlig HTTPS på webbplatsen, behöver jag göra något?
Om din värdtjänst ligger utanför GoDaddy måste du fortfarande se till att paketet används korrekt.
Vad är ”klientautentisering” i detta sammanhang?
Med klientautentisering avses att ett certifikat används av en klient (användare, enhet eller annan server) för att autentisera till servern. Det används ofta i mTLS (ömsesidig TLS) eller server-till-server API-autentisering där servern behöver verifiera certifikatet som presenteras av den anslutande klienten.
Kan jag fortfarande använda clientAuth-certifikat?
Ja & mdash; men för allmänhetens förtroende måste du använda ett certifikat som specifikt utfärdats för klientautentisering (det vill säga dedikerad clientAuth EKU) eller använda en privat CA för dina interna system. Offentliga servercertifikat med clientAuth EKU litas inte längre på Chrome om de utfärdas efter 15 juni 2026.
Kommer andra webbläsare att genomdriva denna ändring eller bara Chrome?
Policyn kommer från Chrome Root Program, men ändringar i det offentliga PKI-ekosystemet påverkar ofta andra webbläsare och tillitsbutiker. Det är klokt att anta bredare tillämpbarhet eller åtminstone att framtida efterlevnad kommer att ha betydelse för alla plattformar.
Gäller detta interna / privata CA-certifikat?
Nej & mdash; ändringen påverkar endast offentligt betrodda SSL / TLS-certifikat (de som betrodda av de offentliga rotbutikerna). Privat CA-infrastruktur som används för intern klientautentisering påverkas inte direkt.
När behöver vi vara redo för den här ändringen?
Måltidslinjen är den 27 maj 2026. Vid det datumet ska ansvariga team ha slutfört beredskapsvalideringen (utfärdarkonfiguration, paket- / nedladdningens korrekthet, installationsvägledning för distributionskedjan, övervakning och EKU-beroendekontroller) så att lanseringen kan fortsätta utan att tjänsten störs.