Faux certificats TLS pour Google : pourquoi le cadenas n’est pas une garantie
Le 6 octobre 2026, l’équipe de sécurité de Chrome chez Google a révélé que des attaquants avaient pris le contrôle des registres de trois domaines nationaux, .gh (Ghana), .sl (Sierra Leone) et .as (Samoa américaines). De là, ils ont modifié des enregistrements DNS et obtenu de faux certificats TLS pour plusieurs domaines de Google, ainsi que pour des domaines d’autres organisations, dont « plusieurs grandes marques mondiales ».
Le plus troublant : ces certificats étaient techniquement valides. Un navigateur qui les recevait pouvait afficher le petit cadenas comme si tout allait bien. Google précise que ses propres systèmes n’ont pas été piratés et qu’il n’a aucune raison de croire que les autorités de certification qui ont émis ces certificats ont commis une faute. C’est la chaîne de confiance autour d’elles qui a été trompée.
En bref
- Le cadenas ne prouve pas l’identité du site. Il prouve que la connexion est chiffrée avec un certificat qu’une autorité reconnue a émis pour ce nom de domaine. Si quelqu’un contrôle le DNS du domaine, il peut obtenir ce certificat.
- Les domaines en .ca ou en .com ne font pas partie des extensions piratées. Mais le même résultat (un faux certificat « valide » pour votre domaine) peut arriver par une voie bien plus banale : un compte de registraire mal protégé.
- Google ne garantit pas avoir tout trouvé, et ses blocages dans Chrome ne protègent pas de façon fiable les utilisateurs d’autres navigateurs.
La chaîne de confiance, et où elle a cédé
Quand vous ouvrez un site en HTTPS, plusieurs maillons doivent tenir pour que le cadenas veuille dire quelque chose. Voici ces maillons, dans l’ordre, avec ce qui s’est passé dans l’incident décrit par Google.
MAILLON 1 · LE REGISTRE DU DOMAINE NATIONAL
L’organisme qui gère toute une extension (.gh, .sl, .as, ou .ca chez nous) et indique quels serveurs DNS répondent pour chaque domaine.
⚠ Point d’entrée de l’attaque
Les attaquants ont compromis ces trois registres, ce qui mettait à risque n’importe quel domaine se terminant par .gh, .sl ou .as.
↓
MAILLON 2 · LES SERVEURS DNS QUI FONT AUTORITÉ
Ils répondent à la question « où se trouve ce site ? ». Tout le monde, y compris les autorités de certification, se fie à leur réponse.
⚠ Réponses falsifiées
Les attaquants ont modifié les enregistrements DNS de domaines choisis pour que les requêtes aboutissent chez eux.
↓
MAILLON 3 · L’AUTORITÉ DE CERTIFICATION
Avant d’émettre un certificat, elle vérifie que le demandeur contrôle le domaine, souvent au moyen d’un test DNS ou web.
Trompée, sans faute
Comme le DNS répondait pour les attaquants, le test a réussi. Google n’a « aucune raison de croire » que les autorités ont mal agi.
↓
MAILLON 4 · LES JOURNAUX DE TRANSPARENCE (CT)
Les certificats auxquels Chrome se fie par défaut doivent être inscrits dans des journaux publics, consultables par n’importe qui.
✓ Là où on peut le voir
Ce sont ces journaux qui ont permis à Google de repérer d’autres organisations touchées. C’est aussi là que vous pouvez surveiller votre propre domaine.
↓
MAILLON 5 · LE NAVIGATEUR ET SON CADENAS
Le navigateur vérifie que le certificat est valide pour le nom demandé et qu’il vient d’une autorité reconnue. Si oui, il affiche le cadenas.
Cadenas trompeur
Avec un certificat valide en main, un imposteur peut se faire passer pour le vrai site. Chrome bloque maintenant les certificats que Google a identifiés.
La leçon pour une PME : le maillon le plus faible n’est pas le chiffrement, c’est le contrôle de votre nom de domaine. Quiconque peut changer les réponses DNS de votre domaine peut, en principe, obtenir de faux certificats TLS à votre nom.
Comment Google a réagi, étape par étape
- Semaine du 28 septembre : Google apprend l’existence d’une série de détournements de domaines dans les trois extensions.
- Blocage immédiat dans Chrome : les certificats non autorisés visant les propriétés de Google sont bloqués au moyen des CRLSets, un mécanisme de Chrome qui permet de bloquer des certificats précis rapidement.
- Révocation par les autorités : Google travaille avec les autorités de certification émettrices pour faire révoquer ces certificats, afin de protéger aussi les utilisateurs d’autres logiciels que Chrome.
- Fouille des journaux CT : les journaux de transparence révèlent d’autres organisations probablement touchées. Google bloque aussi ces certificats dans Chrome et prévient les organisations quand c’est possible.
- 6 octobre : publication de l’avis. Les utilisateurs de Chrome n’ont rien à faire. Les propriétaires de domaines, eux, ont du travail.
Google n’a nommé ni les domaines touchés, ni les autres organisations, ni le nombre de certificats. Il n’a pas non plus indiqué si ces certificats ont servi à intercepter du trafic réel. Et il le dit sans détour : « nous ne pouvons pas garantir que notre analyse a identifié chaque domaine touché, et les interventions de Chrome ne protègent pas de façon fiable les utilisateurs d’autres navigateurs ».
Ce que Google recommande aux propriétaires de domaines
Google ne donne que deux consignes. Elles valent pour toute PME qui a un site web ou une messagerie à son nom.
1. Surveiller la transparence des certificats (CT) pour tous vos domaines
Chaque certificat de confiance doit être publié dans les journaux CT. En les surveillant, vous êtes averti presque en temps réel quand un certificat est émis pour un de vos domaines. Google insiste : couvrez tout votre portefeuille, y compris les domaines « parqués » et les extensions régionales. Pour un premier coup d’œil gratuit, tapez votre domaine dans crt.sh.
2. Publier des enregistrements CAA restrictifs, liés à votre compte
Un enregistrement DNS de type CAA indique quelles autorités ont le droit d’émettre des certificats pour votre domaine. Google reconnaît que le CAA n’empêche pas l’émission pendant un détournement DNS actif. Mais une fois le contrôle du DNS repris, une règle CAA qui limite l’émission à votre compte et à certaines méthodes de validation empêche l’attaquant de réutiliser une validation déjà réussie pour obtenir de nouveaux certificats.
Exemple d’enregistrement CAA pour un domaine dont les certificats viennent de Let’s Encrypt (à adapter : le numéro de compte est fictif) :
votreentreprise.ca. CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/123456789; validationmethods=dns-01" votreentreprise.ca. CAA 0 iodef "mailto:securite@votreentreprise.ca"
Attention avant d’activer le CAA : votre hébergeur web, Microsoft 365, votre réseau de diffusion (CDN) ou un outil de marketing peuvent émettre des certificats en votre nom. Faites d’abord l’inventaire, sinon le prochain renouvellement automatique échouera et votre site affichera une erreur.
Nos recommandations NeoTech, en plus de celles de Google
Le piratage d’un registre national est hors de votre contrôle. En revanche, le même scénario (quelqu’un modifie votre DNS et obtient un certificat à votre nom) arrive bien plus souvent par le compte chez votre registraire ou chez votre fournisseur DNS. Les mesures suivantes ne viennent pas de Google : ce sont nos recommandations pour les PME.
- MFA sur le compte du registraire et du fournisseur DNS. Idéalement une clé de sécurité physique ou une application d’authentification, pas un code par texto. Ce compte vaut autant que votre site et vos courriels.
- Verrou de registraire et, si offert, verrou de registre (« registry lock »). Le premier bloque les transferts et changements non autorisés ; le second exige une vérification manuelle avant tout changement de serveurs DNS. Il ne protège pas contre un registre lui-même piraté, mais il ferme la porte la plus courante.
- DNSSEC quand votre registraire et votre fournisseur DNS le permettent. Il signe vos réponses DNS et complique la falsification en chemin. Soyons honnêtes : il ne protège pas contre une compromission du registre lui-même, mais il fait partie d’une bonne hygiène.
- Un inventaire de vos domaines, avec qui y a accès, la date d’expiration et le renouvellement automatique activé. Les vieux domaines oubliés sont des cibles faciles.
- Une adresse courriel de récupération qui ne dépend pas du domaine lui-même. Si votre domaine est détourné, vous devez encore pouvoir joindre votre registraire.
Votre fournisseur web a vécu un incident récemment ? Notre article sur les questions à poser à votre hébergeur web après l’incident Pantheon complète bien cette liste. Un domaine sans suivi fait aussi partie des 5 signes que votre PME est une cible facile.
Et vos employés, devant le cadenas ?
Ce message vaut la peine d’être répété à l’équipe : le cadenas veut dire « connexion chiffrée », pas « site honnête ». La plupart des sites d’hameçonnage ont aussi un cadenas. Gardez les navigateurs à jour (c’est ainsi que les blocages comme ceux de Chrome vous arrivent), méfiez-vous des avertissements de certificat au lieu de les contourner, et ouvrez les sites sensibles (banque, Microsoft 365) depuis un favori plutôt qu’à partir d’un lien reçu.
Comment NeoTech peut vous aider
Pour les PME de Laval, de Montréal et de la Rive-Nord, on peut faire l’inventaire de vos domaines, sécuriser l’accès à votre registraire avec la MFA, vérifier vos enregistrements CAA et mettre en place une surveillance des journaux CT. Notre surveillance automatisée 24/7 avec intervention du technicien de garde vous aide à réagir vite quand quelque chose change. Voir aussi nos services de cybersécurité.
Réservez votre Bilan cyber gratuit
Vous ne savez pas qui contrôle le DNS de votre domaine, ni si un certificat a été émis à votre nom sans que vous le sachiez ? En une courte rencontre, on fait le tour et on priorise les correctifs.
👉 Réservez votre Bilan cyber gratuit
Appelez-nous au 438-476-2322 ou écrivez à info@neotechcloudsolutions.com.
Sources
- Google, Chrome Secure Web and Networking Team — Chrome’s Response to Recent ccTLD Registry Hijacks (6 octobre 2026, en anglais)
- Ars Technica — Hackers obtain counterfeit TLS certificates for Google and other large services (6 octobre 2026, en anglais)
- Let’s Encrypt — Autorisation d’autorité de certification (CAA)
- Certificate Transparency — fonctionnement des journaux CT (en anglais)
- IETF — RFC 8659, DNS Certification Authority Authorization (CAA) Resource Record (en anglais)
Photo : JJ Ying (Unsplash), via Wikimedia Commons, CC0.