Surveillance de la transparence des certificats à haut niveau d'assurance

RÉSUMÉ EXÉCUTIF : La PKI Internet (Infrastructure à Clé Publique) est un écosystème sensible et parfois fragile. Depuis que Netscape a conçu le noyau de son modèle de confiance en 1995, la communauté mondiale de la sécurité s'efforce de comprendre les menaces et, avec le temps, de faire évoluer diverses mesures d’atténuation, tandis que le monde continue de fonctionner au gré de ces changements. Red Sift est étroitement impliqué dans ce domaine, explorant l'état de l'art de la protection PKI et travaillant à la sécurité de ses clients.

Ce livre blanc propose une analyse approfondie des enseignements tirés lors de la création de Red Sift Certificates, notre solution phare de surveillance de la posture PKI. Nous commençons par un aperçu de la gestion de la confiance dans le monde, puis introduisons progressivement des concepts et technologies de plus en plus complexes, jusqu’à explorer les techniques mises en œuvre pour aider nos clients à atteindre leurs objectifs de sécurité. Enfin, nous présentons la surveillance de la transparence des certificats à haut niveau d'assurance, une technique indispensable pour les organisations ayant besoin d’une sécurité PKI publique maximale.

Les 15 dernières années ont été favorables à l’Internet en matière de sécurité de la couche de transport. Après des décennies de négligence, un effort déterminé a été engagé pour obtenir un chiffrement efficace, effort qui se poursuit encore aujourd’hui. Il a fallu de longues années, mais la communauté des ingénieurs a travaillé à la mise à jour du protocole de couche de transport (TLS) : modernisation de la cryptographie, suppression du superflu et maintien d’une compatibilité ascendante. Un véritable succès.

Et pourtant, les PKI publiques restent essentiellement aussi sûres qu’elles l’ont toujours été.

En 2011, une petite Autorité de Certification (CA) néerlandaise baptisée DigiNotar a été attaquée et sa sécurité entièrement compromise. Dans les jours qui ont suivi, des centaines de certificats ont été émis pour certains des sites les plus importants au monde. Google, Microsoft, Mozilla, Twitter… tous ont été victimes de certificats frauduleux.

Pire encore, ces certificats ont été utilisés contre environ 300 000 utilisateurs lors d’une attaque réseau active visant à contourner le chiffrement et collecter secrets et mots de passe. Une attaque d’une telle ampleur était sans précédent : cela n’avait jamais été observé auparavant, et cela ne s’est jamais reproduit depuis.

Le même scénario pourrait survenir aujourd’hui, car les faiblesses fondamentales de notre modèle de confiance subsistent.

L’Infrastructure à Clé Publique (PKI) désigne l’ensemble des technologies, politiques et procédures permettant de gérer les identités numériques. Par exemple, chaque site web a besoin d’une identité numérique vérifiable par les utilisateurs, afin de garantir un accès sécurisé et chiffré. Ces identités reposent sur des clés de chiffrement privées vérifiées grâce aux clés publiques correspondantes. En pratique, ces clés publiques sont intégrées à des certificats contenant toutes les informations nécessaires à la validation. Pour l’utilisateur final, les certificats sont un détail technique garantissant la sécurité, mais un écosystème complexe agit en coulisses pour assurer l’efficacité de ces certificats.

Malgré le mot « publique » dans son nom, une PKI n’a pas à être publique. N’importe qui peut créer sa propre PKI privée et définir ses propres règles. Or, la sécurité à l’échelle mondiale ne peut être assurée que par des PKI publiques, fondées sur des règles clairement définies et ouvertes à la participation de tous. La Web PKI en est un exemple ; elle est strictement réglementée et gérée par les principaux éditeurs de navigateurs, et utilisée pour la protection des sites web. Il existe aussi la PKI Internet, moins formalisée, qui fonctionne parfois avec la Web PKI, parfois en dehors. Pour ce guide, la distinction importe peu en général, mais sera précisée lorsque nécessaire.

Comme évoqué, nous utilisons en surface des certificats numériques pour authentifier l’accès aux sites web. C’est la partie simple : avant d’accéder à votre destination, le site doit présenter un certificat valide et prouver la possession de la clé privée correspondante. Le processus d’émission d’un certificat, lui, est bien plus complexe.

Tout d'abord, nous formons un groupe d’organisations de confiance appelées autorités de certification (CAs). Nous nous assurons de leur compétence et de leur maîtrise de la sécurité réseau, puis nous leur donnons des instructions précises sur la forme des certificats. L’exigence essentielle est que les certificats numériques soient émis seulement à leurs propriétaires légitimes, via un processus appelé validation.

Voici la partie délicate : réaliser une validation à l’échelle mondiale n’est pas une mince affaire, car il faut créer des relations de confiance ex nihilo. L’approche dominante aujourd’hui s’appuie sur la preuve du contrôle de l’infrastructure. Concrètement, si vous souhaitez un certificat pour « google.com », il vous suffit de prouver un niveau de contrôle sur ce nom de domaine, par exemple en publiant un fichier spécial sur le site.

Ce dispositif, créé par Netscape à l’aube d’Internet, a encouragé la croissance fulgurante du Web, car il est facile à utiliser pour tous. Malheureusement, il souffre de deux faiblesses intrinsèques :

• La validation s’effectue sur des réseaux publics, sans authentification cryptographique. Un attaquant capable de manipuler l’acheminement réseau ou le DNS, ou d’intercepter la communication, peut obtenir à la place des certificats frauduleux.
• Les propriétaires de domaines n’ont aucun contrôle sur les certificats émis pour leurs propriétés. Les CAs sont supposés être dignes de confiance. Même si on les audite, plusieurs choses peuvent mal tourner, et ont déjà mal tourné. Comme le scandale DigiNotar l’a démontré, leur propre sécurité peut être compromise. Ils peuvent commettre des erreurs ou être victimes d’attaques de type ingénierie sociale. Ou encore être contraints légalement par leur gouvernement d’agir au-delà des limites autorisées.

Comprendre ces faiblesses est essentiel pour définir les meilleures stratégies de détection/prévention, et minimiser les dégâts si de telles attaques surviennent.

Comme dit précédemment, l’émission d’un certificat n’a lieu qu’après démonstration du contrôle sur la partie pertinente de l’infrastructure réseau. Pour les noms de domaine, le processus se résume ainsi :

1. Un certificat pour example.com est demandé auprès d’une CA
2. La CA génère un long nombre aléatoire et le renvoie
3. Le demandeur publie ce nombre sur le site example.com en clair
4. La CA vérifie que le nombre aléatoire est visible via HTTP
5. La CA émet le certificat

Que pouvons-nous en déduire ? Le processus de validation s’appuie sur des « tuyaux » Internet de base, comme la résolution DNS, le routage d’adresses IP (via BGP), et part du principe que la communication ne sera pas détournée. Aujourd’hui, aucune de ces composantes n’est parfaitement sécurisée, et diverses attaques peuvent cibler ces points. Par exemple, une attaque BGP peut rediriger le trafic d’une adresse IP vers l’attaquant. Une usurpation DNS peut pointer un site vers une adresse IP contrôlée par l’attaquant. Une attaque réseau active contre l’un des deux bouts (site ou CA) produit le même résultat.

Maintenant que nous comprenons le rôle-clé des CAs dans la sécurité Internet, que savons-nous d’elles ? Les éditeurs de navigateurs se basent sur un système, le Common CA Database (CCADB), pour recenser les CAs et leurs certificats numériques autorisés à émettre des certificats utilisateurs. Cette base de données est publique, et je l’ai récemment examinée. Voici mes découvertes :

• 94 organisations CA sont enregistrées, reconnues par au moins l’un des quatre principaux acteurs (Apple, Google, Microsoft ou Mozilla).
• Parmi elles, 39 sont reconnues par les quatre acteurs.
• Les 94 organisations sont réparties dans 42 pays.
• Le groupe restreint de 39 organisations couvre 22 pays.

Que conclure ? Premièrement, le simple nombre d’organisations génère une surface d’attaque importante. Toutes doivent agir parfaitement tout le temps pour préserver la sécurité. Deuxièmement, dans un monde où la géopolitique est complexe, avoir des CAs réparties sur autant de pays ouvre la porte à des abus politiques, en théorie comme en pratique.

Ces faiblesses ne sont pas théoriques : elles ont toutes été exploitées, à divers moments dans l’histoire.

• En 2011, la sécurité de la CA DigiNotar a été totalement compromise et des centaines de certificats usurpés ont été générés.
• En 2021, le domaine de premier niveau .cd souffrait d’un serveur de noms mal configuré, permettant à un chercheur de rediriger 50 % du trafic DNS du .cd (sous-domaines inclus).
• En 2022, des attaquants ont mené une attaque BGP contre KLAYswap, une plateforme crypto sud-coréenne, volant 2 millions de dollars.
• En 2023, l’accès réseau au serveur web « jabber.ru » a été détourné, semble-t-il par la police allemande, permettant la génération d’un certificat utilisé pour déchiffrer tous les accès chiffrés.
• En 2024, des activités du groupe d’espionnage Salt Typhoon ont été découvertes ; il aurait compromis la connectivité réseau de 60 organisations dans 80 pays.
• En 2025, la Fina CA a été surprise avoir émis douze certificats pour l’adresse IP 1.1.1.1 (appartenant à Cloudflare) sans autorisation, sur 16 mois.

Ce ne sont que quelques exemples représentatifs. Chaque cas illustre un vecteur d’attaque particulier. Il est probable que d’autres attaques similaires n’aient jamais été découvertes.

À la suite de l’attaque DigiNotar en 2011, de nombreuses propositions pour sécuriser les PKI publiques ont émergé. Celles cherchant à réformer radicalement l’émission des certificats ont échoué. Les mesures d’amélioration incrémentale ont, elles, abouti, notamment la Certificate Transparency (CT). Cet effort, lancé par Google via son navigateur Chrome, s’est particulièrement distingué.

L’objectif de CT, comme son nom l’indique, est d’étendre la Web PKI en y ajoutant une visibilité complète sur l’émission des certificats. Si l’on ne peut pas techniquement contrôler ce que font les CAs, nous pouvons au moins observer leurs actions.

Avec CT, la Web PKI s’enrichit de journaux CT qui servent d’auditeurs. Avant qu’un certificat ne soit émis, les informations essentielles doivent être inscrites dans plusieurs journaux CT indépendants. Chaque journal délivre des confirmations par signature numérique pour chaque certificat observé sur le point d’être émis. Enfin, ces signatures sont intégrées au certificat lui-même.

C’est cette dernière étape qui fait tout fonctionner : dès lors que tous les certificats comportent une preuve d’enregistrement dans des journaux CT, les navigateurs peuvent refuser les certificats dont l’inscription n'est pas vérifiée. Par conséquent, seuls les certificats publiés peuvent servir pour les sites web.

Note : La distinction entre Web PKI et PKI Internet a ici son importance : la Certificate Transparency n’est actuellement mise en œuvre que dans la Web PKI et imposée par les navigateurs. Les certificats sans données CT restent valides ; ils fonctionnent pour les usages PKI Internet, mais pas pour les sites web. Cela pourrait évoluer.

CT est devenu pratiquement obligatoire depuis 2018. Chrome est le premier navigateur à l’avoir exigé, ce qui a suffi vu sa domination sur le marché. Apple, Microsoft et Mozilla ont ensuite adopté la démarche. La visibilité offerte par CT a une valeur immense, rendant possible une surveillance mondiale en continu des émissions de certificats, avec des ajustements et perfectionnements successifs encore en cours.

Remarque : Les spécifications techniques régissant l’émission des certificats sont pilotées par un organe professionnel baptisé CA/Browser Forum. Navigateurs et CAs décident conjointement des procédures de validation et d’émission. La relation est dissymétrique : les navigateurs décident de leur propre liste de confiance, ce qui leur donne l’avantage dans les négociations.

Comme vu plus haut, la transparence des certificats est un outil précieux pour la surveillance globale de l’écosystème, mais permet aussi au propriétaire d’un domaine de surveiller l’émission de certificats liés à ses propriétés. Les faiblesses du fonctionnement des PKI publiques permettent à des tiers, malveillants ou non, d’émettre des certificats pour des domaines ne leur appartenant pas. Grâce à CT, tout le monde peut surveiller les certificats de n’importe quel domaine.

Les organisations soucieuses d’activités non autorisées peuvent mettre en place des moniteurs CT pour analyser le flux mondial de certificats et retrouver ceux qui les concernent. Deux perspectives intéressantes en découlent :

• Surveiller ses propres certificats pour comprendre les centres d’émission et les tendances, ainsi que le recours aux différentes CAs.
• Détecter les certificats non autorisés. En d’autres termes, CT permet de repérer des certificats mal émis.

La Certificate Transparency, telle qu’implémentée aujourd’hui, n’offre pas une visibilité parfaite sur toutes les émissions de certificats dans le monde. En effet, tous les éditeurs ne l’imposent pas dans leurs politiques root store. Voici la situation actuelle :

• Apple impose CT pour tous les certificats, y compris sur son navigateur et tout code utilisant ses bibliothèques officielles
• Chrome de Google exige CT pour tous les sites web
• Edge de Microsoft, basé sur Chromium, requiert également CT
• Firefox de Mozilla impose aussi CT

Étant donné que CT n'est pas imposé par les « Baseline Requirements », et que les politiques root store n’imposent pas à toutes les CAs d’enregistrer tous les certificats dans les journaux CT, il existe des failles exploitables. Techniquement donc, la publication dans CT n’est pas obligatoire. Même si la plupart des CAs utilisent CT par défaut, certaines proposent une option d’exclusion. En outre, elles pourraient être contraintes par la justice à publier en-dehors de CT.

De tels certificats seront évidemment inutilisables pour les sites web, mais pourraient être valides dans certains cas :

• Requêtes d’API (à l’exception des plateformes Apple)
• Communications serveur à serveur (échange de mails, XMPP, etc.)

Nous anticipons que le périmètre de CT s’étendra à l’avenir à tous les certificats publics. En attendant, gardez en tête ses limites et ajustez vos modèles de menaces en conséquence.

La Certification Authority Authorization (CAA) est une norme permettant aux détenteurs d’un nom de domaine de contrôler l’émission de certificats pour leurs propriétés. Les politiques CAA sont stockées dans le système DNS via un enregistrement CAA. Plusieurs fonctions sont supportées :

• Limiter quelles CAs sont autorisées à émettre
• Contrôles séparés pour l’émission de certificats ordinaires, wildcards, ainsi que pour les certificats email et BIMI
• Possibilité de définir des politiques fines, par CA
• Diffusion d’informations de contact pour traiter les incidents

Voici un exemple de configuration :

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"

La CAA est appliquée juste avant l’émission du certificat. Ce n’est pas un contrôle technique fort, mais l’usage de la CAA est imposé à toutes les CAs via les Baseline Requirements. Toute émission ne respectant pas la CAA du détenteur est considérée comme une émission illicite.

La force de la CAA réside dans sa capacité à limiter quelles CAs ont le droit d’émettre quels types de certificats. Sans politique CAA sur un domaine, tous les types de certificats et toutes les CAs sont autorisés. Mais s’il existe une directive (par exemple « issue » pour les certificats ordinaires ou « issuemail » pour S/MIME), seules les CAs mentionnées sont autorisées. Un point-virgule signifie qu’aucune émission n’est autorisée.

Décodons la configuration précédente :

• Let’s Encrypt est autorisé à émettre des certificats standards
• DigiCert et Sectigo sont autorisés à émettre des certificats wildcard
• Aucune autorité n’a le droit d’émettre des certificats S/MIME ni BIMI
• L’adresse « pki@example.com » peut être utilisée pour signaler les problèmes

Les balises « issue » et « issuewild » fonctionnent ensemble. Si seule « issue » est présente, l’émission de certificats standards comme wildcard est autorisée. Mais si « issuewild » existe, elle contrôle exclusivement les wildcards.

La CAA est flexible dans sa localisation. Chaque domaine peut comporter sa politique propre. Si aucune CAA n’est définie au niveau d’un sous-domaine, la configuration de la racine est répercutée si disponible.

Dans la section précédente, nous avons vu comment restreindre quelles CAs peuvent émettre ; en quoi cela aide-t-il vraiment ? Cette action réduit considérablement la surface d’attaque. Rappelons que de nombreux points faibles dans les PKI publiques découlent du nombre de CAs pouvant émettre pour vos propriétés, alors qu’en réalité, vous ne travaillez qu’avec un petit nombre. La CAA réduit cette exposition.

L’approche recommandée :

1. Établir une liste exhaustive de ses noms de domaine
2. Utiliser CT pour répertorier tous les certificats publics
3. Surveiller CT quelque temps pour lister les CAs observées
4. Déployer une CAA restreignant l’émission à la liste restreinte des CAs observées

Cette méthode simple minimise le risque PKI, tout en évitant au maximum de perturber les habitudes d’émission existantes. Il faudra appliquer la politique CAA à chaque nom de domaine. Selon le niveau de sécurité voulu, il est possible de choisir une liste unique de CAs pour toutes ses propriétés ou d’affiner le choix par domaine.

Note : Le DNS est souvent utilisé pour déléguer certains contrôles à des tiers (hébergement géré via CNAME). Définir une CAA sur le domaine principal ne perturbe pas l’émission de certificats par un tiers, à condition que celui-ci gère sa propre politique CAA. La seule contrainte : il faut que la délégation soit prise en charge et que le tiers connaisse la CAA et définisse sa propre politique adaptée.

La CAA standard constitue une bonne base, mais elle ne suffit pas pour sécuriser des propriétés de grande valeur. Une faille réside dans le fait que restreindre une CA ne suffit pas à empêcher des tiers d’utiliser cette même CA pour obtenir des certificats. Cela est aggravé par la popularité de Let’s Encrypt, utilisé par pratiquement tout le monde pour ses certificats gratuits et l’automatisation offerte. Cela abaisse le seuil d’obtention de certificats Let’s Encrypt.

Les extensions ACME pour CAA répondent à ce besoin. ACME signifie Automatic Certificate Management Environment : le standard de gestion automatique de certificats mis à l’honneur par Let’s Encrypt dès 2015, aujourd’hui adopté par toutes les CAs. La RFC 8657 ajoute deux fonctionnalités au croisement d’ACME et CAA :

• Restreindre à quels comptes clients d’une CA l’émission est autorisée
• Limiter quelles méthodes de validation ACME sont acceptées

Au moment où nous écrivons, la RFC 8657 n’est pas encore obligatoire, mais son adoption est attendue prochainement. Aujourd’hui, seul Let’s Encrypt la prend officiellement en charge. Ces extensions n’ont pas besoin d’être universellement supportées pour être utiles, mais uniquement par les CAs de votre choix. En cas de doute, contactez votre CA : certaines offrent des fonctions propriétaires similaires.

Grâce à la RFC 8657, il devient possible d’autoriser l’émission d’un certificat pour un domaine via une seule CA, mais en s’assurant qu’aucun autre client de cette CA ne pourra faire de même. Voici à quoi cela pourrait ressembler avec Let’s Encrypt :

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

Aussi longtemps que cette configuration sera en place, seul le compte « 1726001367 » pourra obtenir des certificats Let’s Encrypt pour « example.com ». Si plusieurs comptes sont nécessaires, il suffit de multiplier les balises CAA, chacune autorisant un compte distinct.

L’autre fonctionnalité de la RFC 8657 permet de restreindre les méthodes de validation ACME utilisables avant émission du certificat. ACME propose divers modes, et les clients peuvent en choisir un lors de leur demande. La méthode la plus courante est la preuve de possession, qui impose de publier une réponse à la demande de la CA sur le site concerné.

Cette approche est souvent pratique car elle donne à chaque serveur la possibilité de demander des certificats pour lui-même. Mais, côté sécurité, permettre à n’importe quel serveur d’obtenir ses propres certificats n’est pas optimal : quiconque contrôle le serveur peut obtenir n'importe quel certificat pour tous les domaines associés.

Un exemple d’exploitation est la mauvaise configuration DNS dite « dangling ». Pour qu’un domaine fonctionne, il faut le configurer dans le DNS (A/AAAA records) puis sur le serveur lié. Un problème « dangling DNS » survient lorsqu’un serveur est supprimé mais que le DNS subsiste. Imaginons que l’adresse IP provienne d’un cloud – fréquent en pratique. Toute personne obtenant cette IP pourra alors demander des certificats pour le domaine en question. Ce n’est qu’un exemple parmi d’autres vecteurs d’attaque DNS.

Une organisation souhaitant empêcher ce type d’incident peut centraliser l’émission de ses certificats et utiliser la validation ACME basée sur DNS. Pour cela, il est impératif d’interdire toutes les autres méthodes de validation. Voici à quoi ressemblerait cette configuration avec la RFC 8657 :

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

                                  dns-01"

Avec cette configuration, seule une modification du DNS du domaine cible permettra de valider et d’émettre un certificat.

Les deux restrictions définies dans la RFC 8657 sont un peu similaires, mais elles présentent des différences essentielles pouvant influencer votre choix.

• La restriction par méthode de validation ne requiert pas d’authentification de la demande. Restreindre l’émission à une méthode spécifique permet uniquement à ceux qui contrôlent votre DNS d’obtenir un certificat – ce qui limite la surface d’attaque sans supprimer certains risques. Ainsi, une erreur de configuration DNS reste exploitable.
• La restriction par compte impose une authentification forte. En limitant l’émission à un compte client spécifique, la demande doit d’abord être authentifiée de manière forte. Avec ACME, chaque client crée une identité cryptographique unique, utilisée pour chaque émission. La restriction par compte rend l’authentification obligatoire dès la première étape du protocole ACME : le client doit prouver qu’il est lié au compte CAA spécifié.

Note : En juin 2025, le CA/Browser Forum a voté l’adoption du Ballot SC-085v2, imposant la validation DNSSEC lors des requêtes CAA et DCV (validation de contrôle de domaine). Ces changements deviendront obligatoires pour toutes les CAs à compter de mars 2026. Dès lors, les domaines DNSSEC ne seront plus vulnérables au spoofing DNS.

Les extensions RFC 8657 permettent d’appliquer des contrôles stricts sur l’émission de certificats, mais cela a un coût. Il faut investir du temps et des ressources pour adapter ses structures et procédures. Il est en général inutile de protéger tous les domaines de l’organisation avec ses méthodes, car ce ne serait pas rentable. Cela est cependant conseillé pour les propriétés particulièrement sensibles. Pour le reste, une simple restriction au niveau des CAs suffit.

Pour vos propriétés stratégiques, suivez cette démarche :

1. Choisissez deux ou trois CAs de confiance. Il en faut au moins deux pour éviter tout point unique de défaillance. Idéalement, prévoyez toujours au moins un certificat de secours valide en cas de problème avec le principal. Vos CAs doivent obligatoirement prendre en charge la RFC 8567 ou offrir une fonctionnalité équivalente propriétaire.
2. Déployez une CAA stricte sur le domaine principal, restreignant l’émission aux seules CAs choisies, et – essentiel – aux comptes clients spécifiques. Vous obtenez ainsi une validation cryptographique forte.
3. Surveillez la configuration DNS : a) vérifiez qu’il n’existe aucun « dangling DNS », b) repérez les éventuelles délégations par CNAME (qui peuvent utiliser leur propre politique CAA).

Comme nous l’avons vu, la Certificate Transparency a révolutionné la surveillance des activités des autorités de certification. L’exercice n’est toutefois pas exempt de défis :

• Il reste possible de publier des certificats publics hors CT, comme exposé plus haut.
• Le monitoring CT demeure rare. Même s’il est obligatoire depuis plusieurs années, la plupart des organisations n’allouent encore que peu de ressources à la surveillance de l’émission de certificats pour leurs propriétés.
• Il est difficile de distinguer le signal du bruit. Les certificats contiennent rarement assez d’informations pour différencier une émission légitime d’une émission frauduleuse. Il faut donc des outils de surveillance perfectionnés, que peu d’organisations connaissent aujourd’hui.

Même si notre objectif est de montrer le meilleur de la technique, nous reconnaissons que toutes les organisations n’ont pas besoin d’un niveau de sécurité maximal. Même celles qui en ont besoin n’en bénéficient pas forcément sur l’ensemble de leurs domaines et sites web.

Nous vous recommandons de segmenter vos propriétés selon leur profil de risque :

• Très faible risque : placez ici tout domaine inutilisé ou « parké ». Selon la taille de l’organisation, leur nombre peut varier de quelques-uns à plusieurs centaines. Sauf si vous avez automatisé toute votre configuration DNS, il n’est sans doute pas pertinent de renforcer significativement la sécurité sur ce groupe.
• Faible risque : tout domaine hébergeant un site web ou une application. Il s’agit du cas par défaut. Pour ce groupe, déployez une simple politique CAA restreignant l’émission à quelques CAs partenaires, comme décrit plus haut. Le risque d’attaque étant bas, la CAA sert surtout à appliquer votre politique de choix de CAs.
• Risque élevé : tous les domaines susceptibles d’attirer de véritables attaques (sites ou applis traitant d’argent, gouvernements, communications sensibles, etc). Protégez ce groupe avec toutes les mesures techniques disponibles.

La surveillance CT à haut niveau d’assurance consiste à surveiller avec un haut degré de certitude le flux des certificats publiés via Certificate Transparency, pour distinguer ceux sous votre contrôle des certificats émis à l’insu de tiers non autorisés.

Le principe est simple : identifier ce qui est « bon », tout le reste étant par conséquent suspect :

1. Maintenir un inventaire de tous les certificats dont vous avez le contrôle
2. Surveiller les flux CT pour repérer tout certificat non connu

Voilà. Deux étapes seulement, mais la première peut nécessiter un travail conséquent selon vos outils et votre organisation. Cela ne concerne donc que vos domaines les plus sensibles, pas l’ensemble de votre parc.

• Si vous utilisez un outil de gestion de cycle de vie de certificats (CLM) ou ACME avec une CA commerciale, l’inventaire est souvent intégré. Il suffira généralement d’utiliser leur API pour extraire la liste de vos certificats.
• Si vous utilisez ACME avec une CA gratuite (par exemple Let’s Encrypt), l’inventaire n’est parfois pas intégré. Il faudra alors mettre en place un mécanisme pour centraliser les certificats émis. Cela sera plus facile si tout passe par un serveur unique, mais reste faisable avec plusieurs serveurs.

Dans la pratique, il sera souvent nécessaire de tenir une base de données séparée pour répertorier vos certificats. La centralisation de l’émission est rare, surtout à grande échelle. Il existe toujours des exceptions, y compris des délégations à des tiers. La solution globale devra donc s’intégrer à plusieurs sources de données pour une vision complète.