1 Introduction
Votre configuration TLS concerne le certificat que votre serveur présente aujourd'hui. Mais des dizaines d'autorités de certification (CA) publiques peuvent émettre un certificat pour votre domaine, et chacun de ces certificats est inscrit dans des journaux publics. En tant que propriétaire, vous avez donc deux questions à vous poser : qui a le droit d'émettre des certificats pour mon domaine, et qu'est-ce qui a réellement été émis ?
CAA répond à la première : un enregistrement DNS qui liste les autorités que vous utilisez. Certificate Transparency répond à la seconde : des journaux en ajout seul où tout certificat reconnu publiquement doit figurer. La partie Certificats d'un scan de domaine lit les deux, reconstitue l'historique de vos certificats et signale ceux que vous partagez avec d'autres domaines.
2017
Année où la vérification CAA avant émission est devenue obligatoire pour toutes les CA publiques
RFC 8659
La norme CAA actuelle (2019), qui remplace la RFC 6844
Public
Chaque nom de chaque certificat reconnu est consultable par tous, attaquants compris
2 Comment ça marche
Un certificat passe par trois étapes avant qu'un navigateur l'accepte. CAA intervient avant l'émission, Certificate Transparency après.
Prouver le contrôle
Le demandeur prouve à la CA qu'il contrôle le domaine (un fichier sur le site, un enregistrement DNS sous _acme-challenge, ou un email).
Vérifier CAA
La CA consulte votre enregistrement CAA. S'il existe et ne la cite pas, elle doit refuser.
Journaliser
La CA soumet le certificat aux journaux CT publics. Des navigateurs comme Chrome et Safari refusent un certificat qui n'y figure pas.
Prévenir, puis détecter
CAA réduit le nombre d'autorités qu'un attaquant pourrait tromper ou compromettre : de plusieurs dizaines à la ou les deux que vous utilisez vraiment. CT ne bloque rien, mais un certificat frauduleux pour votre domaine ne peut plus rester secret : il apparaît dans les journaux, où vous (ou un service de surveillance) pouvez le voir. L'un ne remplace pas l'autre, et les deux sont gratuits.
3 Analyse détaillée
CAA : qui peut émettre pour vous
Un ou plusieurs enregistrements CAA sur le domaine lui-même. Ils s'appliquent aussi à chaque sous-domaine qui n'a pas son propre CAA :
exemple.fr. CAA 0 issue "letsencrypt.org"
exemple.fr. CAA 0 issuewild ";"
exemple.fr. CAA 0 iodef "mailto:[email protected]"
issue et issuewild
issue liste les CA autorisées à émettre des certificats classiques. issuewild fait de même pour les wildcards (*.exemple.fr) ; en son absence, les wildcards suivent issue. La valeur ";" signifie « personne ». L'exemple ci-dessus autorise Let's Encrypt pour les certificats classiques et interdit tout wildcard.
iodef : qui est prévenu
Une adresse où une CA peut signaler une demande refusée. Toutes les CA ne l'utilisent pas, considérez-le comme un bonus. Le scan note son absence à titre d'information seulement.
Trouver le bon identifiant
Chaque CA documente le domaine à inscrire : letsencrypt.org, pki.goog (Google Trust Services), digicert.com, sectigo.com, etc. Les CDN et plateformes d'hébergement passent souvent par une ou plusieurs CA pour vous : lisez leur documentation avant de restreindre.
Dans le rapport, le bloc CAA affiche :
CAA record : Absent
N'importe quelle CA publique peut émettre pour votre domaine. Le scan le classe en gravité moyenne. Publier un enregistrement prend cinq minutes dans votre interface DNS.
Issuance matches CAA, et le tableau « Authorities that actually issued »
Le scan compare les CA à l'origine de vos certificats encore valides avec votre enregistrement. Not in CAA signifie qu'une CA a émis un certificat que votre enregistrement n'autorise pas aujourd'hui. Le plus souvent, l'enregistrement a été ajouté après le certificat, ou un prestataire oublié passe par une autre CA. Identifiez le cas, puis ajoutez cette CA ou faites révoquer et remplacer le certificat.
Validation ACME (_acme-challenge)
Un CNAME sur _acme-challenge délègue la validation des certificats à un tiers (un CDN, un service d'automatisation DNS). Ce tiers peut obtenir des certificats pour votre domaine, et CAA ne l'en empêche pas : CAA limite quelle CA signe, pas qui prouve le contrôle. Si le scan indique target zone missing, la délégation pointe vers un domaine qui n'existe plus, et celui qui l'enregistre pourra obtenir des certificats à votre nom. Supprimez cet enregistrement tout de suite. Les jetons TXT restés sur _acme-challenge (« stale tokens ») sont sans danger mais peuvent être nettoyés.
Historique des certificats
Construit à partir de Certificate Transparency, ce bloc lit vos anciens certificats comme une frise. Les pastilles donnent HTTPS since (âge du plus ancien certificat vu), le nombre de Certificates et d'Authorities, l'intervalle de renouvellement médian (Median renewal), le nombre de certificats valides aujourd'hui (Valid today) et la présence d'un Wildcard.
Une nouvelle autorité s'est mise à émettre
Le bandeau jaune apparaît quand une CA que vous n'utilisiez pas commence à émettre alors qu'une autre est déjà en place. Après un changement d'hébergeur ou de CDN, c'est normal. Si personne n'a rien changé de votre côté, cherchez qui a demandé ce certificat.
Noms wildcard valides
Un certificat wildcard couvre tous les sous-domaines de ce niveau. Sa clé privée vaut plus que celle d'un certificat à un seul nom, et elle finit souvent copiée sur de nombreux serveurs. Sachez où se trouve chacun, et préférez un certificat par service quand l'automatisation les rend gratuits.
Beaucoup de certificats valides en même temps, ou un renouvellement très rapproché
Que plusieurs plateformes (CDN, messagerie, préproduction) aient chacune leur certificat est normal. Un outil qui redemande un certificat tous les jours, ou des dizaines de certificats valides en même temps pour un seul nom, trahit généralement une boucle de renouvellement à corriger. « Log duplicates merged » n'est pas un problème : un précertificat et son certificat final sont journalisés séparément et comptés une seule fois.
Certificats partagés
Un même certificat peut lister de nombreux noms dans son champ Subject Alternative Name. Quand certains appartiennent à d'autres domaines sans rapport avec le vôtre, le scan marque le certificat comme Shared et compte les domaines co-signés. Ce ne sont pas vos sous-domaines : ce sont d'autres clients de la même plateforme.
Pourquoi cela arrive
Certains CDN, hébergeurs mutualisés et créateurs de sites regroupent de nombreux clients sur un certificat pour économiser des certificats ou des adresses IP. C'est le signe d'un hébergement mutualisé, pas d'une compromission.
Pourquoi c'est important
Vous ne maîtrisez pas la clé : celui qui la détient peut servir n'importe quel nom de la liste. Quiconque lit le certificat découvre aussi vos voisins, et les enquêteurs s'appuient sur ces listes pour relier des domaines entre eux. Pour un site de marque, une page de connexion ou tout ce qui touche aux données clients, demandez un certificat dédié à votre prestataire (souvent une option ou une formule) ou utilisez le vôtre.
Les journaux Certificate Transparency
Les journaux CT (RFC 6962) sont des registres publics, en ajout seul, des certificats émis. Vous pouvez les consulter vous-même sur crt.sh : saisissez %.exemple.fr pour voir tous les certificats de votre domaine et de ses sous-domaines.
S'en servir pour repérer les certificats frauduleux
Plusieurs services gratuits (certaines CA, certains CDN, des outils open source) vous envoient un email dès qu'un nouveau certificat pour votre domaine est journalisé. Activez-en un : c'est le seul moyen d'apprendre vite que quelqu'un a obtenu un certificat à votre nom.
Tout y est public, pour toujours
Des noms comme vpn-test.exemple.fr ou jira-old.exemple.fr restent lisibles après la fin du service. C'est ainsi que les attaquants énumèrent les sous-domaines. Les noms qui ne résolvent plus sont traités dans prise de contrôle de sous-domaine. Pour les machines purement internes, utilisez une CA privée ou un wildcard plutôt que de journaliser chaque nom.
Impossible de retirer une entrée
Si un certificat a été émis par erreur, faites-le révoquer par la CA. Il reste dans le journal, mais il est marqué révoqué et n'est plus accepté par les clients qui vérifient.
Par quoi commencer
Urgent : une délégation _acme-challenge vers une zone qui n'existe plus, ou un certificat que vous ne savez pas expliquer.
Important : publiez un enregistrement CAA avec les CA d'où viennent réellement vos certificats (le tableau « Authorities that actually issued » du scan vous donne la liste).
Hygiène : activez une surveillance CT, sortez les sites sensibles des certificats partagés et ajoutez iodef.
Vérifiez votre domaine sur mlab.sh
Un scan de domaine lit votre enregistrement CAA, le compare aux autorités qui ont réellement émis pour vous, reconstitue l'historique de vos certificats depuis Certificate Transparency et signale les certificats partagés.
Scanner votre domaine sur mlab.sh4 Red Flags
_acme-challenge délégué à une zone qui n'existe plus
Celui qui enregistre cette zone peut prouver le contrôle de votre domaine et obtenir des certificats valides. Supprimez le CNAME aujourd'hui.
Un certificat d'une autorité que personne n'a choisie
Un bandeau « nouvelle autorité » ou un verdict « Not in CAA » sans migration derrière. Trouvez le demandeur avant de conclure que c'est sans gravité.
Aucun enregistrement CAA
Toutes les CA publiques peuvent émettre pour vous, donc la plus faible fixe votre niveau de sécurité. Limitez-vous à celle ou aux deux que vous utilisez.
Votre site de connexion ou de paiement sur un certificat partagé
Une clé que vous ne maîtrisez pas couvre votre nom à côté de sites sans rapport. Demandez un certificat dédié.
Des noms internes dans les journaux CT
Un panneau d'administration, une préproduction ou un VPN publiés dans un certificat public offrent une liste de cibles toute prête. Utilisez une CA privée pour ce qui doit rester interne.
Modules connexes
Comprendre la configuration TLS
Versions de protocole, suites de chiffrement et validité du certificat : lire un résultat de scan TLS et corriger une configuration faible.
Votre surface d'attaque : les sous-domaines
Ce que l'énumération de sous-domaines révèle à un attaquant, et comment réduire la surface : hôtes oubliés, préprod, interfaces d'admin.
Prise de contrôle de sous-domaine et DNS orphelin
Comment un CNAME ou un NS oublié permet à n'importe qui de publier sur votre sous-domaine, et comment repérer et nettoyer ces entrées avant un attaquant.
Source : mlab Academy — Plateforme de sensibilisation à la cybersécurité
URL : https://academy.mlab.sh/fr-FR/page/certificats-caa-ct
Module : Certificats, CAA et Certificate Transparency — Sécuriser son domaine
Avertissement : Ce contenu est à des fins de sensibilisation uniquement.