Ressources · 01
Guide OSINT : produire une analyse fiable pour décider
Une méthode en six étapes pour passer de sources ouvertes dispersées à une note traçable, nuancée et directement exploitable.
· 16 min
Ce que ce guide permet
- Réduire la collecte sans objectif
- Éviter de confondre répétition et corroboration
- Rendre les incertitudes visibles
- Produire une recommandation liée à la décision
Contrôle express
- La question tient-elle en une phrase ?
- La date limite de validité est-elle définie ?
- Deux sources sont-elles réellement indépendantes ?
- Une information personnelle est-elle nécessaire au raisonnement ?
- Le lecteur sait-il ce qui changerait la conclusion ?
Méthode pas à pas
- 01
Cadrer la décision
Formulez la décision à éclairer, son propriétaire, l’échéance et le coût probable d’une erreur. Une bonne question limite le champ sans imposer la conclusion.
Livrable : brief d’une page.
- 02
Construire un plan de collecte
Découpez la question en sous-hypothèses et associez à chacune les sources susceptibles de confirmer, nuancer ou réfuter. Définissez aussi un critère d’arrêt.
Livrable : tableau hypothèse, source, statut.
- 03
Tracer la provenance
Conservez l’URL ou la référence primaire, l’auteur, la date de publication, la date de consultation et une copie conforme lorsque cela est licite.
Livrable : journal de sources.
- 04
Évaluer sans sur-noter
Notez séparément la fiabilité de la source et la crédibilité de l’information. Un acteur compétent peut défendre un intérêt ; une source inconnue peut publier un document authentique.
Livrable : grille de confiance.
- 05
Corroborer et contredire
Cherchez une origine indépendante et tentez activement de réfuter l’hypothèse dominante. Plusieurs reprises d’une même dépêche ne constituent qu’une seule origine.
Livrable : matrice de corroboration.
- 06
Restituer pour l’action
Ouvrez par la réponse courte, puis les faits décisifs, les limites, les scénarios et la prochaine action. Placez les détails de collecte en annexe.
Livrable : note décisionnelle et annexes.
Exemple d’application
Situation illustrative
Une direction doit décider si un signal public sur un partenaire justifie une vérification renforcée. L’équipe sépare le document original, ses reprises et les commentaires, date chaque pièce et note ce qui reste inconnu.
Décision et preuve attendue
Le dossier indique les deux faits qui changeraient la décision, le niveau de confiance de chaque conclusion et la date à laquelle refaire la recherche.
Indicateurs de pilotage
| Indicateur | Ce qu’il mesure | Première action |
|---|---|---|
| Couverture | Part des sous-questions disposant d’au moins une source pertinente | Rechercher les angles non couverts avant d’ajouter des sources similaires |
| Indépendance | Part des affirmations clés corroborées par des origines distinctes | Remonter à la source primaire de chaque reprise |
| Fraîcheur | Âge des preuves par rapport au rythme de changement du sujet | Définir une date d’expiration par conclusion |
| Traçabilité | Part des affirmations clés reliées à une référence vérifiable | Ajouter une note de source au moment de la collecte |
Erreurs fréquentes
- Collecter avant d’avoir formulé la décision
- Citer un agrégateur à la place de la source primaire
- Transformer une absence de preuve en preuve d’absence
- Masquer les contradictions pour simplifier la conclusion
Questions fréquentes
Quelle différence entre OSINT et simple recherche web ?
L’OSINT ajoute un objectif, une méthode de collecte, une traçabilité, une qualification des sources et une restitution proportionnée au risque de décision.
Combien de sources faut-il ?
Il n’existe pas de nombre universel. Cherchez surtout des origines indépendantes et une couverture suffisante des affirmations qui peuvent changer la décision.
Peut-on automatiser la collecte ?
Oui pour repérer, normaliser et surveiller. La portée, la licéité, l’identité des sources, les contradictions et la conclusion exigent un contrôle humain explicite.
OSINT : origines, reprises et corroboration
OSINT : cinq documents ne font pas cinq origines
La quantité de reprises d’une affirmation ne décrit pas son indépendance. Pour la question examinée, remontez de chaque document à l’observation ou à l’acquisition qui l’alimente. Le graphe suivant est fictif ; ses liens sont fournis pour l’exercice, pas inférés automatiquement.
| Document fictif | Lien documentaire fourni | Ce que le lecteur peut retenir |
|---|---|---|
| A · Publication d’un premier capteur | Acquisition A, conservée pour l’exercice. | Première chaîne d’origine déclarée ; l’exactitude du capteur reste une question distincte. |
| B · Article reprenant A | B cite explicitement A, sans nouvelle acquisition. | Une reprise supplémentaire, pas une observation indépendante supplémentaire. |
| C · Fil reprenant B | C reprend B, qui dépend de A. | Une deuxième reprise reste rattachée à la même origine A. |
| D · Journal d’un second capteur | Acquisition D distincte dans les données fictives. | Deuxième chaîne documentée dans l’exercice ; vérifier ses conditions de collecte avant corroboration. |
| E · Capture sans référence | Aucune origine établie dans le jeu fourni. | Une origine inconnue ne doit être comptée ni comme indépendante ni comme fausse par défaut. |
Lecture de cet exemple : cinq documents, deux chaînes d’origine documentées (A et D) et une origine indéterminée (E). Ce décompte n’est ni un score de crédibilité, ni une preuve que deux observations confirment la même affirmation.
Quatre questions qui peuvent changer la conclusion
- Les documents portent-ils réellement sur la même affirmation, la même période et le même objet ?
- Les acquisitions sont-elles distinctes, ou partagent-elles une source, un instrument, une erreur ou un biais ?
- Quelles hypothèses relient l’observation à la conclusion et quelle information les contredirait ?
- Quelle copie, quelle date de collecte et quel lien précis permettent à un autre analyste de refaire le rapprochement ?
ICD 203 demande notamment de décrire la qualité des sources, d’exprimer l’incertitude, de distinguer informations et jugements et d’examiner des alternatives. Nous retenons ces repères méthodologiques pour cet exercice ; il ne s’agit ni d’un produit officiel de renseignement ni d’un agrément.
ODNI · ICD 203, Analytic Standards · D.6.e(1)–(4) · Références consultées le
Indicateurs STIX et partage TLP
Qualifier la source avant d’exploiter un indicateur
Un renseignement structuré conserve une provenance et une histoire de versions. Pour une note OSINT exploitable, séparer les faits collectés, l’assertion du producteur et la conclusion locale ; expliciter ensuite ce qui reste à confirmer.
- Distinguer le créateur déclaré de l’objet et le service qui l’a relayé.
- Comparer les versions, la fenêtre de validité et une éventuelle révocation avant de réutiliser un ancien indicateur.
- Présenter la confiance du producteur comme une appréciation contextualisée, avec ses limites et les recoupements indépendants disponibles.
Consulter la fiche STIX, observations et partage TLP →
Sources vérifiées le · OASIS · STIX 2.1
OSINT : preuves et conservation
Relier la source, les octets conservés et chaque manipulation
Une enquête OSINT exploitable conserve davantage qu’un lien et une capture d’écran. Elle relie un élément collecté à son contexte, aux personnes ou rôles qui l’ont manipulé et aux transformations utilisées pour l’analyse. Le dossier doit permettre de distinguer observation, copie technique, version expurgée et conclusion analytique.
Cette méthode éditoriale adapte des principes de conservation du NIST à une revue organisationnelle de sources et de fichiers. NIST IR 8387 vise d’abord les professionnels de la gestion des preuves ; SP 800-86 traite la forensic informatique dans la réponse à incident. Les champs et les scénarios ci-dessous sont des exemples locaux, pas un formulaire NIST, une certification ou une garantie de recevabilité.
Cinq questions que le dossier doit séparer
| Question | Ce qui aide à répondre | Limite à garder visible |
|---|---|---|
| Intégrité des octets | Comparer une empreinte calculée à une référence protégée, pour un objet et un périmètre précis. | Une correspondance ne nomme ni l’auteur ni le premier détenteur. Une référence réécrite avec le fichier ne protège plus la comparaison. |
| Origine et contexte | Noter la source déclarée, le mode de collecte, les identifiants utiles et les conditions d’observation. | Un nom de fichier, un titre ou un domaine visible dans une image ne prouve pas à lui seul la provenance. |
| Continuité de possession | Relier les remises, réceptions, accès et actions à des rôles identifiables et à leurs heures. | Une empreinte inchangée ne remplit pas les périodes ou transferts non documentés. |
| Transformation et filiation | Attribuer un nouvel identifiant à un extrait, une transcription ou une version expurgée ; conserver le lien vers son parent. | Une version dérivée peut avoir une empreinte différente sans constituer une altération clandestine de l’objet préservé. |
| Interprétation analytique | Citer les éléments utilisés, les hypothèses, les alternatives et les limites de couverture. | Des octets intacts peuvent contenir une information fausse, partielle ou sortie de son contexte. |
Dix champs pour préparer une fiche de conservation
| Champ proposé | Contenu utile | Contrôle de revue |
|---|---|---|
| Identifiant et périmètre | Dossier, objet, version, type de collecte et lien avec les autres éléments. | L’identifiant désigne un objet précis, sans confondre fichier, archive complète et extrait. |
| Source observée | URL ou système, identifiant de publication, fournisseur et contexte d’accès autorisé. | Distinguer source déclarée, observation directe et source recopiée par un tiers. |
| Date et horloge | Heure brute, fuseau ou décalage connu, heure de collecte et éventuelle normalisation. | Conserver l’incertitude d’horloge ; ne pas inventer un ordre entre événements mal datés. |
| Mode de collecte | Outil, version, paramètres utiles et opérateur ou rôle responsable. | Rendre la procédure compréhensible ; un export logique n’est pas automatiquement une image complète de support. |
| Empreinte de référence | Algorithme, valeur, nombre d’octets et périmètre exact des données hachées. | Conserver la référence dans un emplacement protégé contre les modifications conjointes avec l’objet. |
| Emplacement et accès | Référence de stockage interne, niveau d’accès, responsable et historique utile. | Vérifier qui peut lire, modifier, remplacer ou supprimer, y compris la trace de référence. |
| Remise et réception | Émetteur, destinataire, heure, objet, motif et accusé de réception. | Une remise déclarée reste distincte d’une réception confirmée. |
| Copies et dérivés | Parent, nouvel identifiant, transformation, outil et empreinte de chaque résultat. | Préserver l’objet de référence et préciser ce qui a été retiré ou transformé. |
| Incidents de conservation | Écart d’empreinte, accès inexpliqué, transfert manquant et action de traitement. | Conserver l’écart observé ; ne pas remplacer silencieusement la référence pour rendre le contrôle vert. |
| Usage et conservation | Finalité de l’analyse, destinataires prévus, règle de conservation et point de révision. | Adapter les accès et la durée au dossier ; aucune durée universelle n’est déduite de cet exemple. |
Trois objets et deux contenus binaires dans l’exercice
Les trois objets sont inventés. Les empreintes ci-dessous sont calculées sur leurs chaînes UTF-8 exactes, avec un saut de ligne LF après chaque ligne, y compris la dernière. E01 et E02 ont un contenu identique ; D01 constitue un nouveau contenu documenté.
| Objet / parent | Rôle dans le scénario | Taille UTF-8 et SHA-256 |
|---|---|---|
| E01 | Objet capturé fictif ; aucun parent dans ce dossier. | 72 octets · SHA-256: 26b8f611a7e9a53474ffc21f3e7b7be89ca1bb8cf69f85f526171e9b91eee963 |
| E02 ← E01 | Copie exacte de E01 destinée à la revue technique. | 72 octets · SHA-256: 26b8f611a7e9a53474ffc21f3e7b7be89ca1bb8cf69f85f526171e9b91eee963 |
| D01 ← E02 | Version de E02 où la source textuelle a été remplacée par [redacted]. | 51 octets · SHA-256: 98fd0d2daa0e77e87bfe1f497150a5c8cde80dc5d6b4a14489caacdc54f7f2cc |
Voir les chaînes exactes utilisées pour calculer les empreintes
| Objet | Chaîne JSON représentant les octets UTF-8 |
|---|---|
| E01 | "CASE-TRAINING-07\nstatus=observed\nsource=https://public.example/report/7\n" |
| E02 | "CASE-TRAINING-07\nstatus=observed\nsource=https://public.example/report/7\n" |
| D01 | "CASE-TRAINING-07\nstatus=observed\nsource=[redacted]\n" |
Le SHA-256 porte ici sur le contenu textuel uniquement : il ne couvre pas le nom du fichier, son chemin, ses droits ou les dates du système de fichiers. Une égalité d’empreintes ne suffit donc pas à prouver une identité de métadonnées, une origine ou une date de création.
Sept traces dans une chaîne de possession fictive
Toutes les heures de ce scénario sont UTC, au 22 octobre 2026. Les rôles A à D sont fictifs. Les horodatages expriment les faits consignés dans l’exercice ; ils ne sont pas des jetons d’horodatage qualifiés ou des signatures numériques.
| Heure UTC / objet | Rôle et action | Résultat documenté |
|---|---|---|
| 10:00:00 · E01 | Collecteur A : enregistrer la capture et son contexte. | Empreinte initiale et référence de collecte conservées dans le scénario. |
| 10:02:00 · E01 | Dépositaire B : confirmer la réception dans le stockage de conservation. | Réception et référence protégée enregistrées ; conservation distincte de l’espace de travail. |
| 10:05:00 · E02 | Analyste C : créer une copie de travail de E01. | Taille et empreinte comparées à E01 ; lien parent conservé. |
| 10:08:00 · E02 | Analyste C : déclarer une remise à la revue contrôlée. | Remise enregistrée ; réception encore en attente à cet instant. |
| 10:09:00 · E02 | Relecteur D : accuser réception et contrôler la copie. | Accusé relié à la remise précédente ; comparaison de contenu consignée. |
| 10:15:00 · D01 | Analyste C : produire un dérivé expurgé de E02. | Nouvel identifiant, transformation et empreinte de D01 enregistrés ; E01 et E02 préservés. |
| 10:20:00 · D01 | Relecteur D : examiner le périmètre de diffusion. | Revue de l’expurgation consignée ; aucune publication réelle effectuée par cet exemple. |
Un journal ne devient pas infalsifiable parce qu’il contient des empreintes. Le stockage, l’authentification individuelle, les droits et la protection des références doivent être vérifiés séparément. Une lacune se signale comme telle ; une heure plausible ajoutée après coup ne la répare pas.
Huit situations où limiter correctement la conclusion
01 · Copie identique, origine encore non corroborée
Constat fictif : E01 et E02 ont la même taille et le même SHA-256 ; la source déclarée de E01 n’a pas été corroborée.
Conclusion limitée : la comparaison est cohérente avec une copie binaire identique. Elle ne prouve pas que l’auteur ou l’origine déclarés sont exacts. Prochaine preuve : contexte de collecte et corroboration indépendante.
02 · Première empreinte calculée après une modification
Constat fictif : le premier digest disponible a été produit après une retouche dont l’étendue n’est pas connue.
Conclusion limitée : cette référence décrit la version hachée à cet instant. Elle ne démontre pas l’absence de modification avant ce calcul. Conserver cette limite et rechercher une copie antérieure documentée.
03 · Fichier et référence remplacés ensemble
Constat fictif : un même compte peut remplacer l’objet et écraser sa référence de contrôle sans trace indépendante.
Conclusion limitée : le contrôle peut devenir auto-cohérent après altération. Préserver des références protégées et examiner droits et journaux ; ne pas présenter la seule comparaison comme preuve suffisante.
04 · Dérivé expurgé avec une nouvelle empreinte
Constat fictif : D01 retire la source textuelle et possède une autre empreinte que E02. La transformation est documentée.
Conclusion limitée : la différence est attendue pour ce dérivé ; elle ne doit pas être masquée. Vérifier filiation, contenu retiré et adéquation de la diffusion. Une simple mention expurgé ne prouve pas l’absence de données résiduelles.
05 · Écart d’empreinte sur une copie annoncée exacte
Constat fictif : une copie annoncée exacte ne correspond pas à l’empreinte de référence attendue.
Conclusion limitée : la comparaison échoue pour le périmètre haché. Isoler la copie de travail, préserver l’observation et analyser la cause ; ne pas attribuer automatiquement une intention malveillante ni écraser la référence.
06 · Remise déclarée sans accusé de réception
Constat fictif : le registre indique une remise à 10:08 mais aucune réception confirmée n’est disponible.
Conclusion limitée : la remise est déclarée, la réception reste non établie. Une empreinte inchangée n’identifie pas le détenteur pendant l’intervalle. Rechercher les traces de réception et signaler la lacune.
07 · Fuseau inconnu dans une chronologie
Constat fictif : deux journaux indiquent 10:05 et 10:07, mais le fuseau et le décalage d’une horloge sont inconnus.
Conclusion limitée : conserver les heures brutes et l’incertitude ; ne pas déduire une causalité de cet ordre apparent. Toute normalisation doit rester reliée à une hypothèse explicite et révisable.
08 · Capture d’écran sans couverture de la source
Constat fictif : une capture d’écran est intacte, mais ne montre ni l’intégralité de la publication ni les conditions d’affichage.
Conclusion limitée : elle conserve une vue observée, pas nécessairement toute la source. Consigner ce qui est visible, ce qui manque et les éventuelles versions dynamiques ; distinguer fidélité de la capture et véracité du contenu.
Six vérifications avant de remettre une synthèse
- Chaque affirmation importante renvoie à un objet identifié et à son périmètre de collecte.
- Les empreintes sont associées à leur algorithme, à leurs octets exacts et à une référence protégée.
- Les copies de travail et les dérivés gardent leurs parents, versions et transformations.
- Les remises et réceptions sont distinguées ; les lacunes et heures incertaines restent visibles.
- La diffusion utilise les versions prévues et une revue des informations retirées ou encore présentes.
- La synthèse sépare observation, interprétation, hypothèse et conclusion non démontrée.
Les numéros de champs, les trois objets et les sept traces sont une construction pédagogique locale. Les éditions des documents et leurs périmètres sont indiqués pour éviter de les présenter comme une procédure judiciaire universelle.
Sources primaires et adaptation de la méthode
- NIST · Digital Evidence Preservation · NIST IR 8387 · September 2022
Preservation scope and publication record - NIST IR 8387 · Full report · September 2022 · reviewed 2026-10-22
§3.2 · printed pp. 7–11: custody, copies, storage and protection of reference hashes - NIST · SP 800-86 · August 2006 · IT forensics guidance
Scope: integration of forensic techniques into incident response - NIST SP 800-86 · Full report · August 2006 · reviewed 2026-10-22
§3.1 · printed pp. 3-2–3-5: acquire, verify and document custody - NIST · FIPS 180-4 · Secure Hash Standard · August 2015 · revision planning note dated 2023-03-07
Hash algorithms and message-change detection; a digest is not proof of origin
Sources vérifiées le
PDF : expurgation et diffusion
Expurger la synthèse sans remplacer les sources conservées
Une version partageable et une référence de travail ne servent pas le même usage. Conservez leur filiation et contrôlez l’information visible, le contenu caché et les destinataires de la copie dérivée.
- Attribuer un identifiant à la copie expurgée et garder son lien vers le parent.
- Ne pas recopier les valeurs retirées dans un ticket ou une capture largement accessible.
- Tester le fichier finalement remis, y compris sa couche texte et ses pièces jointes.
Voir les surfaces et la matrice de revue avant partage →
Sources vérifiées le · Adobe · Redacting and sanitizing PDFs · Adobe · Redact sensitive content · Adobe · Sanitize PDFs · ICO · Avoid accidental breaches when redacting · ICO · Hidden information in documents · Microsoft · Document Inspector
Chronologies : UTC et fuseaux
La date affichée ne suffit pas à ordonner des sources
Une collecte peut répéter une heure locale ou recevoir tardivement une publication. Le texte d’origine, le décalage, le fuseau et l’observation doivent rester traçables avant de construire une chronologie OSINT.
- Demander une clarification lorsqu’une heure locale correspond à deux instants.
- Garder la version des règles de fuseau utilisée pour la conversion.
- Séparer l’ordre temporel calculé, la qualité des horloges et l’interprétation causale.
Lire les 12 cas et les trois états datés →
Sources relues le · IETF · RFC 3339 · Python · PEP 495 · Python 3.12 · zoneinfo · IANA · Time Zone Database 2026e · IANA · 2026e Europe rules · OpenTelemetry · Logs Data Model
Repères IANA et lecture DNSSEC
Une preuve DNS ne suffit pas à attribuer un site
Une réponse DNS authentifiée renseigne sur les données d’une zone dans une chaîne de confiance. Elle n’identifie pas, à elle seule, l’organisation qui décide du contenu publié.
- Conserver nom interrogé, type, heure, résolveur et réponse observée.
- Séparer données d’enregistrement RDAP, hébergement, publication DNS et contenu éditorial.
- Rapprocher les indices indépendants et conserver les points encore indéterminés.
Lire les registres et essayer le modèle de cache →
IETF · RFC 4033 · §3–5 · 2026-10-23
Certificats TLS et renseignement ouvert
Certificate Transparency (CT) rend observables des certificats et précertificats TLS dans des journaux publics. Pour l’OSINT et l’analyse de surface d’exposition, c’est une piste documentaire à recouper : une trace de certificat ne démontre ni un service actif, ni la maîtrise actuelle du domaine, ni l’identité de son éditeur.
Instantané documentaire de la liste Chrome, version 96.2, généré le 5 novembre 2026 à 13:36:08 UTC et contrôlé le 6 novembre 2026. Périmètre : log_list.json uniquement, et non tous les journaux CT existants. Les états et interfaces décrivent cette édition ; aucun contrôle réseau des journaux n’est réalisé ici.
Quatre objets à ne pas confondre
| Objet | Ce qu’il permet d’examiner | Ce qu’il ne suffit pas à établir |
|---|---|---|
| Certificat / précertificat | Noms déclarés, émetteur, clé publique, période de validité ; un précertificat est un objet distinct. | Déploiement sur un serveur, résolution DNS actuelle ou identité juridique du responsable. |
| SCT · Signed Certificate Timestamp | Engagement signé d’un journal à intégrer l’entrée dans son délai MMD. | Présence déjà démontrée dans un arbre : une promesse d’intégration n’est pas une preuve d’inclusion. |
| STH + preuve d’inclusion | Rattachement d’une feuille à la racine d’un arbre de taille donnée, après vérification cryptographique. | Cohérence de toutes les versions du journal ou validité TLS actuelle du certificat. |
| Preuve de cohérence | Relation entre deux états d’un même arbre : le second prolonge le premier sans modifier les anciennes entrées. | Absence mondiale de vues divergentes ; les observations doivent aussi être comparées entre observateurs. |
IETF · RFC 6962 · Certificate Transparency · June 2013 · Experimental · §§2.1, 3, 5.4, 7
Deux familles d’interfaces dans l’instantané
Les entrées « logs » de la source correspondent à RFC 6962 ; les « tiled_logs » à static-ct-api. Cette dernière sépare un préfixe de soumission et un préfixe de lecture par ressources statiques, tout en produisant des SCT selon RFC 6962. Elle n’est pas synonyme de CT v2. La RFC 9162 décrit la version 2.0 et remplace la RFC 6962 comme document ; cela ne transforme pas automatiquement les interfaces déployées en v2.
C2SP · Static Certificate Transparency API · v1.1.0
IETF · RFC 9162 · Certificate Transparency Version 2.0 · December 2021 · Experimental · obsoletes RFC 6962
Lire les champs sans changer leur sens
| Champ de la source | Lecture correcte | Piège d’analyse |
|---|---|---|
| log_id | SHA-256 de la clé publique DER SubjectPublicKeyInfo, encodé en base64. | Le nom commercial du journal ne remplace pas cet identifiant cryptographique. |
| state + timestamp | État du journal selon le distributeur et instant d’entrée dans cet état. | Cet instant n’est pas la date d’émission d’un certificat. |
| mmd | Délai maximal d’intégration déclaré, en secondes. | Ce n’est ni une disponibilité mesurée, ni la durée de validité d’un certificat. |
| temporal_interval | Intervalle des dates d’expiration NotAfter acceptées : début inclus, fin exclue. | Il ne décrit pas la durée d’activité du journal. |
| url / monitoring_url / submission_url | Préfixes d’interfaces du journal, conservés selon leur rôle. | Un préfixe de lecture statique n’est pas une API RFC 6962 get-entries. |
Google Chrome · Log list schema v3 · Schema v3 checked against signed snapshot 96.2 · 2026-11-06
Comprendre les quatre états présents
| État à la date de la liste | Interprétation documentaire |
|---|---|
| usable | Journal utilisable dans le cycle de vie décrit par Chrome ; ce libellé ne constitue pas une mesure de santé effectuée par CIE. |
| qualified | Journal admis après sa phase de contrôle initiale ; sa reconnaissance se diffuse dans les versions des clients. |
| readonly | Le journal cesse d’émettre de nouveaux SCT ; une taille finale et une racine d’arbre sont publiées dans la source. |
| retired | Le journal n’est plus utilisé pour créer de nouveaux SCT. L’analyse d’anciens SCT dépend notamment de leurs dates et de la politique du client. |
D’autres états existent, dont pending et rejected, mais ils sont absents de cet instantané. Ce tableau explique les libellés ; il ne calcule pas la conformité d’un certificat à la politique d’un navigateur.
Google Chrome · CT Log Lifecycle · Consulted 2026-10-23
Explorer les 89 journaux de la liste datée
Les filtres s’appliquent uniquement à l’instantané local. Sans JavaScript, les 89 lignes restent consultables. Les compteurs globaux conservent le périmètre complet ; le résultat filtré possède son propre compteur. Les préfixes sont affichés comme données documentaires, sans interrogation automatique. Le tableau dispose de son propre défilement vertical et horizontal, accessible au clavier.
- Journaux dans l’instantané
- 89
- Opérateurs
- 11
- usable
- 43
- readonly
- 2
- qualified
- 41
- retired
- 3
- RFC 6962
- 26
- static-ct-api
- 63
Journaux affichés : 89 / 89
Aucun journal ne correspond à ces critères.
| Journal et LogID | Opérateur | État à la date de la liste | MMD (s) | NotAfter accepté · UTC | Interface et préfixes |
|---|---|---|---|---|---|
Google Argon2026h2Détails techniquesLogID: | usable | 86400 |
| RFC 6962Détails techniquesurl: | |
Google Argon2027h1Détails techniquesLogID: | usable | 86400 |
| RFC 6962Détails techniquesurl: | |
Google Xenon2026h2Détails techniquesLogID: | usable | 86400 |
| RFC 6962Détails techniquesurl: | |
Google Xenon2027h1Détails techniquesLogID: | usable | 86400 |
| RFC 6962Détails techniquesurl: | |
Google ParcelYard2026h2Détails techniquesLogID: | usable | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: | |
Google ParcelYard2027h1Détails techniquesLogID: | usable | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: | |
Google ParcelYard2027h2Détails techniquesLogID: | usable | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: | |
Google PlumbersArms2026h2Détails techniquesLogID: | usable | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: | |
Google PlumbersArms2027h1Détails techniquesLogID: | usable | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: | |
Google PlumbersArms2027h2Détails techniquesLogID: | usable | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: | |
Cloudflare Nimbus2026Détails techniquesLogID: | Cloudflare | usable | 86400 |
| RFC 6962Détails techniquesurl: |
Cloudflare Nimbus2027Détails techniquesLogID: | Cloudflare | usable | 86400 |
| RFC 6962Détails techniquesurl: |
DigiCert Wyvern2026h2Détails techniquesLogID: | DigiCert | usable | 86400 |
| RFC 6962Détails techniquesurl: |
DigiCert Wyvern2027h1Détails techniquesLogID: | DigiCert | usable | 86400 |
| RFC 6962Détails techniquesurl: |
DigiCert Wyvern2027h2Détails techniquesLogID: | DigiCert | usable | 86400 |
| RFC 6962Détails techniquesurl: |
DigiCert Sphinx2026h2Détails techniquesLogID: | DigiCert | usable | 86400 |
| RFC 6962Détails techniquesurl: |
DigiCert Sphinx2027h1Détails techniquesLogID: | DigiCert | usable | 86400 |
| RFC 6962Détails techniquesurl: |
DigiCert Sphinx2027h2Détails techniquesLogID: | DigiCert | usable | 86400 |
| RFC 6962Détails techniquesurl: |
Sectigo Mammoth2026h2Détails techniquesLogID: | Sectigo | readonly | 86400 |
| RFC 6962Détails techniquesurl: |
Sectigo Sabre2026h2Détails techniquesLogID: | Sectigo | readonly | 86400 |
| RFC 6962Détails techniquesurl: |
Sectigo Elephant2026h2Détails techniquesLogID: | Sectigo | usable | 86400 |
| RFC 6962Détails techniquesurl: |
Sectigo Elephant2027h1Détails techniquesLogID: | Sectigo | usable | 86400 |
| RFC 6962Détails techniquesurl: |
Sectigo Elephant2027h2Détails techniquesLogID: | Sectigo | usable | 86400 |
| RFC 6962Détails techniquesurl: |
Sectigo Tiger2026h2Détails techniquesLogID: | Sectigo | usable | 86400 |
| RFC 6962Détails techniquesurl: |
Sectigo Tiger2027h1Détails techniquesLogID: | Sectigo | usable | 86400 |
| RFC 6962Détails techniquesurl: |
Sectigo Tiger2027h2Détails techniquesLogID: | Sectigo | usable | 86400 |
| RFC 6962Détails techniquesurl: |
Sectigo Monument2027h1Détails techniquesLogID: | Sectigo | qualified | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
Sectigo Monument2027h2Détails techniquesLogID: | Sectigo | qualified | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
Sectigo Monument2028h1Détails techniquesLogID: | Sectigo | qualified | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
Sectigo Monument2028h2Détails techniquesLogID: | Sectigo | qualified | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
Sectigo Statue2027h1Détails techniquesLogID: | Sectigo | qualified | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
Sectigo Statue2027h2Détails techniquesLogID: | Sectigo | qualified | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
Sectigo Statue2028h1Détails techniquesLogID: | Sectigo | qualified | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
Sectigo Statue2028h2Détails techniquesLogID: | Sectigo | qualified | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
Let's Encrypt Oak2026h2Détails techniquesLogID: | Let's Encrypt | retired | 86400 |
| RFC 6962Détails techniquesurl: |
Let's Encrypt Sycamore2026h2Détails techniquesLogID: | Let's Encrypt | usable | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
Let's Encrypt Sycamore2027h1Détails techniquesLogID: | Let's Encrypt | usable | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
Let's Encrypt Sycamore2027h2Détails techniquesLogID: | Let's Encrypt | usable | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
Let's Encrypt Willow2026h2Détails techniquesLogID: | Let's Encrypt | usable | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
Let's Encrypt Willow2027h1Détails techniquesLogID: | Let's Encrypt | usable | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
Let's Encrypt Willow2027h2Détails techniquesLogID: | Let's Encrypt | usable | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
Let's Encrypt Sycamore2028h1Détails techniquesLogID: | Let's Encrypt | qualified | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
Let's Encrypt Sycamore2028h2Détails techniquesLogID: | Let's Encrypt | qualified | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
Let's Encrypt Willow2028h1Détails techniquesLogID: | Let's Encrypt | qualified | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
Let's Encrypt Willow2028h2Détails techniquesLogID: | Let's Encrypt | qualified | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
TrustAsia log2026aDétails techniquesLogID: | TrustAsia | usable | 86400 |
| RFC 6962Détails techniquesurl: |
TrustAsia log2026bDétails techniquesLogID: | TrustAsia | usable | 86400 |
| RFC 6962Détails techniquesurl: |
TrustAsia HETU2027Détails techniquesLogID: | TrustAsia | usable | 86400 |
| RFC 6962Détails techniquesurl: |
TrustAsia Luoshu2027Détails techniquesLogID: | TrustAsia | usable | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
TrustAsia Luoshu2028h1Détails techniquesLogID: | TrustAsia | qualified | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
TrustAsia Luoshu2028h2Détails techniquesLogID: | TrustAsia | qualified | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
TrustAsia Taiji2028h1Détails techniquesLogID: | TrustAsia | qualified | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
TrustAsia Taiji2028h2Détails techniquesLogID: | TrustAsia | qualified | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
Bogus placeholder log to unbreak misbehaving CT librariesDétails techniquesLogID: | Geomys | retired | 86400 |
| RFC 6962Détails techniquesurl: |
Geomys Tuscolo2026h2Détails techniquesLogID: | Geomys | usable | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
Geomys Tuscolo2027h1Détails techniquesLogID: | Geomys | usable | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
Geomys Tuscolo2027h2Détails techniquesLogID: | Geomys | usable | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
Geomys Tuscolo2028h1Détails techniquesLogID: | Geomys | qualified | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
Geomys Tuscolo2028h2Détails techniquesLogID: | Geomys | qualified | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
Geomys Trastevere2026h2Détails techniquesLogID: | Geomys | qualified | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
Geomys Trastevere2027h1Détails techniquesLogID: | Geomys | qualified | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
Geomys Trastevere2027h2Détails techniquesLogID: | Geomys | qualified | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
Geomys Trastevere2028h1Détails techniquesLogID: | Geomys | qualified | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
Geomys Trastevere2028h2Détails techniquesLogID: | Geomys | qualified | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
Bogus RFC6962 log to avoid breaking misbehaving CT librariesDétails techniquesLogID: | IPng Networks | retired | 86400 |
| RFC 6962Détails techniquesurl: |
IPng Networks Halloumi2026h2aDétails techniquesLogID: | IPng Networks | usable | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
IPng Networks Halloumi2027h1Détails techniquesLogID: | IPng Networks | usable | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
IPng Networks Halloumi2027h2Détails techniquesLogID: | IPng Networks | usable | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
IPng Networks Gouda2026h2Détails techniquesLogID: | IPng Networks | usable | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
IPng Networks Gouda2027h1Détails techniquesLogID: | IPng Networks | usable | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
IPng Networks Gouda2027h2Détails techniquesLogID: | IPng Networks | usable | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
IPng Networks Gouda2028h1Détails techniquesLogID: | IPng Networks | qualified | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
IPng Networks Gouda2028h2Détails techniquesLogID: | IPng Networks | qualified | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
IPng Networks Halloumi2028h1Détails techniquesLogID: | IPng Networks | qualified | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
IPng Networks Halloumi2028h2Détails techniquesLogID: | IPng Networks | qualified | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
Microsec Eszigno2026h2Détails techniquesLogID: | Microsec | qualified | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
Microsec Eszigno2027h1Détails techniquesLogID: | Microsec | qualified | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
Microsec Eszigno2027h2Détails techniquesLogID: | Microsec | qualified | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
Microsec Eszigno2028h1Détails techniquesLogID: | Microsec | qualified | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
Microsec Eszigno2028h2Détails techniquesLogID: | Microsec | qualified | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
GoDaddy Aquamarine2026h2Détails techniquesLogID: | GoDaddy | qualified | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
GoDaddy Aquamarine2027h1Détails techniquesLogID: | GoDaddy | qualified | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
GoDaddy Aquamarine2027h2Détails techniquesLogID: | GoDaddy | qualified | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
GoDaddy Aquamarine2028h1Détails techniquesLogID: | GoDaddy | qualified | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
GoDaddy Aquamarine2028h2Détails techniquesLogID: | GoDaddy | qualified | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
HARICA Selene2027h1Détails techniquesLogID: | HARICA | qualified | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
HARICA Selene2027h2Détails techniquesLogID: | HARICA | qualified | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
HARICA Selene2028h1Détails techniquesLogID: | HARICA | qualified | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
HARICA Selene2028h2Détails techniquesLogID: | HARICA | qualified | 60 |
| static-ct-apiDétails techniquessubmission_url: monitoring_url: |
Provenance et contrôles du fichier source
Contrôles du fichier source : schéma JSON v3 validé ; signature détachée vérifiée avec la clé RSA 4096 bits publiée par Google, RSASSA-PKCS1-v1_5 / SHA-256 ; les 89 LogID rapprochés du SHA-256 des clés DER. Ces contrôles portent sur la liste téléchargée, pas sur les signatures des certificats ou SCT, les preuves d’inclusion ou l’état actuel des services.
- Source JSON SHA-256
e7930ddd50db8f2f99ad43a331fef94cd76234b1dde6a589b77a446d9783fa17- Public key PEM SHA-256
a284e4ad744211a6636a03c59aca9446ecd5ff2c14d7cb6edd69f7ba2108bf95
Cas d’enquête : transformer un signal en question
| Observation fictive | Contrôle à préparer | Conclusion proportionnée |
|---|---|---|
| Un nom apparaît dans les SAN d’un certificat | Relever le nom exact, l’émetteur, le numéro de série, les dates et la source. Vérifier séparément les observations DNS et TLS autorisées et datées. | « Nom présent dans un certificat observé », sans conclure que le serveur existe encore. |
| Le même certificat apparaît dans plusieurs journaux | Rapprocher l’objet exact par son empreinte et distinguer les occurrences de journalisation. Séparer certificat final, précertificat et renouvellements. | Plusieurs occurrences ne sont pas plusieurs services ni plusieurs compromissions. |
| Un certificat contient *.example.org | Conserver le caractère générique comme tel. Ne pas fabriquer des noms d’hôtes à partir de cette seule entrée. | Le motif n’énumère pas les sous-domaines réellement déployés. |
| Une recherche ne retourne aucun résultat | Documenter l’outil, les journaux couverts, la requête, l’instant et les éventuels délais de collecte. | Absence de résultat dans ce périmètre, sans affirmer l’absence de certificat ou d’actif. |
| Un SCT est daté de 12:00 UTC, avec MMD = 60 s | L’échéance théorique d’intégration est 12:01 UTC. Pour examiner la promesse, utiliser les objets et preuves du journal appropriés. | Un résultat de recherche manquant à 12:00:30 ne démontre pas un dépassement du MMD. |
Google Chrome · Certificate Transparency for Site Operators · Domain Privacy · consulted 2026-10-23
IETF · RFC 5280 · X.509 certificate profile · May 2008 · §§4.1.2.5, 4.2.1.6, 6
Une trace exploitable dans une note de renseignement
- Délimiter la collecte
Noter domaine ou motif, source primaire ou agrégateur, heure UTC et périmètre. Une source de recherche peut avoir sa propre couverture et son propre retard.
- Conserver l’objet et son contexte
Distinguer certificat, précertificat, SCT et preuve. Associer empreinte de l’objet, LogID, index ou taille d’arbre lorsque disponibles, et moment de consultation.
- Recouper les couches
Rapprocher données d’enregistrement, DNS, TLS et contenu web avec leurs dates respectives. Une infrastructure partagée peut expliquer des relations techniques sans lien organisationnel.
- Exprimer l’incertitude
Écrire ce qui est observé, ce qui est déduit et ce qui reste à confirmer. Prévoir un responsable et une prochaine vérification pour toute hypothèse qui influence une décision.
Données : Google Chrome, usage documentaire d’investigation et d’audit, selon sa politique d’utilisation. L’instantané n’est pas un magasin de confiance et ne sert pas à imposer CT dans un client TLS. Les textes, tableaux d’analyse et exemples fictifs sont une synthèse éditoriale CIE ; les documents liés conservent leurs propres conditions.
Google Chrome · CT Log Lists and usage policy · Consulted 2026-11-06
RDAP : enregistrement, rôles et données masquées
RDAP : qualifier le rôle avant de nommer un acteur
Le registrar, le titulaire et le contact technique répondent à des questions différentes. Une réponse d’enregistrement publique est datée et peut comporter des données non publiées.
- Lire les rôles déclarés plutôt que rapprocher seulement des noms.
- Séparer date d’enregistrement, de modification, de synchronisation et de collecte.
- Conserver les expurgations et les limites d’accès sans inventer l’identité manquante.
Ouvrir le dossier RDAP et le lecteur local →
IETF · RFC 9083 · RDAP JSON Responses · June 2021 · §§4–5, 9–10
Chaînes de reprises et veille sociale
Distinguer origine, reprise et corroboration
Une capture ou une signature de provenance peut documenter une pièce sans prouver l’affirmation qu’elle contient. Avant de citer plusieurs publications, vérifier si elles renvoient au même document.
- Conserver la version consultée et sa référence exacte.
- Nommer les citations absentes plutôt que supposer leur contenu.
- Traiter les documents distincts comme des pièces à comparer, sans présumer leur indépendance.
Lire la méthode et explorer les chaînes de reprises →
Government Communications · RESIST 3 · RESIST 3 · 2025 · consulted 2026-10-23
Government Communications · RESIST 3 quick reference · RESIST 3 · 2025 · consulted 2026-10-23
Références officielles
Date de consultation des références : . La méthode et la fiche de travail proposent des contrôles à adapter à votre contexte ; elles ne constituent pas une certification.
- OHCHR — Berkeley Protocol on Digital Open Source Investigations
- OECD — Due Diligence Guidance for Responsible Business Conduct
- ODNI · ICD 203, Analytic Standards
- NIST · Digital Evidence Preservation
- NIST IR 8387 · Full report
- NIST · SP 800-86
- NIST SP 800-86 · Full report
- NIST · FIPS 180-4 · Secure Hash Standard
- Adobe · Redacting and sanitizing PDFs
- Adobe · Redact sensitive content
- Adobe · Sanitize PDFs
- ICO · Avoid accidental breaches when redacting
- ICO · Hidden information in documents
- Microsoft · Document Inspector
- IETF · RFC 3339
- Python · PEP 495
- Python 3.12 · zoneinfo
- IANA · Time Zone Database 2026e
- IANA · 2026e Europe rules
- OpenTelemetry · Logs Data Model
- Government Communications · RESIST 3
- Government Communications · RESIST 3 quick reference
- IETF · RFC 9083 · RDAP JSON Responses
- IETF · RFC 9537 · Redacted Fields in RDAP
- IETF · RFC 6962 · Certificate Transparency
- IETF · RFC 9162 · Certificate Transparency Version 2.0
- Google Chrome · CT Log Lists and usage policy
- Google Chrome · Log list schema v3
- Google Chrome · CT Log Lifecycle
- C2SP · Static Certificate Transparency API
- Google Chrome · Certificate Transparency for Site Operators
- IETF · RFC 5280 · X.509 certificate profile
- IETF · RFC 4033 · DNSSEC introduction and requirements
- IETF · RFC 4035 · DNSSEC validation and caching
- OASIS · STIX 2.1
