Le piratage de trois registres nationaux a produit de faux certificats TLS au nom de Google

6 octobre 2026. Google révèle que des attaquants ont piraté trois registres de domaines nationaux — les ccTLD .gh (Ghana), .sl (Sierra Leone) et .as (Samoa américaines) — et s’en sont servis pour frapper de faux certificats TLS au nom de Google et de plusieurs grandes marques. Aucune compromission des systèmes de Google ni des autorités de certification. Semaine du 29 septembre. L’équipe sécurité de Chrome indique avoir pris connaissance des détournements « la semaine dernière », soit fin septembre. Pourquoi c’est important : la chaîne de confiance du HTTPS ne tient que par un maillon — la validation de contrôle du domaine — et ce maillon a cédé non pas chez un éditeur, mais chez des registres nationaux dont dépendent des milliers de sites.

Ce qui s’est exactement passé, et ce que ça ne veut pas dire

Un certificat TLS lie un nom de domaine à une clé publique grâce à une signature. Sa délivrance repose sur une seule vérification, la validation de contrôle du domaine (domain control validation, DCV) : l’autorité de certification demande au demandeur de prouver qu’il contrôle le domaine, le plus souvent en publiant un enregistrement DNS ou en répondant sur une URL. Si quelqu’un contrôle le DNS du domaine, il passe la DCV sans rien casser.

C’est précisément ce qui s’est produit. En prenant la main sur les registres .gh, .sl et .as, les attaquants ont pu modifier les enregistrements DNS et les délégations de serveurs de noms des domaines de leur choix. Contrôlant le DNS, ils ont fait aboutir des demandes de certificats parfaitement valides du point de vue des procédures. Google le dit sans détour : « nous n’avons aucune raison de penser que les autorités de certification qui ont émis les certificats concernés ont fait quoi que ce soit de mal ».

Le résultat n’est pas une faille de chiffrement. C’est une faille de confiance : un faux certificat permet à un attaquant positionné sur le chemin d’usurper cryptographiquement un site — l’équivalent moderne du faux passeport. Google n’a pas précisé combien de certificats ont été émis, ni la liste complète des victimes, mais précise que « plusieurs domaines de Google » et « plusieurs grandes marques mondiales et services en ligne très utilisés » sont concernés.

La mécanique de la validation de domaine, pas à pas

Pour émettre un certificat, une autorité vérifie le contrôle du domaine par l’une de trois méthodes : répondre sur une URL dédiée (HTTP-01), publier un enregistrement TXT dans la zone (DNS-01), ou recevoir un courriel d’approbation sur une adresse du domaine. Les deux dernières reposent sur le DNS. Un attaquant qui contrôle les enregistrements d’un domaine peut donc satisfaire la validation sans posséder aucun serveur du domaine : il demande le certificat, publie le TXT attendu, reçoit le certificat, puis efface la trace. C’est ce qui rend la compromission d’un registre si grave : elle donne le contrôle du DNS de milliers de domaines à la fois, sans toucher à aucun d’eux individuellement. Les journaux de Certificate Transparency, eux, enregistrent chaque certificat émis de façon publique et quasi immuable — c’est pourquoi ils sont à la fois l’outil de détection et la preuve qui permet, après coup, de mesurer l’étendue d’un détournement.

Pourquoi le navigateur ne suffit pas

Chrome a réagi vite : blocage immédiat des certificats non autorisés via les CRLSets, révocation coordonnée avec les autorités de certification, puis identification proactive d’autres victimes grâce aux journaux de Certificate Transparency (CT). Pour l’utilisateur de Chrome, rien à faire : le blocage est automatique.

Mais Google prévient que cette protection a une limite. « L’intervention côté navigateur ne doit pas être considérée comme une protection fiable pour vos utilisateurs », écrit l’équipe. Deux raisons. D’abord, l’analyse de Chrome ne peut pas garantir d’avoir identifié tous les domaines touchés : un certificat non détecté reste dangereux. Ensuite, les interventions de Chrome ne protègent pas les utilisateurs des autres navigateurs ni des clients qui ne sont pas des navigateurs — clients d’API, agents, applications mobiles, outils en ligne de commande qui vérifient le certificat contre leur propre magasin de confiance.

La comparaison historique est instructive. En 2011, la compromission de l’autorité néerlandaise DigiNotar avait permis de frapper de faux certificats pour google.com et plus de 200 autres domaines très fréquentés, utilisés contre au moins 300 000 personnes liées à l’Iran. La leçon de 2011 comme celle de 2026 est la même : la DCV est le maillon le plus faible de la chaîne, et elle l’est d’autant plus qu’elle repose sur le DNS, lui-même tributaire de registres et de bureaux d’enregistrement rarement traités comme des surfaces d’attaque.

Les deux contre-mesures qui restent entre les mains du propriétaire de domaine

Google formule deux recommandations concrètes, et elles ne dépendent pas du navigateur.

La première est la surveillance des journaux CT. Tout certificat de confiance accepté par Chrome doit être publié dans un journal public de Certificate Transparency. Surveiller ces journaux sur l’ensemble de son portefeuille — y compris les domaines en sommeil ou les ccTLD régionaux qu’on a enregistrés puis oubliés — donne une alerte quasi temps réel à chaque émission. Si vous exploitez un domaine en .gh, .sl ou .as, Google conseille de passer en revue les entrées récentes des journaux CT à la recherche d’une émission inattendue.

La seconde est la publication d’enregistrements CAA restrictifs (Certification Authority Authorization, RFC 8659), idéalement avec des liaisons de compte ACME pour restreindre l’émission à des comptes précis. La nuance est importante : un CAA n’empêche pas l’émission pendant un détournement DNS actif — l’attaquant contrôle le DNS, il peut aussi réécrire le CAA. En revanche, il protège après le rétablissement du DNS : les autorités de certification étant autorisées à mettre en cache les validations DCV effectuées et à les réutiliser, un CAA restrictif rétabli empêche un attaquant de rejouer une validation mise en cache pour frapper de nouveaux certificats une fois le détournement terminé.

Ce que la suite prépare

L’incident s’inscrit dans un mouvement de fond qui durcit l’écosystème HTTPS. Google cite explicitement la réduction de la durée de validité des certificats et du délai de réutilisation des DCV — le ballot SC081v3 du CA/Browser Forum — ainsi que le nouveau programme racine quantum-safe de Chrome. La logique est simple : plus un certificat vit longtemps et plus une validation est réutilisée longtemps, plus la fenêtre d’exploitation d’un détournement DNS transitoire est large.

À l’échelle du réseau, l’épisode confirme aussi que la sécurité du Web PKI se joue autant chez les registres que chez les autorités de certification. Un registre de ccTLD n’est pas un prestataire anodin : c’est la racine de confiance de tout un espace de noms, et sa compromission se propage à tous les domaines qui y résident, sans qu’aucun d’eux n’ait commis la moindre faute.

Verdict

Si vous êtes propriétaire de domaines — surtout d’un portefeuille large, avec des ccTLD régionaux ou des domaines en sommeil — mettez en place dès cette semaine une surveillance des journaux CT qui couvre la totalité du portefeuille, et publiez des enregistrements CAA restrictifs avec liaisons de compte ACME. C’est la seule défense qui reste sous votre contrôle quand le DNS est détourné. Si vous exploitez un domaine en .gh, .sl ou .as, la vérification n’est pas optionnelle : passez en revue les émissions récentes des journaux CT immédiatement. Si vous dépendez d’un client qui n’est pas un navigateur — API, agent, application mobile — ne comptez pas sur le blocage de Chrome : vérifiez les magasins de confiance de vos clients et traitez tout certificat inattendu sur vos domaines comme un incident. La leçon tient en une phrase : le cadenas vert de la barre d’adresse est une promesse, pas une preuve — et sa solidité dépend de registres que vous ne contrôlez pas.

Références

• Google — Chrome’s Response to Recent ccTLD Registry Hijacks (6 octobre 2026)
• Ars Technica — Hackers obtain counterfeit TLS certificates for Google and other large services (octobre 2026)
• RFC 8659 — DNS Certification Authority Authorization (CAA) Resource Record
• RFC 8657 — CAA Record Extensions for Account URI and ACME Method Binding