L'essentiel
Qui contrôle le DNS de votre domaine peut obtenir pour lui un vrai certificat, reconnu par les navigateurs. Le 6 octobre 2026, l'équipe sécurité de Chrome chez Google a indiqué que des attaquants avaient détourné les registres nationaux du Ghana (.gh), de la Sierra Leone (.sl) et des Samoa américaines (.as), modifié des enregistrements DNS faisant autorité et obtenu des certificats HTTPS valides pour plusieurs domaines Google et pour d'autres organisations.
Google assure que ses systèmes n'ont pas été piratés et que les autorités de certification semblent avoir respecté les règles. Chrome bloque les certificats. La leçon pour tous les autres se trouve dans la partie de la pile que peu d'équipes regardent : registres, bureaux d'enregistrement et l'automatisation DNS et certificats derrière votre environnement cloud.
Comment les attaquants ont-ils obtenu de vrais certificats pour des domaines Google ?
Avant d'émettre un certificat HTTPS, une autorité de certification vérifie que le demandeur contrôle le domaine. Une méthode courante consiste à lui faire publier un enregistrement DNS contenant une valeur aléatoire. Quiconque peut modifier le DNS faisant autorité du domaine réussit ce contrôle. C'est tout le principe de la validation de domaine, et c'est aussi son point faible.
Ici, les attaquants ne s'en sont pas pris à Google. Ils sont montés d'un niveau, jusqu'aux systèmes qui gèrent trois domaines de premier niveau nationaux. Avec ce contrôle, ils ont réécrit le DNS faisant autorité de domaines en .gh, .sl et .as, dont les domaines locaux de Google pour ces pays, puis demandé des certificats que n'importe quel navigateur accepterait. The Register et BleepingComputer notent que Google n'a révélé ni les AC émettrices ni les autres entreprises touchées.
Qu'ont fait Google et Chrome ?
Google a ajouté les certificats frauduleux visant ses propres services aux CRLSets, le mécanisme dont Chrome se sert pour bloquer rapidement des certificats en urgence, et a obtenu leur révocation auprès des AC émettrices afin de protéger aussi les autres navigateurs et clients. Google a ensuite fouillé les journaux publics Certificate Transparency, trouvé des certificats d'autres organisations semblant liés à la même campagne, les a bloqués à leur tour dans Chrome et a prévenu les titulaires quand c'était possible. Selon Google, les utilisateurs de Chrome n'ont rien à faire.
La réserve importante vient de Google lui-même : les détournements DNS étant complexes, l'entreprise ne peut pas promettre d'avoir trouvé tous les domaines concernés. Les titulaires de domaines sous ces trois extensions, et toute marque dont un domaine national est géré par un petit registre, devraient vérifier eux-mêmes leur historique de certificats plutôt que d'attendre une notification.
Ce que cela change pour les équipes logicielles aux États-Unis et dans l'UE
D'abord, votre confiance TLS ne vaut pas plus que le registre le plus faible dont vous dépendez. Beaucoup d'entreprises déposent des domaines nationaux pour le marketing, la protection de marque ou des boutiques locales, puis les oublient. Ces domaines sont souvent gérés par de petits registres et revendeurs dont personne n'a jamais évalué la sécurité. Un détournement à ce niveau peut produire un certificat valide pour un domaine que vos clients reconnaissent.
Ensuite, les enregistrements CAA ne relèvent plus de l'hygiène facultative. Un enregistrement Certification Authority Authorization indique quelles AC peuvent émettre pour votre domaine. Google recommande explicitement des enregistrements CAA stricts qui limitent aussi l'émission à vos propres comptes ACME et méthodes de validation. Cela n'arrête pas quelqu'un qui contrôle entièrement votre DNS et peut réécrire l'enregistrement, mais cela réduit les voies d'attaque pour tous les autres et fait échouer par défaut une émission via une AC ou un compte inattendu.
Enfin, la surveillance Certificate Transparency transforme une attaque silencieuse en alerte. Chaque certificat publiquement reconnu est journalisé. C'est en surveillant ces journaux que Google a repéré les autres victimes, et c'est le moyen le plus rapide de voir un certificat inattendu avant qu'il ne serve contre vos utilisateurs. Pour les entités européennes soumises à NIS2 ou DORA, comme pour les entreprises américaines qui répondent à des exigences SOC 2 ou à des questionnaires de sécurité clients, « nous surveillons CT pour nos domaines » est un contrôle facile à démontrer.
Quelles conséquences pour les entreprises françaises ?
Les domaines en .fr sont gérés par l'Afnic, un registre de premier plan ; le risque pour les entreprises françaises se situe plutôt en périphérie du portefeuille. Les groupes présents en Afrique de l'Ouest et dans les pays francophones détiennent souvent des domaines nationaux pour leurs filiales, leurs marques locales ou leurs campagnes, déposés via des agences ou des partenaires sur place et rarement suivis par la DSI. Ce sont précisément ces petits registres, comparables à ceux du Ghana et de la Sierra Leone, qui ont été visés. Un certificat valide sur le domaine local d'une marque française connue suffit pour un hameçonnage crédible contre clients et distributeurs.
L'ANSSI publie depuis longtemps des bonnes pratiques sur l'acquisition et l'exploitation des noms de domaine, et cet incident leur donne une actualité concrète : cartographier tous les noms, savoir qui les gère, activer DNSSEC et les verrous proposés par les bureaux d'enregistrement. La directive NIS2 range explicitement les registres de domaines de premier niveau et les fournisseurs DNS parmi les acteurs concernés et impose une gestion des risques liés à la chaîne d'approvisionnement ; pour le secteur financier, DORA ajoute ses exigences sur les prestataires TIC. Concrètement : inscrivez le portefeuille de domaines dans votre cartographie des actifs et des prestataires, documentez CAA et DNSSEC comme mesures techniques et conservez la preuve d'une surveillance CT continue pour vos prochains audits.
Que vérifier dès cette semaine ?
- Inventorier tous vos domaines. Y compris les domaines nationaux, les domaines de campagne et tout ce que des agences ont déposé pour vous. Notez le registre et le bureau d'enregistrement de chacun.
- Interroger les journaux Certificate Transparency. Cherchez les certificats émis depuis mi-septembre 2026 que vous n'avez pas demandés, puis mettez en place des alertes CT continues sur l'ensemble du portefeuille.
- Publier des enregistrements CAA stricts. N'autorisez que les AC que vous utilisez réellement et, si votre AC le permet, liez l'émission à votre compte ACME et à la méthode de validation choisie.
- Activer les protections du bureau d'enregistrement et du registre. Utilisez le verrouillage registre (registry lock) quand il existe, activez DNSSEC, imposez la MFA sur les comptes du bureau d'enregistrement et revoyez les accès.
- Supprimer ou regrouper les domaines orphelins. Un domaine que personne ne surveille est un domaine dont personne ne remarquera le détournement. Redirigez-le depuis un bureau d'enregistrement bien géré ou abandonnez-le de façon délibérée.
Questions fréquentes
Que s'est-il passé avec les domaines en .gh, .sl et .as ?
Des attaquants ont compromis les systèmes servant à exploiter les registres nationaux du Ghana (.gh), de la Sierra Leone (.sl) et des Samoa américaines (.as), réécrit des enregistrements DNS faisant autorité pour des domaines sous ces extensions et utilisé ce contrôle pour obtenir des certificats HTTPS valides. Google a rendu les incidents publics le 6 octobre 2026.
Les systèmes de Google ont-ils été piratés ?
Non. Google indique que ses systèmes n'ont pas été compromis. Les attaquants contrôlaient au niveau du registre le DNS des domaines nationaux de Google, comme google.com.gh, ce qui suffisait à passer les contrôles de maîtrise du domaine effectués par les autorités de certification.
Les autorités de certification ont-elles commis une faute ?
Google dit n'avoir aucune raison de penser que les AC émettrices ont agi de manière incorrecte. La validation de domaine prouve qui contrôle le DNS d'un domaine à un instant donné, pas qui en est le titulaire légal ; un détournement au niveau du registre la contourne donc par construction.
Les utilisateurs de Chrome doivent-ils agir ?
Non. Google a bloqué les certificats identifiés dans Chrome via les CRLSets et obtenu leur révocation auprès des AC émettrices, ce qui protège aussi les utilisateurs d'autres navigateurs et clients. Les certificats d'autres organisations repérés dans les journaux Certificate Transparency ont également été bloqués.
Que doit faire notre entreprise ?
Publier des enregistrements CAA stricts qui ne citent que les AC utilisées et, lorsque c'est possible, lient l'émission à votre propre compte ACME et à vos méthodes de validation. Surveiller les journaux Certificate Transparency pour chacun de vos domaines, y compris les domaines nationaux. Vérifier les protections du bureau d'enregistrement et du registre, comme le verrouillage registre et DNSSEC.
Sources
Google — Chrome’s response to recent ccTLD registry hijacks
BleepingComputer — Hackers hijack Google domains after breaching ccTLD registries
The Register — Attackers hijacked top-level domains, minted fake security certs for Google and other orgs
SecurityWeek — Google domains impacted by recent ccTLD hijacks