Defaults.Exposed › Corrections › Enregistrements CAA

Comment corriger Enregistrements CAA

Un enregistrement CAA est une courte instruction dans les réglages de votre domaine qui désigne quelles autorités de certification ont le droit d'émettre le certificat de sécurité du « cadenas » pour votre site. Une fois activé, aucune autre autorité ne peut créer discrètement un certificat valide en votre nom.

En clair, pour votre entreprise : Sans enregistrement CAA, presque n'importe laquelle des centaines d'autorités de certification dans le monde peut émettre un véritable certificat de cadenas, pleinement reconnu, pour votre domaine — permettant à un escroc de dresser un clone impeccable et d'apparence parfaitement « sécurisée » de votre site pour récolter les identifiants et numéros de carte de vos clients, sans rien à l'écran qui les alerte.

Ce que cela peut vous coûter

Un escroc obtient un vrai certificat pour une copie de votre site, qui affiche donc le cadenas vert et le HTTPS — vos clients ne voient rien d'anormal, saisissent leurs mots de passe et numéros de carte, et vous ne l'apprenez qu'au début des rejets de paiement et des appels furieux.
Vos clients se font hameçonner via un sosie au pixel près de votre page de connexion ; les retombées — remboursements, charge de support, atteinte à la réputation — retombent sur votre marque alors même que votre vrai site n'a jamais été touché.
L'équipe de sécurité ou des achats d'un prospect lance une vérification rapide sur votre domaine avant de signer, ne voit aucune protection CAA, et vous note discrètement comme « faible sur les bases » — mettant une affaire en péril pour un réglage qui prend cinq minutes à ajouter.
L'une des autorités de certification mondiales est compromise (cela s'est produit à plusieurs reprises — DigiNotar, Comodo, Symantec), et parce que vous n'avez jamais dit qui a le droit d'agir pour vous, votre domaine est exposé à celle qui se révèle être le maillon le plus faible.

Pourquoi c'est important. Pour l'instant, la porte est grande ouverte : n'importe quelle autorité de certification sur Terre peut se porter garante d'un site se prétendant le vôtre, que vous ayez ou non déjà eu affaire à elle. Un enregistrement CAA verrouille cette porte pour que seule l'autorité que vous avez choisie puisse émettre des certificats — c'est la défense la plus simple et la moins chère qui soit contre quelqu'un qui usurpe l'identité de votre entreprise en ligne.

Les enregistrements CAA, en clair

Tout site web sécurisé a un certificat — la chose derrière le cadenas dans le navigateur et le « https » au début de votre adresse. Ces certificats sont délivrés par des firmes spécialisées appelées autorités de certification (CA) : des noms comme Let’s Encrypt, DigiCert, Sectigo, Google Trust Services. Quand votre navigateur voit un certificat valide, il affiche le cadenas et indique à votre client que la connexion est authentique et sécurisée.

Voici la partie que la plupart des dirigeants n’ont jamais entendue : par défaut, des centaines de ces autorités de certification dans le monde ont chacune le droit d’émettre un certificat pour votre domaine — que vous en ayez entendu parler ou non. Un enregistrement CAA (Certification Authority Authorization) est une note d’une ligne que vous ajoutez aux réglages DNS de votre domaine et qui dit, en substance : « seules ces autorités ont le droit d’émettre des certificats pour moi. » Toute autorité de certification légitime est tenue par les règles du secteur de vérifier cette note avant d’émettre — et de refuser si elle n’est pas sur votre liste.

C’est la différence entre une porte d’entrée déverrouillée par laquelle n’importe qui peut passer, et une porte dont seuls les gens que vous avez choisis détiennent une clé. Et son ajout ne coûte rien.

Ce que cela peut vous coûter

Le risque que ferme un enregistrement CAA, c’est l’usurpation convaincante. Quand un escroc peut obtenir un vrai certificat pour une copie de votre site, les signaux d’alerte habituels disparaissent — pas de cadenas brisé, pas de bannière « non sécurisé », pas d’erreur de certificat. Tout a l’air en ordre, ce qui est précisément ce qui le rend dangereux.

Le faux impeccable. Un escroc enregistre une adresse sosie (ou compromet une route vers vos clients), obtient un vrai certificat, et dresse un clone parfait de votre page de connexion ou de paiement — cadenas compris. Les clients saisissent mots de passe et numéros de carte comme d’habitude. La première chose que vous en apprenez est une vague de rejets de paiement, de signalements de fraude et d’appels furieux.
La campagne de hameçonnage en votre nom. Les attaquants envoient des e-mails « merci de confirmer votre compte » qui pointent vers leur clone certifié de votre site. Comme la page paraît parfaitement sécurisée, davantage de gens se laissent prendre. Le nettoyage — prévenir les clients, remboursements, heures de support, l’explication publique embarrassante — retombe entièrement sur vous, alors même que vos vrais serveurs n’ont jamais été touchés.
L’affaire qui cale sur une liste de contrôle. L’équipe de sécurité ou des achats d’un client plus important scanne votre domaine avant de signer. « Pas d’enregistrement CAA » apparaît comme un point rouge ou orange à côté de votre nom. C’est techniquement une petite chose, mais cela se lit comme « ne couvre pas les bases », et cela peut ralentir ou couler un contrat que vous auriez autrement remporté.
Pris au piège par la faille d’un autre. Une autorité de certification avec laquelle vous n’avez jamais traité est compromise — ce n’est pas hypothétique ; DigiNotar, Comodo et Symantec ont tous connu de graves incidents. Comme vous n’avez jamais restreint qui pouvait agir pour vous, l’attaquant peut obtenir un certificat valide pour votre domaine via cette CA faible. Un enregistrement CAA l’aurait refusé.
L’angle mort des génériques. Même les entreprises soigneuses pour leur site principal oublient souvent les sous-domaines. Sans règle issuewild, un attaquant qui peut obtenir un certificat générique obtient en fait une clé pour tous les sous-domaines que vous aurez jamais, d’un coup.

Aucun de ces cas ne requiert une attaque sophistiquée contre vos serveurs. Ils exploitent le fait que, sans enregistrement CAA, le système de certification au sens large est tout simplement trop confiant en votre nom.

Ce que c’est vraiment, et à quoi ressemble une situation « correcte »

Un enregistrement CAA réside dans le DNS de votre domaine — les mêmes réglages qui pointent votre domaine vers votre site et votre messagerie. Chaque enregistrement a trois parties : un drapeau (flag), une étiquette (tag) et une valeur. Les étiquettes qui comptent sont :

issue — désigne une autorité de certification autorisée à émettre des certificats normaux pour votre domaine. Vous pouvez en avoir plusieurs, une par autorité que vous utilisez légitimement.
issuewild — contrôle les certificats génériques (un certificat couvrant tous les sous-domaines, par ex. *.exemple.com). Si vous n’utilisez pas de génériques, le réglage recommandé les bloque entièrement.
iodef — une adresse de contact optionnelle où vous serez notifié si une autorité de certification rejette une demande à cause de votre politique CAA. C’est votre alerte précoce que quelqu’un a essayé.

À quoi ressemble une situation « correcte » : au moins un enregistrement issue (ou issuewild) est présent, désignant la ou les autorités que vous utilisez réellement, avec les génériques soit restreints à une autorité nommée, soit bloqués. C’est le seuil que ce contrôle mesure — il recherche les enregistrements CAA de votre domaine auprès de plusieurs résolveurs indépendants et passe lorsqu’il trouve une vraie politique issue ou issuewild en place. Un domaine sans aucun enregistrement CAA est traité comme la porte ouverte qu’il est.

Cela affecte-t-il ma note ? Oui. Un enregistrement CAA manquant est un élément noté et signalé en gravité moyenne — c’est une vraie lacune, pas un simple bonus, car il laisse ouverte une véritable voie d’usurpation. Ajouter l’enregistrement comble la lacune et efface le constat.

Comment corriger (gratuit, ~5 minutes)

Transmettez cette section à la personne qui gère votre domaine ou votre site — le correctif est gratuit. C’est une petite modification DNS, pas une reconstruction. Nous ne facturons que si vous voulez ensuite que nous continuions à surveiller que l’enregistrement reste en place ; l’ajouter ne coûte rien.

Étape 1 — Déterminer quelle autorité de certification vous utilisez réellement. C’est l’étape à ne pas rater, car lister la mauvaise autorité peut bloquer votre prochain renouvellement. Cas courants :

Let’s Encrypt — utilisé par de nombreux hébergeurs et panneaux de contrôle (cPanel, Plesk) → letsencrypt.org
Cloudflare (s’il émet votre certificat en périphérie) → letsencrypt.org, digicert.com, comodoca.com, pki.goog, et ssl.com (Cloudflare utilise plusieurs CA en arrière-plan ; listez celles que son tableau de bord affiche, ou son jeu complet, pour que les renouvellements ne cassent jamais)
Google Workspace / Google Trust Services → pki.goog
DigiCert → digicert.com
Sectigo / Comodo → sectigo.com (et comodoca.com)
Microsoft 365 / Azure — Microsoft utilise généralement DigiCert pour les certificats gérés → digicert.com (confirmez dans votre portail)

En cas de doute, regardez votre certificat actuel dans le navigateur (cliquez sur le cadenas → détails du certificat → « Émis par ») pour voir qui l’a émis.

Étape 2 — Connectez-vous à votre fournisseur DNS. C’est là où résident les enregistrements de votre domaine — généralement votre bureau d’enregistrement, votre hébergeur web, ou Cloudflare. Trouvez la section des enregistrements DNS et choisissez d’ajouter un nouvel enregistrement de type CAA (certaines interfaces l’étiquettent type 257).

Étape 3 — Ajoutez un enregistrement issue pour chaque autorité que vous utilisez. Pour Let’s Encrypt, par exemple :

exemple.com.   CAA   0 issue "letsencrypt.org"

Ajoutez une ligne issue par autorité légitime. La plupart des tableaux de bord DNS vous proposent des champs distincts pour le drapeau (0), l’étiquette (issue) et la valeur (le domaine de la CA) afin que vous n’ayez pas à taper toute la ligne à la main.

Étape 4 — Contrôlez les certificats génériques. Si vous n’utilisez pas de génériques, bloquez-les purement et simplement pour que personne ne puisse en obtenir un discrètement :

exemple.com.   CAA   0 issuewild ";"

Si vous utilisez des génériques, nommez plutôt l’autorité : 0 issuewild "letsencrypt.org".

Étape 5 — (Recommandé) Ajoutez une adresse de notification. Pour être averti chaque fois qu’une CA rejette une tentative — votre alerte précoce que quelqu’un a essayé :

exemple.com.   CAA   0 iodef "mailto:[email protected]"

Étape 6 — Enregistrez et vérifiez. Lancez dig CAA exemple.com (ou utilisez n’importe quel outil de recherche DNS en ligne) et confirmez que vos enregistrements apparaissent. Les changements peuvent mettre de quelques minutes à quelques heures à se propager sur internet. Votre certificat existant et tous les renouvellements continuent de fonctionner pendant ce temps — le CAA ne régit que les nouvelles émissions.

Notes rapides par plateforme : Sur Cloudflare, DNS → Records → Add record → type CAA. Sur Google Workspace, vous gérez le DNS chez votre bureau d’enregistrement (ou Cloud DNS si vous l’utilisez) — ajoutez-y les enregistrements CAA avec pki.goog. Sur Microsoft 365, le CAA ne se règle pas dans le centre d’administration M365 ; ajoutez-le là où le DNS de votre domaine est hébergé, en listant votre CA de certificat géré (souvent DigiCert). Sur les hébergeurs courants (GoDaddy, Namecheap, OVH, etc.), c’est dans le même panneau DNS où résident vos enregistrements A et MX.

Erreurs courantes

Lister la mauvaise CA — ou en oublier une. Le plus grand risque concret n’est pas la sécurité, c’est de bloquer vos propres renouvellements. Si vous utilisez plus d’un émetteur (par ex. un pour le site principal et un autre derrière Cloudflare), listez-les tous. Dans le doute, listez-en quelques-uns en qui vous avez confiance plutôt que trop peu.
Définir issue mais ignorer les génériques. Un domaine qui restreint les certificats normaux mais ne dit rien des génériques laisse toujours ouverte la voie générique, plus puissante. Définissez toujours issuewild aussi — soit vers votre autorité, soit sur ";" pour le bloquer.
Placer le CAA sur le mauvais nom. Le CAA est lu par l’autorité de certification pour le nom exact certifié, en remontant l’arborescence. Le définir à la racine de votre domaine (l’« apex », par ex. exemple.com) est la bonne approche — il couvre les sous-domaines par défaut, sauf si un sous-domaine définit le sien.
Supposer que votre plateforme l’a déjà fait. Cloudflare, Google et Microsoft gèrent les certificats mais n’ajoutent pas d’enregistrements CAA pour vous. À moins de les avoir ajoutés, votre domaine est toujours ouvert.
Le traiter comme une chose à régler une fois pour toutes sans surveillance. Une migration DNS ultérieure, un changement de bureau d’enregistrement ou un « rangement » d’enregistrements peut faire disparaître silencieusement votre protection CAA. Il vaut la peine de vérifier qu’elle est toujours là après tout changement DNS.

La couche technique (à transmettre à votre informaticien)

Le CAA est défini dans la RFC 8659 et imposé par les Baseline Requirements du CA/Browser Forum — toute CA publiquement reconnue est tenue de vérifier le CAA au moment de l’émission. Les enregistrements prennent la forme <flags> <tag> <value>, avec les étiquettes issue, issuewild et iodef. Une politique issue ou issuewild non vide est ce qui satisfait ce contrôle ; la présence de iodef seule ne le fait pas (c’est du signalement, pas de l’autorisation).

Une base solide à l’apex :

exemple.com.   CAA   0 issue "letsencrypt.org"
exemple.com.   CAA   0 issuewild ";"
exemple.com.   CAA   0 iodef "mailto:[email protected]"

Notes pour la personne qui met en œuvre :

Remontée de l’arborescence CAA : les CA évaluent le CAA depuis le FQDN demandé en remontant jusqu’à l’apex, en s’arrêtant au premier nom doté d’un enregistrement CAA. Un enregistrement à l’apex protège donc tous les sous-domaines, sauf si un sous-domaine publie le sien — utile si un sous-domaine précis utilise un émetteur différent.
La valeur ; dans issuewild signifie « aucune CA ne peut émettre de génériques » — un refus explicite. Utilisez-la chaque fois que les génériques ne font pas partie de votre configuration.
Le drapeau 0 est le drapeau issuer-critical ; 0 (non critique) est correct pour un usage normal. Évitez d’activer le bit critique sans le comprendre pleinement, car une étiquette critique mal comprise peut amener des CA conformes à refuser l’émission.
Émetteurs multiples : plusieurs enregistrements issue sont autorisés et cumulatifs — listez chaque CA légitimement présente dans votre stack (y compris les CA en arrière-plan utilisées par votre CDN/fournisseur de périphérie) pour éviter les échecs de renouvellement.
Vérification : dig CAA exemple.com +short, ou vérifiez via les outils de test CAA du CA/Browser Forum. Ce contrôle lui-même interroge le CAA via plusieurs résolveurs indépendants (DNS local, puis Google, Cloudflare et Quad9 en DNS-over-HTTPS en repli) et accepte la première réponse faisant autorité, de sorte qu’une panne d’un seul résolveur ne produira pas un faux « pas de CAA ».
Couplage avec DNSSEC : le CAA indique aux CA qui peut émettre ; le DNSSEC empêche la réponse CAA elle-même d’être falsifiée en transit. Ils sont complémentaires — pour les domaines à forte valeur, activez les deux.

Configurez-le chez votre hébergeur

Étape par étape pour les fournisseurs courants :

FAQ

Je ne suis pas technique — puis-je m'en occuper moi-même ?

Vous n'avez pas besoin de comprendre le détail, mais le correctif est une petite modification dans les réglages DNS de votre domaine, donc mieux vaut le confier à la personne qui gère votre site ou votre domaine. Envoyez-lui la section « Comment corriger » ci-dessous — c'est un changement de cinq minutes, sans coût. Nous ne facturons jamais que si vous voulez ensuite que nous continuions à surveiller que l'enregistrement reste en place ; le correctif lui-même est toujours gratuit.

Ajouter ceci va-t-il casser mon site ou mon certificat ?

Non — tant que vous listez l'autorité de certification que vous utilisez réellement, tout continue de fonctionner exactement comme avant. Un enregistrement CAA ne touche pas et ne remplace pas votre certificat existant ; il régit seulement qui a le droit d'en créer de nouveaux. La seule façon de provoquer un souci est d'oublier votre véritable autorité dans la liste, ce qui peut bloquer votre prochain renouvellement automatique — les étapes ci-dessous sont écrites précisément pour éviter cela.

Si les certificats sont émis automatiquement de nos jours, pourquoi en ai-je encore besoin ?

Les certificats automatiques sont bien et pratiques — le problème, c'est que le système est ouvert à tous par défaut, y compris à quelqu'un qui se fait passer pour vous. Un enregistrement CAA désigne simplement qui est autorisé, transformant une porte ouverte en une porte avec votre propre serrure. Il fonctionne aux côtés de l'émission automatique, pas contre elle.

Cela affecte-t-il mon classement Google ou ma note sur ce rapport ?

Cela affecte votre note de sécurité ici — un enregistrement CAA manquant est un élément noté, marqué comme une lacune de gravité moyenne, car il laisse ouverte une véritable voie d'usurpation. Ce n'est pas un facteur de classement Google direct, mais l'usurpation et le hameçonnage qu'il prévient sont exactement le genre d'incidents qui nuisent à la confiance et au trafic. Dans tous les cas, c'est un gain rapide et gratuit.

Quelle est la différence entre « issue » et « issuewild » ?

Un enregistrement « issue » contrôle les certificats normaux pour votre domaine et ses sous-domaines. Un enregistrement « issuewild » contrôle les certificats génériques (wildcard) — le certificat unique qui couvre tous les sous-domaines possibles à la fois (comme *.exemple.com). Les génériques sont plus puissants et donc plus risqués entre de mauvaises mains, alors il est de bonne pratique de les contrôler séparément : si vous n'utilisez pas de génériques, bloquez-les purement et simplement.

Nous utilisons Cloudflare / Google Workspace / Microsoft 365 — est-ce que cela couvre déjà ce point ?

Pas automatiquement. Ces plateformes gèrent vos certificats pour vous, mais à moins d'avoir explicitement ajouté des enregistrements CAA, votre domaine dit toujours au monde « n'importe quelle autorité peut émettre ». La bonne nouvelle, c'est que le correctif est le même simple changement DNS sur toutes, et là où Cloudflare ou votre hébergeur émet votre certificat, vous listez simplement cette autorité. Les notes par plateforme dans la section de correction ci-dessous couvrent les cas courants.