Perché GoDaddy sta rimuovendo l'EKU ClientAuth e sta passando alla gerarchia radice R1 per l'emissione di TLS DV?

A partire dal 15 giugno 2026, i certificati SSL/TLS pubblicamente attendibili emessi per l'uso su server non potranno più includere l'uso della chiave estesa "Autenticazione client" (EKU: clientAuth). Ecco i punti chiave da capire:

• La modifica fa parte dell'aggiornamento dei criteri del programma principale di Chrome: i nuovi certificati devono includere solo l'EKU "Autenticazione server".
• I nuovi certificati pubblici emessi dopo tale data che includono clientAuth non saranno considerati attendibili da Chrome.
• I certificati emessi con clientAuth prima del 15 giugno 2026 non sono interessati da questa modifica e rimarranno validi fino alla scadenza o alla revoca.
• I certificati della CA privata (per uso interno) non sono interessati da questa modifica, ma si applica solo ai certificati pubblicamente attendibili.

In breve: se la tua organizzazione utilizza certificati TLS pubblici per l'autenticazione client (tramite clientAuth EKU), dovrai agire prima del 15 giugno 2026 . Per l'utilizzo standard di TLS per siti web (solo autenticazione server), questa modifica non richiede alcuna azione. Tuttavia, è un promemoria tempestivo per rivedere il certificato di utilizzo, separare le funzioni in modo appropriato e accertarsi di essere in linea con il modello di affidabilità in evoluzione.

Come GoDaddy implementerà questa modifica

I nostri attuali agenti intermedi di firma/emissione G2 non presentano alcun EKU elencato, il che rende tale gerarchia non conforme ai requisiti del programma principale di Chrome. Di conseguenza, l'emissione degli intermedi G2 interessati deve essere interrotta entro tale data.

Piuttosto che creare nuovi prodotti intermedi di emissione sulla catena G2 - che dovrebbe scadere/terminare con Google nell'aprile 2027 - stiamo spostando l'emissione di DV nella nostra nuova gerarchia R1 per soddisfare i vincoli delle politiche future.

Stiamo modificando la catena di emissione DV pubblica in modo che i nuovi certificati foglia DV vengano emessi dalla gerarchia CA radice TLS GoDaddy - R1, utilizzando i certificati CA di emissione CA DV - R1v1 intermedi GoDaddy. Ciò significa che la catena di emittenti presentata dai server (foglia + intermedia) potrebbe differire da quella che alcuni sistemi hanno storicamente visto e qualsiasi strumento interno che presuppone uno specifico nome intermedio o ordine di catena legacy deve essere aggiornato per accettare la nuova catena R1.

Inoltre, i certificati foglia emessi da questa gerarchia non conterranno l'EKU ClientAuth. Qualsiasi flusso di lavoro che si basa su certificati foglia DV utilizzabili per l'autenticazione client TLS deve migrare a un profilo di certificato/percorso PKI appropriato. Durante l'implementazione, i certificati rimangono operativi nei browser perché i client eseguono la convalida utilizzando il percorso di attendibilità con firma incrociata R1 → G2, pubblicato nel nostro repository (certs.godaddy.com).

In che modo i certificati rimangono operativi sul browser durante la transizione R1 (segno incrociato R1 → G2)

Durante la migrazione delle emissioni TLS DV pubbliche alla gerarchia R1, la radice R1 è ancora in procinto di essere ampiamente attendibile/distribuita nei browser e nei trust store del sistema operativo. Per garantire che i certificati R1 di nuova emissione funzionino immediatamente nei browser, ci affidiamo a un percorso di attendibilità con firma incrociata alla radice G2 già attendibile.

In termini pratici, il certificato foglia viene emesso in base alla CA di emissione DV R1, ma i client lo convalidano creando una catena su GoDaddy Radice Classe 2 - G2 utilizzando il certificato incrociato R1 → G2 pubblicato. Gli elementi rilevanti nel repository sono il trust anchor G2 (gdroot-g2), il certificato incrociato (gd_tls_root-r1-cross-g2), l'intermedio per l'emissione di DV R1 (gd_tls_issuing_dv-r1v1) e la radice della gerarchia nativa (gd_tls_root-r1 ) certs.godaddy.com. Questo approccio con il segno incrociato consente ai browser di convalidare la catena oggi stesso (ancorandosi a G2), mentre l'attendibilità R1 si propaga nel tempo.

Perché viene apportata questa modifica?

Esistono diversi motivi per abbandonare i certificati che supportano sia serverAuth che clientAuth (noti anche come certificati misti):

• Separare l'autenticazione del server da quella del client aiuta a semplificare il modello di affidabilità del certificato.
• Sicurezza igienica migliorata: i certificati con un numero eccessivo di scopi aumentano il rischio (ovvero, l'uso improprio di clientAuth in modi non previsti).
• L'utilizzo di gerarchie PKI dedicate per funzioni distinte aiuta a mantenere confini di fiducia più chiari, allineandosi alle più ampie best practice PKI (Public Key Infrastructure).

Quali sono i vantaggi di questa modifica?

• Rischio ridotto derivante da certificati multiuso: limitando i certificati pubblici solo a serverAuth, la superficie di attacco è ridotta e i limiti di attendibilità sono più chiari.
• Migliore conformità & governance: le organizzazioni avranno una separazione più netta tra autenticazione del server e autenticazione del client, che può supportare un migliore controllo e una migliore gestione del ciclo di vita dei certificati.
• Chiarezza operativa migliorata: quando la funzionalità clientAuth è separata in certificati o infrastrutture appropriati, è più facile gestire ruoli, revoche e rinnovi e garantire che il certificato giusto venga usato per lo scopo giusto.
• Prontezza futura: questa modifica è in linea con l'evoluzione dei modelli PKI / di affidabilità dei browser e aiuta le organizzazioni a orientarsi verso modelli di sicurezza e automazione più recenti.

Chi non è interessato?

La maggior parte dei siti Web che utilizzano certificati solo per l'autenticazione del server (ovvero, TLS/HTTPS tipico) non sono interessati. Se utilizzi il certificato solo per proteggere il tuo sito web per gli utenti, questa modifica non richiede alcun intervento.

Chi è interessato?

Questa modifica interessa le organizzazioni che utilizzano certificati server pubblicamente attendibili per l'autenticazione client (noti anche come TLS / mTLS reciproco) o l'autenticazione da server a server che si basa sull'EKU clientAuth. Ad esempio, alcuni servizi finanziari, servizi SaaS o API multi-tenant potrebbero essere interessati da questa modifica.

Quello che devi fare

• Se l'host è al di fuori di GoDaddy : assicurati che il pacchetto completo fornito dagli endpoint di download o dall'interfaccia del cliente sia stato installato quando aggiorni il tuo prossimo certificato.
• Se utilizzi certificati in qualsiasi caso d'uso che si basano su ClientAuth (mTLS) : Assicurati di migrare tali flussi di lavoro per utilizzare un certificato autofirmato o una soluzione di CA privata.

I team devono inoltre confermare che nessuna funzionalità interna o documentazione presume che i certificati foglia DV includano ClientAuth EKU, poiché i certificati foglia rilasciati da R1 non lo includeranno.

Ciò significa che tutti i certificati emessi dopo il 15 giugno 2026 non sono validi?

No. I certificati emessi prima del 15 giugno 2026 che includono clientAuth rimangono validi (fino alla scadenza) in base al modello di affidabilità esistente. La modifica interessa solo i nuovi certificati pubblici emessi a partire da tale data.

Devo fare qualcosa se utilizzo il mio certificato solo per il tipico protocollo HTTPS (autenticazione server) di un sito web?

Se il tuo hosting è esterno a GoDaddy, devi comunque assicurarti che il pacchetto sia utilizzato correttamente.

Che cos'è esattamente l '“autenticazione client” in questo contesto?

L'autenticazione client si riferisce all'uso di un certificato da parte di un client (utente, dispositivo o altro server) per autenticarsi sul server. Viene comunemente utilizzato nell'autenticazione API mTLS (Mutual TLS) o server-to-server in cui il server deve verificare il certificato presentato dal client di connessione.

Posso comunque usare i certificati clientAuth?

Sì, ma per l'attendibilità pubblica dovrai usare un certificato emesso specificamente per l'autenticazione del client (ovvero, clientAuth EKU dedicato) o usare una CA privata per i tuoi sistemi interni. I certificati server pubblici con clientAuth EKU non saranno più considerati attendibili in Chrome se emessi dopo il 15 giugno 2026.

Altri browser applicheranno questa modifica o solo Chrome?

La policy ha origine dal programma principale di Chrome, ma le modifiche nell'ecosistema PKI pubblico spesso influenzano altri browser e truststore. È saggio presumere un'applicabilità più ampia o almeno che la conformità futura sarà importante per tutte le piattaforme.

Questo vale per i certificati CA interni/privati?

No & mdash; la modifica interessa solo i certificati SSL/TLS attendibili pubblicamente (quelli considerati attendibili dagli archivi radice pubblici). L'infrastruttura della CA privata utilizzata per l'autenticazione del client interno non è direttamente interessata.

Quando dobbiamo essere pronti per questo cambiamento?

La tempistica prevista è il 27 maggio 2026. Entro tale data, i team responsabili dovrebbero aver completato la convalida della disponibilità (configurazione dell'emissione, correttezza del pacchetto/download, guida all'installazione della catena di distribuzione, monitoraggio e controlli delle dipendenze EKU) in modo che l'implementazione possa procedere senza interruzioni del servizio.

Altre informazioni

• Configura e installa il mio certificato SSL
• Se tu o i tuoi clienti riscontrate errori di "radice non attendibile" o di catena di certificati, consulta la nostra procedura per risolvere il problema .