Pourquoi GoDaddy supprime-t-il ClientAuth EKU et passe-t-il à la hiérarchie racine R1 pour l'émission de DV TLS?

À compter du 15 juin 2026, les certificats SSL / TLS de confiance publique émis pour une utilisation sur serveur ne seront plus autorisés à inclure l'utilisation de la clé étendue «Authentification du client» (EKU: clientAuth). Voici les points clés à comprendre:

• La modification fait partie de la mise à jour de la politique du programme racine de Chrome: les nouveaux certificats doivent inclure uniquement l’EKU «Authentification du serveur».
• Les nouveaux certificats publics émis après cette date et incluant clientAuth ne seront pas approuvés par Chrome.
• Les certificats émis avec clientAuth avant le 15 juin 2026 ne sont pas concernés par cette modification et resteront valides jusqu'à leur expiration ou leur révocation.
• Les certificats CA privés (à usage interne) ne sont pas concernés par cette modification & mdash; elle s'applique uniquement aux certificats de confiance publique.

En bref: si votre organisation utilise des certificats TLS publics pour l'authentification client (via clientAuth EKU), vous devrez agir avant le 15 juin 2026 . Pour l'utilisation TLS standard du site Web (authentification du serveur uniquement), cette modification ne nécessite aucune action. Cependant, il s'agit d'un rappel opportun pour examiner votre certificat d'utilisation, séparer les fonctions de manière appropriée et vous assurer que vous êtes aligné sur le modèle de confiance en évolution.

Comment GoDaddy mettra en œuvre ce changement

Aucune EKU n'est répertoriée dans nos intermédiaires de signature / émission G2 actuels, ce qui rend cette hiérarchie non conforme aux exigences du programme Chrome Root. Par conséquent, les émissions des intermédiaires G2 concernés doivent cesser avant cette date.

Plutôt que de créer de nouveaux intermédiaires d'émission sur la chaîne G2 & mdash; qui devrait expirer / se terminer avec Google en avril 2027 & mdash; nous transférons l'émission DV vers notre nouvelle hiérarchie R1 pour répondre aux contraintes de la politique à l'avenir.

Nous modifions la chaîne d'émission DV publique afin que les nouveaux certificats feuilles DV soient émis à partir de la hiérarchie de l'autorité de certification racine TLS GoDaddy - R1, à l'aide de l'autorité de certification TLS intermédiaire GoDaddy DV - R1v1 émettant des certificats CA.godaddy.com. Cela signifie que la chaîne d'émetteur présentée par les serveurs (feuille + intermédiaire) peut différer de ce que certains systèmes ont vu dans le passé, et que tout outil interne qui suppose un nom intermédiaire hérité spécifique ou un ordre de chaîne doit être mis à jour pour accepter la nouvelle chaîne R1.

En outre, les certificats feuilles émis à partir de cette hiérarchie ne contiendront pas ClientAuth EKU. Tout flux de travail qui reposait sur des certificats feuilles DV utilisables pour l’authentification du client TLS doit migrer vers un profil de certificat / un chemin PKI approprié. Pendant le déploiement, les certificats restent opérationnels dans les navigateurs, car les clients sont validés à l'aide du chemin de confiance croisé requis R1 → G2 publié dans notre référentiel (certs.godaddy.com).

Comment les certificats restent opérationnels dans le navigateur pendant la transition R1 (signe croisé R1 → G2)

Alors que nous migrons l'émission publique de DV TLS vers la hiérarchie R1, la racine R1 est toujours en train d'être largement approuvée / distribuée dans les magasins de confiance du navigateur et du système d'exploitation. Pour garantir que les certificats R1 récemment émis fonctionnent immédiatement dans les navigateurs, nous nous appuyons sur un chemin de confiance croisé vers la racine G2 déjà approuvée.

En termes pratiques, le certificat feuille est émis sous l'autorité de certification d'émission DV R1, mais les clients le valident en créant une chaîne GoDaddy Class 2 Root - G2 à l'aide du certificat croisé publié R1 → G2. Les artefacts pertinents dans le référentiel sont l'ancre de confiance G2 (gdroot-g2), le certificat croisé (gd_tls_root-r1-cross-g2), l'intermédiaire d'émission DV R1 (gd_tls_issuing_dv-r1v1) et la racine de la hiérarchie native (gd_tls_root-r1) ) certs.godaddy.com. Cette approche croisée permet aux navigateurs de valider la chaîne aujourd'hui (ancrage à G2), tandis que la confiance R1 se propage au fil du temps.

Pourquoi ce changement est-il effectué?

Plusieurs raisons justifient l'abandon des certificats qui prennent en charge à la fois serverAuth et clientAuth (également appelés certificats à usage mixte):

• La séparation de l’authentification du serveur et de l’authentification du client permet de simplifier le modèle de confiance de certificat.
• Amélioration de l'hygiène de sécurité: les certificats avec trop d'objectifs augmentent le risque (c'est-à-dire une mauvaise utilisation de clientAuth de manière inattendue).
• L’utilisation de hiérarchies PKI dédiées pour des fonctions distinctes permet de maintenir des limites de confiance plus claires, en s’alignant sur les meilleures pratiques PKI (Public Key Infrastructure).

Quels sont les avantages de ce changement?

• Réduction des risques liés aux certificats multifonctionnels: en limitant les certificats publics à serverAuth, la surface d'attaque est réduite et les limites de confiance sont plus claires.
• Meilleure conformité & gouvernance: les entreprises auront une séparation plus claire entre l’authentification du serveur et l’authentification des clients, ce qui permettra de mieux gérer l’audit et le cycle de vie des certificats.
• Amélioration de la clarté opérationnelle: Lorsque la fonctionnalité clientAuth est séparée en certificats ou infrastructures appropriés, il est plus facile de gérer les rôles, les révocations, les renouvellements et de garantir que le bon certificat est utilisé pour le bon usage.
• Préparation future: ce changement s’aligne sur l’évolution des modèles de confiance PKI / navigateur et aide à positionner les entreprises pour les nouveaux modèles de sécurité et l’automatisation.

Qui n'est pas concerné?

La plupart des sites Web qui utilisent des certificats uniquement pour l'authentification du serveur (c'est-à-dire TLS / HTTPS) ne sont pas concernés. Si vous n'utilisez le certificat que pour sécuriser votre site Web pour les utilisateurs, cette modification ne nécessite aucune action.

Qui est concerné?

Cette modification concerne les organisations qui utilisent des certificats de serveur de confiance publics pour l’authentification client (également appelée TLS / mTLS mutuel) ou l’authentification de serveur à serveur qui repose sur l’EKU clientAuth. Par exemple, certains services financiers, services SaaS ou API multi-locataires peuvent être affectés par ce changement.

Ce que vous devez faire

• Si vous êtes hébergé en dehors de GoDaddy : Assurez-vous que le bundle complet fourni par les points de terminaison de téléchargement ou l'interface client est en cours d'installation lors de la mise à jour de votre prochain certificat.
• Si vous utilisez des certificats qui reposent sur ClientAuth (mTLS) : veillez à migrer ces flux de travail pour utiliser un certificat auto-signé ou une solution CA privée.

Les équipes doivent également confirmer qu’aucune fonctionnalité ou documentation interne ne suppose que les certificats feuilles DV incluent ClientAuth EKU, étant donné que les certificats feuilles émis par R1 ne l’incluront pas .

Cela signifie-t-il que tous les certificats émis après le 15 juin 2026 ne sont pas valides?

Non. Les certificats émis avant le 15 juin 2026 et qui incluent clientAuth restent valides (jusqu'à leur expiration) dans le cadre du modèle de confiance existant. La modification concerne uniquement les nouveaux certificats publics émis à cette date ou après cette date.

Si j'utilise mon certificat uniquement pour le protocole HTTPS (authentification du serveur), dois-je faire quelque chose?

Si votre hébergement est en dehors de GoDaddy, vous devez quand même vous assurer que le bundle est correctement utilisé.

Dans ce contexte, qu’est-ce que «l’authentification du client»?

L'authentification du client fait référence à l'utilisation d'un certificat par un client (utilisateur, appareil ou autre serveur) pour s'authentifier auprès du serveur. Il est couramment utilisé dans l'authentification mTLS (Mutual TLS) ou l'API de serveur à serveur où le serveur doit vérifier le certificat présenté par le client qui se connecte.

Puis-je quand même utiliser les certificats clientAuth?

Oui & mdash; mais pour la confiance publique, vous devrez utiliser un certificat émis spécifiquement pour l'authentification client (c'est-à-dire clientAuth EKU dédié) ou utiliser une autorité de certification privée pour vos systèmes internes. Les certificats de serveur public avec clientAuth EKU ne seront plus approuvés dans Chrome s'ils sont émis après le 15 juin 2026.

D'autres navigateurs appliqueront-ils ce changement ou simplement Chrome?

La politique est issue du programme Chrome Root, mais les modifications apportées à l’écosystème PKI publique influencent souvent d’autres navigateurs et magasins de confiance. Il est judicieux de supposer une applicabilité plus large ou du moins que la conformité future sera importante sur toutes les plates-formes.

Cela s'applique-t-il aux certificats CA internes / privés?

Non & mdash; la modification affecte uniquement les certificats SSL / TLS de confiance publique (ceux approuvés par les magasins racine publics). L'infrastructure de l'autorité de certification privée utilisée pour l'authentification des clients internes n'est pas directement affectée.

Quand devons-nous être prêts pour ce changement?

Le calendrier cible est le 27 mai 2026. À cette date, les équipes responsables doivent avoir terminé la validation de la disponibilité (configuration de l’émission, exactitude des bundles / téléchargements, instructions d’installation de la chaîne de déploiement, surveillance et vérifications des dépendances EKU) pour que le déploiement puisse se poursuivre sans interruption du service.

En savoir plus

• Configurer et installer mon certificat SSL
• Si vous ou vos clients constatez des erreurs de «racine non approuvée» ou de chaîne de certificats, consultez nos étapes pour résoudre le problème .