L'équipe sécurité de Chrome chez Google a révélé le 6 octobre 2026 avoir eu connaissance, la semaine précédente, d'une série de détournements de domaines dans les domaines de premier niveau nationaux .gh (Ghana), .sl (Sierra Leone) et .as (Samoa américaines). Google souligne que ses propres systèmes n'ont pas été compromis : ce sont les ccTLD gérés par des tiers qui l'ont été, ce qui a exposé tout domaine se terminant par ces suffixes. Pendant les détournements, les attaquants ont modifié les enregistrements DNS faisant autorité et obtenu des certificats HTTPS non autorisés couvrant plusieurs domaines Google ainsi que des domaines appartenant à d'autres organisations. Google estime que, vu la nature des attaques, rien ne permet de penser que les autorités de certification qui ont émis ces certificats aient commis une faute : avec le DNS sous le contrôle des attaquants, la validation de domaine réussit.

Ce que Google a fait

  • Il a immédiatement bloqué dans Chrome, via CRLSets, les certificats non autorisés visant ses propriétés, et a travaillé avec les autorités émettrices pour les faire révoquer, afin de protéger aussi les clients autres que Chrome.
  • Les données des journaux Certificate Transparency (CT) ont ensuite révélé d'autres organisations, dont plusieurs grandes marques mondiales et des services en ligne très utilisés, probablement touchées par les mêmes attaques ; Google a aussi bloqué ces certificats dans Chrome et a prévenu les organisations concernées lorsque c'était possible.
  • Les utilisateurs de Chrome n'ont rien à faire. Mais Google est clair : il ne faut pas compter sur une intervention côté navigateur. Il ne peut pas garantir avoir trouvé tous les domaines touchés, et ses interventions dans Chrome ne protègent pas de manière fiable les utilisateurs d'autres navigateurs.

Google n'a publié ni le nombre de certificats ni le nom des autorités émettrices. En interrogeant les journaux CT publics le 12 octobre, nous avons trouvé des certificats émis par Let's Encrypt entre le 22 et le 27 septembre pour des domaines comme youtube.com.gh, google.sl, youtube.sl et youtube.as, révoqués entre le 26 septembre et le 1er octobre ; les autres certificats que nous avons vus pour ces domaines sur la même période avaient été émis par Google Trust Services, l'autorité de Google elle-même. C'est la nature même de la validation de domaine automatisée : qui contrôle le DNS peut obtenir un certificat dans les règles.

Deux choses que les propriétaires de sites peuvent faire

  • Surveiller en continu la Certificate Transparency. Tout certificat reconnu par défaut doit être inscrit dans des journaux CT publics : leur surveillance vous alerte presque en temps réel dès qu'un certificat est émis pour vos domaines. Google demande expressément de couvrir l'ensemble de votre portefeuille de domaines, y compris les domaines parqués et les domaines nationaux régionaux.
  • Publier des enregistrements CAA restrictifs liés au compte ACME. CAA est un enregistrement DNS qui déclare quelles autorités peuvent émettre des certificats pour votre domaine. Google le formule précisément : CAA ne peut pas empêcher l'émission pendant un détournement en cours, mais constitue une protection essentielle une fois le contrôle du DNS retrouvé — les autorités peuvent mettre en cache et réutiliser des validations de domaine déjà effectuées, et une politique CAA qui limite l'émission à des comptes et des méthodes de validation précis empêche un attaquant d'utiliser cette validation en cache pour obtenir de nouveaux certificats après la fin du détournement.

La mise en place sur votre propre domaine

La documentation CAA de Let's Encrypt (mise à jour le 4 octobre) décrit deux paramètres. accounturi limite les demandes à un seul compte ACME : selon la documentation, il garantit que quelqu'un qui détourne temporairement votre domaine, mais n'a pas accès à la clé de votre compte ACME, ne puisse pas émettre de certificats malveillants. validationmethods limite les méthodes de validation (http-01, dns-01, tls-alpn-01). Un enregistrement qui n'autorise que Let's Encrypt, et uniquement votre compte, ressemble à peu près à ceci :

example.com. CAA 0 issue "letsencrypt.org;accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/YOUR_ACCOUNT_ID"

L'URL de votre compte figure dans les informations de compte de votre client ACME (avec certbot, certbot show_account). Notez que les enregistrements CAA sont cumulatifs — si un seul d'entre eux autorise une autorité, elle peut émettre —, supprimez donc les anciens enregistrements plus permissifs. En vertu du scrutin SC098v2 du CA/Browser Forum, toutes les autorités de certification devront traiter ces deux paramètres à partir du 15 mars 2027. Pour ajouter des enregistrements DNS, voir faire pointer un domaine vers votre VPS : les bases du DNS, ou accélérer et protéger votre site VPS avec Cloudflare si Cloudflare héberge votre DNS ; pour l'évolution de la durée des certificats, voir notre article sur les certificats de 64 jours de Let's Encrypt.