Dernière mise à jour : 5 janvier 2025

RÉSUMÉ EXÉCUTIF : La PKI Internet (Infrastructure à Clé Publique) est un écosystème sensible et parfois fragile. Depuis que Netscape en a conçu le noyau de confiance en 1995, la communauté mondiale de la sécurité n’a cessé de comprendre les menaces et de faire évoluer diverses mesures d'atténuation, alors même que le monde continuait de fonctionner autour de ces changements. Red Sift s'est impliqué de près dans ce domaine, explorant l'état de l'art en matière de protection PKI et œuvrant à la protection de nos clients.

Ce livre blanc propose une analyse approfondie des enseignements tirés pendant le développement de Red Sift Certificates, notre solution phare pour la surveillance de la posture PKI. Nous commençons par une vue d’ensemble de la gestion de la confiance dans le monde, puis introduisons des concepts et technologies de plus en plus complexes, jusqu’à détailler les techniques que nous avons déployées pour aider nos clients à atteindre leurs objectifs de sécurité. Enfin, nous présentons la Surveillance à Haute Assurance de la Transparence des Certificats, une technique incontournable pour les organisations souhaitant le meilleur de la sécurité PKI publique.

Les 15 dernières années ont été remarquables pour Internet en matière de sécurité du transport. Après des décennies de négligence, nous avons assisté à un effort déterminé pour réussir le chiffrement, effort qui se poursuit encore. Il a fallu de nombreuses années, mais la communauté des ingénieurs a travaillé à la modernisation du Transport Layer Protocol (TLS) en l’adaptant à la cryptographie moderne, en supprimant l’obsolète et en conservant la rétrocompatibilité. Un vrai succès.

Et pourtant, les PKI publiques sont restées globalement aussi sûres (ou fragiles) qu'elles l'étaient auparavant.

En 2011, une petite Certification Authority (CA) néerlandaise nommée DigiNotar a été compromise et sa sécurité mise à nu. En quelques jours, des centaines de certificats ont été délivrés pour certaines des plus grandes propriétés mondiales. Google, Microsoft, Mozilla, Twitter… tous ont vu des certificats frauduleux émis en leur nom.

Pire, ces certificats ont servi dans des attaques actives visant environ 300 000 utilisateurs afin de compromettre leur chiffrement et récupérer leurs mots de passe et secrets. Une attaque d’une telle ampleur était inédite : rien de tel n’a été vu auparavant, ni depuis.

La même chose pourrait se produire aujourd’hui car les faiblesses fondamentales de notre modèle de confiance perdurent.

L’Infrastructure à Clé Publique (PKI) désigne le cadre technologique, politique et procédural permettant de gérer les identités numériques. Par exemple, chaque site web nécessite une identité numérique pouvant être vérifiée par les utilisateurs afin d’assurer un accès sécurisé et chiffré. Ces identités reposent sur des clés cryptographiques privées pouvant être vérifiées via les clés publiques correspondantes. En pratique, les clés publiques sont encapsulées dans des certificats contenant toutes les informations nécessaires à la vérification. Pour l’utilisateur final, les certificats sont un détail technique garantissant la sécurité, mais un écosystème complexe en coulisse permet réellement d’assurer le niveau de sécurité requis.

Malgré le terme « public » dans son nom, une PKI n'est pas forcément publique. Tout le monde peut créer une PKI privée et y appliquer les règles de son choix. Cependant, seule une PKI publique, basée sur des règles clairement définies et ouverte à tous, permet une sécurité à l’échelle mondiale. Web PKI en est un exemple : elle est fortement régulée et gérée par les principaux éditeurs de navigateurs pour protéger les sites web. Il y a aussi la PKI Internet, moins bien définie, qui opère parfois dans la Web PKI, parfois à part. Pour la suite, cette distinction est rarement primordiale, nous la soulignerons au besoin.

Comme mentionné, nous utilisons les certificats numériques pour authentifier l’accès aux sites web. C’est simple : avant d’accéder à la destination, le site doit présenter un certificat valide et prouver la possession de la clé privée correspondante. Par contre, le processus de délivrance des certificats est plus complexe.

D’abord, un groupe d’organismes de confiance, appelés Certification Authorities (CAs), est sélectionné. Leur compétence en sécurité réseau ainsi que leur fiabilité globale sont vérifiées, et on leur délivre des instructions strictes sur la forme des certificats. La condition principale est que les certificats ne soient délivrés qu’aux véritables propriétaires, selon le processus dit de validation.

Voici la difficulté : valider à l’échelle mondiale n’est pas facile, il s’agit de bâtir des relations de confiance à partir de rien. L’approche dominante repose sur la preuve de contrôle d’infrastructure. Cela signifie, par exemple, que pour demander un certificat pour « google.com », il suffit de démontrer un certain contrôle du domaine, typiquement en publiant un fichier spécial sur le site web.

Ce principe, hérité de Netscape à l’aube d’Internet, a permis la croissance fulgurante du Web car il est facile à utiliser pour tous. Malheureusement, il comporte deux faiblesses fondamentales :

• La validation s’opère sur des réseaux publics sans authentification cryptographique. Un adversaire capable de détourner le routage réseau, le DNS ou d’intercepter les communications peut subvertir le processus et obtenir des certificats frauduleux.
• Les propriétaires de domaines n’ont aucun contrôle sur les certificats émis pour leurs propres propriétés. Ils doivent faire confiance aux CAs pour agir correctement. Malgré les audits visant à garantir leur compétence, de nombreuses erreurs ou failles sont possibles. Comme vu avec DigiNotar, leur sécurité peut être brisée. Ils peuvent commettre des erreurs ou être victimes d’ingénierie sociale. Ou être légalement forcés par leur gouvernement à des pratiques interdites.

Comprendre ces failles est essentiel pour élaborer des stratégies de détection, de prévention et de limitation des dégâts en cas d’attaque.

Comme discuté précédemment, les certificats ne sont émis qu’après preuve de contrôle sur la portion d’infrastructure réseau visée. Pour les noms de domaine, le processus s’articule ainsi :

1. Une demande de certificat pour example.com est faite auprès d’une CA
2. La CA génère un long nombre aléatoire et le communique en retour
3. Le demandeur publie ce nombre aléatoire sur le site web example.com en clair
4. La CA vérifie que ce nombre est accessible en HTTP
5. La CA émet le certificat

Que peut-on en déduire ? Le processus de validation dépend de certains « tuyaux » d’Internet : résolution DNS, routage IP (BGP), avec l’hypothèse d’une communication non détournée. Or, rien de tout cela n’est fondamentalement sécurisé à ce jour et diverses attaques sont possibles. Exemple : une attaque BGP peut rediriger le trafic d'une IP vers l’attaquant. Un détournement DNS peut renvoyer un site vers une IP de l’attaquant. Une attaque active contre le site ou la CA produit le même effet.

Au vu de leur rôle critique pour la sécurité Internet, que sait-on sur les CAs ? Les éditeurs de navigateurs s’appuient sur le Common CA Database (CCADB) afin de suivre les CAs et leurs certificats dotés de pouvoirs d’émission. Cette base est publique et j’en ai récemment consulté les données. Voici ce que j’ai constaté :

• Il y a 94 organisations CA référencées, reconnues par au moins un des quatre grands éditeurs (Apple, Google, Microsoft, Mozilla).
• Parmi elles, 39 sont reconnues par les quatre éditeurs majeurs.
• Ces 94 organisations sont réparties sur 42 pays.
• Le groupe de 39 est réparti sur 22 pays.

Que conclure ? D’abord, la surface d’attaque liée au nombre d’organisations est déjà importante. Pour conserver notre sécurité, toutes doivent maintenir un niveau de sécurité élevé et éviter toute erreur opérationnelle. Ensuite, cette répartition géographique ouvre la voie à d’éventuels abus ou pressions politiques, dans un monde aux relations internationales complexes.

Ces faiblesses ne sont pas théoriques. Toutes se sont matérialisées à un moment ou un autre.

• En 2011, la sécurité de DigiNotar a été totalement compromise avec émission massive de certificats illégitimes.
• En 2021, le domaine de premier niveau .cd était mal configuré, permettant à un chercheur de rediriger 50 % du trafic DNS .cd (sous-domaines inclus).
• En 2022, des pirates ont mené une attaque BGP contre KLAYswap, une plateforme crypto sud-coréenne, pour voler l’équivalent de 2 M$ de crypto-monnaie.
• En 2023, l’accès réseau du serveur web « jabber.ru » a été détourné (soupçonné par la police allemande), autorisant l’émission d’un certificat servant à déchiffrer tout accès chiffré.
• En 2024, on a découvert les activités du groupe d’espionnage Salt Typhoon, soupçonné d’avoir compromis la connectivité réseau de 60 organisations dans 80 pays.
• En 2025, la CA Fina a été surprise à émettre pendant 16 mois douze certificats pour 1.1.1.1 (propriété Cloudflare) sans y être autorisée.

Ce ne sont que quelques exemples illustrant des vecteurs d’attaque. D’autres attaques similaires ont probablement eu lieu sans être détectées.

Suite à l’attaque DigiNotar de 2011, de nombreuses propositions ont émergé pour renforcer la sécurité des PKI publiques. Celles visant des réformes profondes du modèle d’émission ont échoué. Les améliorations incrémentales ont abouti, dont Certificate Transparency (CT) s’impose. Cette initiative de Google a été favorisée par la domination de Chrome.

L’objectif de CT, comme son nom l’indique, est d’ajouter à la Web PKI des systèmes assurant une visibilité complète de l’émission des certificats. Si l’on ne peut changer le modèle de confiance (pas de contrôle technique sur l’activité des CAs), au moins peut-on surveiller ces activités.

CT ajoute à la Web PKI des journaux CT (CT logs), jouant le rôle d’auditeurs. Avant son émission, chaque certificat doit voir certaines de ses données consignées sur plusieurs journaux CT opérés indépendamment. Chaque journal renvoie alors une confirmation sous forme de signature numérique. Enfin, ces signatures sont intégrées au certificat lui-même.

C’est cette dernière étape qui consacre l’efficacité du dispositif : désormais, tous les certificats portent la preuve d’inclusion dans des CT logs, ce qui permet aux navigateurs de refuser tout certificat n’y figurant pas. De fait, seuls les certificats publiquement enregistrés peuvent être utilisés sur le Web.

Remarque : C’est ici que la distinction entre Web PKI et PKI Internet importe. Certificate Transparency n'est actuellement mis en œuvre que dans la Web PKI et est appliqué par les navigateurs. Les certificats sans informations CT restent valables pour la PKI Internet, mais pas pour les sites web. Cela pourrait évoluer à l'avenir.

CT est de facto obligatoire depuis 2018. Chrome a été le premier navigateur à l’exiger, ce qui a suffi au vu de sa part de marché. Apple, Microsoft et Mozilla ont suivi. La visibilité permise par CT a eu une immense valeur : elle a favorisé une surveillance mondiale de l’émission des certificats, permettant des corrections et améliorations continues, encore en cours aujourd’hui.

Remarque : Les spécifications techniques de l’émission des certificats sont régulées par le CA/Browser Forum. Navigateurs et CAs décident ensemble des procédures de validation. La relation reste asymétrique : les navigateurs contrôlent la confiance dans les CAs, ce qui leur donne l’avantage.

Comme vu précédemment, Certificate Transparency est un outil efficace pour la surveillance globale, mais permet aussi aux propriétaires de domaines de surveiller l’émission de certificats associés à leur propriété. Vous vous rappelez peut-être que, du fait des faiblesses dans le fonctionnement des PKI publiques, il reste possible à des tiers (malveillants ou non) d’émettre des certificats pour des domaines qu’ils ne possèdent pas. Grâce à CT, tout le monde peut surveiller les émissions de certificats de n’importe quel domaine.

Les organisations craignant des émissions non autorisées peuvent installer des moniteurs CT afin d’examiner le flux mondial de certificats et d’identifier ceux qui les concernent. Ce mécanisme ouvre deux possibilités prometteuses :

• Les propriétaires de domaines surveillent l’émission de leurs certificats pour identifier les sources d’émission, mieux comprendre les usages des différentes CAs.
• Il devient également possible de détecter des certificats émis sans autorisation. En d’autres termes, CT permet d'identifier les certificats mal émis.

La Certificate Transparency, dans sa forme actuelle, ne garantit pas une visibilité parfaite sur toutes les émissions de certificats, car tous les fournisseurs n’exigent pas cette publication dans leur politique de stockage racine. Point sur la situation :

• Apple l’exige pour tous les certificats, navigateur et tout autre code utilisant leurs bibliothèques officielles
• Chrome de Google l’exige pour tous les sites web
• Edge de Microsoft (basé sur Chromium) l’exige également
• Firefox de Mozilla l’exige aussi

Comme CT n'est pas exigée par les Baseline Requirements et que les politiques racines ne forcent pas tous les CAs à tout publier sur CT, des failles demeurent. Techniquement, la publication CT n’est donc pas obligatoire. Si les CAs le font par défaut, certains permettent une désactivation. Par ailleurs, ils peuvent être légalement contraints de publier en dehors de CT.

De tels certificats seront invalides sur les sites web, mais resteront acceptés dans divers cas d’usage :

• Requêtes API (sauf depuis les plateformes Apple)
• Communication serveur à serveur (ex. échanges email ou XMPP)

On s’attend à ce que le périmètre de CT élargisse dans l’avenir pour couvrir tous les certificats publics. Pour l’instant, il est important d’intégrer ces limites dans l’évaluation des risques.

Certification Authority Authorization (CAA) est un standard permettant aux propriétaires de domaines de contrôler l’émission des certificats pour leurs propriétés. Les politiques CAA sont stockées dans le DNS, via l’enregistrement de ressource CAA, et offrent plusieurs fonctionnalités :

• Contrôler quelles CAs sont autorisées à émettre
• Différencier l’émission des certificats simples, Wildcard, email et BIMI
• Fournir des politiques fines par CA
• Publier un contact en cas de problème

Considérez la configuration suivante en exemple :

example.com.  CAA     0 issue "letsencrypt.org"
example.com.  CAA     0 issuewild "digicert.com"
example.com.  CAA     0 issuewild "sectigo.com"
example.com.  CAA     0 issuemail ";"
example.com.  CAA     0 issuevmc ";"
example.com.  CAA     0 iodef "pki@example.com"

Le CAA s’applique juste avant l’émission du certificat. Ce n’est pas une barrière technique forte, mais il est obligatoire pour les CAs (selon les Baseline Requirements). Toute émission qui ne respecte pas la configuration du propriétaire est considérée comme une mal-émission.

L’atout clé du CAA est de restreindre quelles CAs peuvent émettre quels types de certificats. S’il n’y a pas de politique CAA sur un domaine, toutes les CAs et tous les types de certificats sont autorisés. S’il y a au moins une directive par type de certificat (ex. : « issue » pour les certifs standards ou « issuemail » pour S/MIME), seules les CAs listées sont autorisées. Une simple présence d’un point-virgule interdit toute émission.

Décryptons l’exemple précédent :

• Let's Encrypt est autorisé à émettre les certificats standards
• DigiCert et Sectigo sont autorisés pour les certificats Wildcard
• Personne n’est autorisé à émettre de certificat S/MIME ni BIMI
• L’adresse « pki@example.com » peut être utilisée en cas de problème

Les balises « issue » et « issuewild » interagissent. Si seule « issue » est présente, l’émission de certificats standards ET Wildcard est permise. Dès que « issuewild » existe, elle régit exclusivement les certificats Wildcard.

Le CAA est flexible en termes de placement, chaque domaine peut avoir sa propre configuration. De plus, si aucune directive CAA n'existe sur un sous-domaine, c'est celle du parent qui s'applique si elle existe.

Après la mécanique de restriction des CAs, quel est l’apport en pratique ? Il s’agit surtout de réduire la surface d’attaque. On l’a vu : de très nombreuses CAs peuvent émettre des certificats pour vos domaines et chacune doit agir parfaitement à chaque fois.

En pratique, la plupart des organisations travaillent avec peu de CAs, toutes les autres représentant un risque. L’usage de CAA réduit ce risque à l'essentiel.

Dans les faits, on recommande l’approche suivante :

1. Établir la liste exhaustive des noms de domaines détenus
2. Utiliser CT pour inventorier les certificats publics
3. Surveiller CT pour établir la liste des CAs observées
4. Déployer une politique CAA restreignant l’émission à cette courte liste

Cette méthode réduit les risques PKI avec peu de chances de perturber les pratiques existantes. La configuration CAA souhaitée doit être définie lors de chaque enregistrement de domaine. Selon le niveau de sécurité désiré, une liste unique de CAs peut être utilisée pour tout, ou une par domaine.

Remarque : Le DNS sert fréquemment à déléguer un contrôle à des tiers (par exemple un service géré sur votre domaine via un enregistrement CNAME). Adoptée sur le domaine principal, une politique CAA ne devrait pas bloquer l’émission, même quand le tiers souhaite recourir à une CA non dans votre liste ; car le CNAME délègue aussi la politique CAA. Il faut simplement que vos prestataires gèrent CAA de leur côté.

Le standard CAA offre une bonne base mais reste insuffisant pour la protection de ressources critiques. Un « trou » demeure : CAA restreint les CAs, mais ne peut empêcher un tiers d’utiliser la même CA pour obtenir un certificat. Or, pratiquement toutes les organisations du monde utilisent Let's Encrypt, rendant la barrière d’utilisation très faible.

C’est là qu’interviennent les extensions ACME CAA. ACME (« Automatic Certificate Management Environment ») est le standard d’automatisation de l’émission popularisé par Let's Encrypt dès 2015 et désormais adopté par toutes les CAs. La RFC 8657 standardise deux apports situés à l’interface d’ACME et de CAA :

• Restreindre quels comptes clients d’une CA peuvent émettre
• Restreindre quelles méthodes de validation ACME peuvent être utilisées

Au moment d’écrire ces lignes, la RFC 8657 n’est pas obligatoire mais devrait être généralisée sous peu. Aujourd’hui, seule Let's Encrypt la supporte officiellement. L’avantage de ces extensions est que, contrairement à CAA standard, leur utilité n’exige pas l’adhésion de toutes les CAs, seulement de celles avec lesquelles vous travaillez. En cas de doute, contactez votre CA : certaines ont des fonctionnalités propriétaires similaires.

Avec la RFC 8657, il devient possible d’autoriser l’émission pour un domaine chez une CA donnée, tout en empêchant tout autre client de cette même CA d’émettre pour ce domaine. Voici ce à quoi cela ressemble avec Let's Encrypt :

Au moment de la rédaction, la RFC 8657 n'est pas obligatoire. Mais il est prévu qu'elle soit adoptée dans un avenir proche. Aujourd'hui, Let's Encrypt est la seule autorité de certification qui la prend officiellement en charge. La particularité de ces extensions est que, contrairement au CAA de base, elles n'ont pas besoin d'être prises en charge par toutes les autorités de certification pour être utiles. Elles doivent seulement être supportées par les autorités avec lesquelles vous faites affaire. En cas de doute, adressez-vous à votre autorité de certification. Certaines d'entre elles proposent des fonctionnalités propriétaires ayant des effets similaires.

Avec la RFC 8657, il est possible d'autoriser l'émission de certificats pour un nom de domaine auprès d'une seule autorité de certification, mais de manière à ce qu'aucun autre client de cette même autorité ne puisse émettre pour ce même nom. Voici à quoi cela peut ressembler avec Let's Encrypt :

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

Tant que le fragment de configuration ci-dessus est actif, seul le compte "1726001367" pourra obtenir des certificats de Let's Encrypt pour le domaine "example.com". Si l'émission à partir de plusieurs comptes est nécessaire, il est possible de configurer plusieurs balises CAA, chacune autorisant un compte client différent.

L'autre fonctionnalité de la RFC 8657 est qu'elle permet de restreindre les méthodes de validation pouvant être utilisées par ACME avant l'émission d'un certificat. ACME propose différentes méthodes et les clients peuvent normalement choisir celle qu'ils préfèrent lors de la demande de certificat. La méthode de validation la plus populaire est la preuve de possession, qui exige qu'une réponse au challenge de l'autorité de certification soit publiée sur le site pour lequel le certificat est requis.

Cette approche est souvent pratique, car elle permet à tout serveur de dialoguer directement avec une autorité de certification et d'obtenir lui-même ses certificats. Cependant, dans un contexte de sécurité, autoriser les serveurs à obtenir leurs propres certificats n'est souvent pas l'idéal ; quiconque contrôle un serveur peut obtenir des certificats pour n'importe quel domaine pointant vers celui-ci.

Une façon d'exploiter un tel arrangement est via une mauvaise configuration DNS orpheline. Pour qu'un nom de domaine fonctionne, des modifications de configuration doivent être apportées à deux niveaux. D'abord dans le DNS, où les enregistrements A et AAAA ajoutent les adresses IPv4 et IPv6 respectivement. Ensuite, un serveur doit être configuré à ces mêmes adresses IP pour fournir des réponses. Un problème DNS orphelin est créé lorsqu'un serveur est retiré mais que ses entrées DNS restent en place. Imaginez que les adresses IP proviennent d'un service cloud, comme c'est très souvent le cas. Désormais, toute personne à qui sont attribuées ces adresses IP peut obtenir des certificats pour le domaine abandonné. Ce n'est qu'un exemple, il existe d'autres vecteurs d'attaque dans le DNS produisant le même effet.

Une organisation souhaitant éviter ce type de problème peut choisir de centraliser l'émission de ses certificats et d'utiliser l'option de validation ACME basée sur le DNS. Toutefois, pour que cela fonctionne, il faut s'assurer que toutes les autres méthodes de validation sont désactivées. Voici à quoi cela pourrait ressembler grâce à la RFC 8657 :

example.com.    CAA    0    issue "letsencrypt.org;
                                   validationmethods=

                                  dns-01"

Avec cette configuration, l'émission de certificats ne pourra être approuvée qu'en effectuant des changements dans la configuration DNS du nom de domaine concerné.

Les deux méthodes de restriction définies dans la RFC 8657 autorisent des contraintes d'apparence similaire, mais il existe des différences clés qui peuvent influencer votre choix et le moment d'utilisation.

• La restriction de la méthode de validation ne requiert pas d’authentification de la demande. Lorsque l'émission est limitée à une méthode comme « dns-01 », seules les personnes contrôlant votre DNS (ou ses parties concernées) peuvent satisfaire la configuration CAA. Cela réduit la surface d'attaque, mais, dans ce cas, la demande d’émission n’est toujours pas authentifiée. Par exemple, il est toujours possible d’exploiter une mauvaise configuration DNS.
• La restriction par compte impose une authentification forte. Lorsque l’émission est restreinte à un compte client spécifique, cela impose une authentification forte de la demande d’émission, avant toute validation. Avec ACME, par exemple, les comptes sont sécurisés par cryptographie à clé publique. La toute première activité de tout client ACME est de créer une identité cryptographique unique qui sera utilisée pour chaque émission. Lorsqu'une restriction par compte est en place, l’authentification de la demande est la première étape de l’interaction ACME, car le client doit prouver son association avec le compte indiqué dans la configuration CAA.

Note : En juin 2025, le CA/Browser Forum a voté l’adoption du bulletin SC-085v2, qui ajoute l’exigence de validation DNSSEC lors de la consultation CAA et de la validation du contrôle de domaine (DCV). Ces changements deviendront obligatoires pour toutes les autorités de certification à partir de mars 2026. Après cette date, les domaines utilisant DNSSEC ne seront plus vulnérables à aucune forme de spoofing DNS. 

Les extensions définies par la RFC 8657 permettent de déployer des contrôles de sécurité plus stricts pour l’émission de certificats, mais cette démarche n'est pas sans coût. Elle nécessite du temps et des ressources pour restructurer et organiser l’émission de certificats en alliant compatibilité et sécurité renforcée. En général, il n’est pas pertinent d’adopter cette approche pour tous les domaines d’une organisation car ce ne serait pas rentable. Cependant, elle peut être appliquée à un petit nombre de propriétés de grande valeur. Pour le reste, il suffit généralement de restreindre l’émission à un nombre limité d’autorités de certification.

Pour vos propriétés à forte valeur, envisagez l’approche suivante :

1. Choisissez deux ou trois autorités de certification compétentes avec lesquelles travailler. Il en faut au moins deux pour éviter un point de défaillance unique. Pour les propriétés critiques, il est conseillé de disposer toujours d’au moins un certificat de secours valide au cas où un problème surviendrait avec le certificat principal. A minima, vos autorités doivent prendre en charge la RFC 8567 ou offrir une fonctionnalité propriétaire équivalente.
2. Déployez une configuration CAA stricte sur le nom de domaine principal, restreignant l’émission uniquement aux autorités de certification sélectionnées et — point crucial — uniquement aux comptes spécifiques auprès de ces autorités. Une telle configuration garantira une forte validation cryptographique.
3. Surveillez votre configuration DNS afin de a) vous assurer qu’il n’y a pas de DNS orphelin et b) vérifier s’il existe des délégations vers des tiers via des CNAME (qui pourraient avoir leur propre configuration CAA).

Comme nous l’avons déjà vu, la Certificate Transparency a transformé notre capacité à surveiller les activités des autorités de certification. Néanmoins, la surveillance comporte certains défis :

• Il reste possible de publier des certificats publics en dehors du CT, comme évoqué précédemment dans ce document.
• La surveillance du CT n’est pas encore généralisée. Malgré des années d'obligation, la plupart des organisations ne consacrent toujours pas suffisamment de ressources à la surveillance de l'émission de certificats pour leurs propres propriétés.
• Distinguer le signal du bruit est difficile. Les certificats contiennent souvent trop peu d’informations pour différencier une émission normale d’une émission frauduleuse par un tiers. Pour cela, il faut des outils de surveillance avancés, mais la plupart des organisations n’en sont pas encore équipées.

Bien que l'objectif de ce document soit d’explorer les possibilités, nous reconnaissons que de nombreuses organisations n’ont pas besoin du nec plus ultra en matière de sécurité. Même celles qui en ont besoin n’exigent généralement pas la meilleure sécurité pour l’ensemble de leurs domaines et sites web.

Nous vous conseillons de diviser votre parc en trois groupes selon leur profil de risque :

• Très faible risque : mettez dans ce groupe toute adresse de domaine inutilisée ou « parquée ». Selon la taille de votre organisation, il peut n’y en avoir que quelques-uns, mais parfois des centaines. À moins que la gestion DNS ne soit parfaitement automatisée, cela ne vaudra probablement pas la peine d’investir pour améliorer la sécurité de ce groupe. 
• Faible risque : mettez dans ce groupe tous les noms de domaines sur lesquels vous hébergez de véritables sites ou applications. Ce devrait être le choix par défaut. Pour ce groupe, adoptez une configuration CAA simple limitant l’émission à un nombre restreint d’autorités de certification comme évoqué plus haut. Ces propriétés sont peu susceptibles d'être attaquées ; la CAA servira essentiellement à renforcer votre politique de choix d’autorité de certification.
• Haut risque : placez ici toutes vos propriétés à haut risque — toute ressource exposée à de vraies menaces, comme les sites de transactions financières, affaires gouvernementales, communications, ou toute cible potentielle d’attaques réseau actives. Protégez ce groupe avec tous les moyens techniques à votre disposition.

La surveillance CT à haute assurance est une méthode permettant de contrôler avec certitude le flux de certificats publiés dans Certificate Transparency, et de distinguer les certificats sous votre contrôle de ceux obtenus par des tiers non autorisés.

Conceptuellement, la méthode est simple et repose sur la validation de ce qui est « reconnu comme sûr » ; tout le reste n’est donc que suspect :

1. Maintenez un inventaire des certificats dont vous détenez le contrôle
2. Surveillez la Certificate Transparency pour repérer les certificats inconnus

Voilà tout. Seulement deux étapes, mais la première peut nécessiter un travail important selon votre organisation. Rappelez-vous : cela ne s’applique qu’aux propriétés à haut risque, pas à l’ensemble de votre parc.

• Si vous utilisez un outil de gestion du cycle de vie des certificats (CLM), ou ACME avec une autorité de certification commerciale, ces solutions proposent généralement un inventaire intégré. Il ne devrait pas être difficile d’extraire vos certificats, mais il faudra programmer un accès à leurs API.
• Si vous utilisez ACME avec une autorité gratuite (ex : Let's Encrypt), il se peut qu’il n’y ait pas d’inventaire exploitable. Dans ce cas, il faudra mettre en place un mécanisme pour collecter les certificats émis et les transférer vers un emplacement centralisé. Ce sera plus facile si tous vos certificats proviennent du même serveur, mais cela reste faisable même avec plusieurs serveurs.

En pratique, il est probable que vous ayez besoin de maintenir une base de données distincte pour conserver vos propres certificats. En effet, l’émission centralisée est très rare en pratique, surtout à grande échelle. Il existe toujours des cas particuliers, notamment lorsque certaines parties de votre PKI publique sont déléguées à des tiers. La solution complète devra intégrer plusieurs sources de données pour disposer d’une vue exhaustive.