L'infrastructure PKI publique et les certificats numériques offrent une base acceptable pour la plupart des propriétés internet, mais certaines comportent un risque bien plus élevé que d'autres. Des propriétés telles que votre page de connexion applicative, vos flux de paiement, vos domaines d'entreprise, et tout ce qui pourrait nuire à votre marque en cas d'usurpation, constituent des cibles de choix pour les attaquants. Ces propriétés doivent être protégées en construisant activement des défenses à l'aide de technologies telles que la Transparence des Certificats (CT) et CAA. Bien que nous ayons déjà détaillé en profondeur la CT à haute assurance, nous souhaitions nous concentrer sur les aspects pratiques de la détection des émissions non autorisées, de l'application des mécanismes de prévention disponibles, et de la configuration d'une surveillance à haute assurance avec Red Sift Certificates.
Qu'est-ce que la Transparence des Certificats ?
La Transparence des Certificats (CT) est une norme ouverte qui exige des autorités de certification (CA) publiquement approuvées qu'elles consignent chaque certificat émis dans des journaux publics auditables et en ajout seul. Ainsi, tout certificat émis pour votre domaine est visible par n'importe qui.
La CT a été conçue pour remédier à une faiblesse fondamentale de l'infrastructure PKI publique : n'importe quelle CA présente dans le magasin de confiance peut techniquement émettre un certificat pour n'importe quel domaine. Elle n'empêche pas cela, mais elle rend les émissions non autorisées détectables. Red Sift ingère et traite les journaux CT depuis 2017, constituant ainsi l'une des bases de données de découverte de certificats les plus complètes qui soient.
Les défaillances de l'infrastructure PKI publique ne sont pas théoriques ; consultez notre historique des attaques contre les infrastructures PKI publiques pour découvrir des incidents que la CT et CAA auraient permis de détecter.
Niveau 1 : Commencer par une politique CAA basique
La première ligne de défense est la prévention, et cela commence par une politique CAA (Certification Authority Authorization) DNS. Une politique CAA vous permet de déclarer quelles CA sont autorisées à émettre des certificats pour votre domaine. Sans politique, n'importe quelle CA peut émettre un certificat pour vos propriétés. Même une configuration CAA basique réduit considérablement votre surface d'attaque.
Recommandation de base : une politique CAA simple avec les paramètres de surveillance CT par défaut.
Définir une politique CAA. Configurons maintenant une politique CAA avec Red Sift Certificates. Avant de verrouiller quoi que ce soit, identifiez qui émet actuellement des certificats pour vos domaines. Sinon, un nouvel enregistrement pourrait interrompre du jour au lendemain une émission légitime. Le filtre Émetteur sur la page Certificats révèle instantanément cette information. En filtrant par exemple sur « Hostnames contient redsift.com », on obtient Let's Encrypt (114), Google Trust Services (34), Sectigo (24) et Amazon (4).


Cette liste se traduit directement en une politique CAA que vous devez configurer sur votre enregistrement DNS :
redsift.com. CAA 0 issue "letsencrypt.org" redsift.com. CAA 0 issue "pki.goog" redsift.com. CAA 0 issue "sectigo.com" redsift.com. CAA 0 issue "amazon.com" redsift.com. CAA 0 issuewild "letsencrypt.org" redsift.com. CAA 0 issuewild "pki.goog" redsift.com. CAA 0 issuewild "sectigo.com" redsift.com. CAA 0 iodef "mailto:security@redsift.com"
issue couvre les certificats classiques, et issuewild couvre les wildcards. Restreignez la liste des wildcards uniquement aux CA que vous utilisez réellement pour l'émission de wildcards ; le filtre « wildcard » dans Red Sift Certificates, combiné à un filtre « hostnames », affiche votre utilisation actuelle des wildcards. Besoin d'aide pour les domaines d'identifiant ? Vous pouvez utiliser ce générateur CAA pour trouver le domaine d'identifiant correct pour chaque CA.
Les CA sont tenues de vérifier et de respecter les enregistrements CAA avant toute émission. Si un certificat découvert enfreint votre politique CAA, Red Sift Certificates signalera le problème de configuration CAA (par exemple, un enregistrement CAA mal formé ou une propriété manquante) et vous enverra une alerte pour information.




Niveau 2 : Mettre en place la surveillance CT
CAA empêche les CA conformes d'émettre des certificats non autorisés, mais cela n'arrête pas une CA compromise ou malveillante. La surveillance CT permet de détecter ce que CAA ne peut pas empêcher.
Red Sift Certificates surveille en continu les journaux CT et crée un cas pour chaque nouveau certificat découvert correspondant à vos domaines. Chaque cas est automatiquement évalué selon un ensemble de règles de clôture et d'escalade permettant de déterminer si le certificat est légitime, inattendu, ou constitue un indicateur potentiel de compromission.
Règles de clôture
Les règles de clôture résolvent automatiquement les cas pour lesquels il existe suffisamment de preuves que le certificat est légitime :


Règles de clôture
Règle | Notes |
Le certificat est approuvé (marqué comme connu) | Déclenché lorsqu'un certificat est importé via une intégration CA ou marqué via l'API. Ces certificats sont garantis être sous votre contrôle, les cas sont donc clôturés immédiatement. |
Le certificat est installé sur vos hôtes | Confirmé via une observation active des hôtes |
Le certificat est expiré | Évite l'encombrement de la file d'attente par des certificats historiques |
Le certificat est révoqué | Clôture les cas pour les certificats révoqués par la CA émettrice et qui ne sont plus utilisables |
La politique CAA correspond à l'émetteur du certificat | Confirme que la CA était autorisée à émettre. S'applique uniquement aux noms d'hôte disposant d'un enregistrement CAA |
L'émetteur correspond à des mots-clés connus | Clôture les cas dont le nom de l'émetteur correspond à une liste de mots-clés de confiance. |
Le cas est ouvert depuis N jours sans escalade | Clôture automatiquement les cas obsolètes n'ayant déclenché aucune règle d'escalade. Recommandé : 30 jours. |
Niveau 3 : Surveillance CT à haute assurance
La surveillance CT standard signale les anomalies de manière réactive. La surveillance CT à haute assurance adopte une approche plus rigoureuse : elle constitue un inventaire complet de tous les certificats que vous possédez, puis considère par défaut comme suspect tout ce qui apparaît dans les journaux CT sans figurer dans cet inventaire.
Cela nécessite deux éléments :
- Un inventaire complet des éléments « connus et fiables ». Constitué en important des certificats via des intégrations CA ou l'API de création de certificats. Chaque certificat importé est automatiquement marqué comme approuvé (connu comme étant sous votre contrôle).
- Des règles d'escalade strictes. Configurées pour escalader tout certificat qui n'est pas pris en compte dans un court délai.


Règles d'escalade
Règle | Notes |
Certificat non approuvé sous X jours | Règle centrale de la haute assurance. Recommandé : 1 à 3 jours (la valeur par défaut est 30). Peut être limitée aux domaines à forte valeur uniquement. |
Certificat jamais observé installé sur des hôtes | Détecte les certificats émis mais jamais déployés. Recommandé : 30 jours. |
La politique CAA ne correspond pas à l'émetteur du certificat | Indique une émission en dehors de votre politique de CA autorisée. À utiliser avec prudence. |
Le certificat n'est pas conforme CT | Peut indiquer une émission non standard ou un certificat soumis en dehors des workflows CA habituels |
L'émetteur du certificat ne figure pas dans la liste des CA autorisées | Nécessite de définir une liste blanche explicite des émetteurs de confiance |
L'émetteur correspond à des mots-clés suspects | Par exemple : noms de CA inconnus, CA internes/de test, émetteurs à risque connus |
Le certificat dépasse la durée de vie maximale | Signale les violations de politique, par exemple une validité supérieure à 200 jours |
Remarque : les journaux CT présentent un délai de fusion inhérent, pouvant atteindre 24 heures pour certains journaux. Red Sift traite les certificats au fur et à mesure de leur apparition dans les journaux CT, quasiment en temps réel, mais pas instantanément.
Pour tout résumer
La Transparence des Certificats transforme un risque invisible, celui de n'importe quelle CA pouvant émettre pour n'importe quel domaine, en un signal publiquement auditable. Mais les données CT brutes sont bruyantes ; les transformer en un système d'alerte précoce fiable nécessite un inventaire des éléments connus et fiables, des règles de clôture pertinentes, et des seuils d'escalade stricts.
Red Sift Certificates réunit ces trois niveaux en un seul endroit : l'application de la politique CAA, la surveillance CT continue, et l'escalade à haute assurance, appuyées par près d'une décennie d'ingestion des journaux CT. Commencez par la base recommandée, puis renforcez les règles d'escalade sur vos domaines à plus forte valeur à mesure que votre inventaire des éléments connus et fiables se consolide.
Prêt à commencer ? Inscrivez-vous pour un essai de Red Sift Certificates Lite, ou connectez-vous pour configurer la surveillance CT à haute assurance pour vos domaines si vous disposez déjà d'un compte.
Bhushan is the leading Principal Engineer for Red Sift's Certificate products and innovation.




