Certificats TLS frauduleux sur les serveurs de jeu : comment les journaux de Certificate Transparency détectent ce que les pare-feu manquent

À l'heure actuelle, il existe un journal public, en écriture seule, de chaque certificat TLS émis pour chaque domaine sur Internet — y compris le vôtre. Si quelqu'un se présente demain devant une autorité de certification et la convainc d'émettre un certificat TLS valide pour votre API de jeu à api.yourgame.com, ce certificat apparaîtra dans les journaux de Certificate Transparency (CT) en quelques minutes. La seule question est de savoir si vous le remarquerez.

La plupart des développeurs de jeux ne le remarqueront pas. Ils l'apprennent lorsque les joueurs signalent des erreurs SSL, lorsqu'un testeur d'intrusion signale le problème, ou pire — lorsque des jetons d'authentification volés commencent à apparaître sur des marchés secondaires parce qu'un certificat malveillant a permis un proxy de type homme du milieu entre les joueurs et le endpoint de connexion.

Cet article est un runbook pour surveiller les journaux de Certificate Transparency sur les domaines de votre backend de jeu. Il explique ce que sont réellement les journaux CT, comment les interroger par programmation, comment filtrer le bruit de vos propres renouvellements de routine, et comment construire un pipeline d'alertes qui détecte les émissions de certificats non autorisées avant qu'elles ne deviennent des brèches.

Ce qui casse : l'émission non autorisée de certificats TLS contre les backends de jeu

Chaque certificat TLS émis par une autorité de certification (CA) publiquement reconnue doit être enregistré dans au moins deux journaux publics de Certificate Transparency. Cela est effectivement obligatoire depuis avril 2018, lorsque Chrome a commencé à exiger l'inclusion CT pour tous les nouveaux certificats. Apple Safari a suivi avec des exigences similaires. Tout certificat non enregistré ne sera pas reconnu par les principaux navigateurs.

L'écosystème CT existe pour détecter les émissions abusives — des situations où une CA émet un certificat pour un domaine que le demandeur ne contrôle pas. Pour les backends de jeu, le modèle de menace ressemble à ceci :

• Interception d'identifiants : un attaquant obtient un certificat valide pour auth.yourgame.com, met en place un proxy entre les joueurs et votre véritable serveur d'authentification, et récolte les jetons de connexion. Pour le joueur, la connexion semble légitime car le navigateur fait confiance au certificat.
• Usurpation d'API : un certificat pour matchmaking.yourgame.com permet à une partie malveillante de terminer les connexions TLS et d'injecter une fausse logique de jeu ou de rediriger les joueurs vers un serveur usurpé.
• Attaques par rejeu et par déclassement : avec un certificat valide en main, un attaquant peut retirer TLS et relayer le trafic, permettant des attaques de rejeu de session ou de déclassement de protocole qui échoueraient autrement contre un endpoint chiffré correctement configuré.

Ce n'est pas théorique. La surveillance CT a détecté l'incident MITM de CNNIC en 2015 et de multiples émissions abusives de Symantec qui ont conduit Chrome à ne plus faire confiance à tous les certificats Symantec. Le même mécanisme qui détecte les compromissions de CA par des États-nations fonctionne pour le serveur API de votre jeu indépendant.

Qu'est-ce que la Certificate Transparency (et ce qu'elle n'est pas)

La Certificate Transparency n'est pas un outil de sécurité que l'on installe. C'est un ensemble de serveurs de journaux publics, auditables cryptographiquement, qui enregistrent chaque certificat émis par les CA participantes. Voici ce qui se passe lorsqu'un certificat est émis :

1. La CA génère un pré-certificat et le soumet à un ou plusieurs journaux CT.
2. Chaque journal renvoie un Signed Certificate Timestamp (SCT) — une promesse cryptographique que le journal a enregistré le certificat.
3. La CA intègre ces SCT dans le certificat final et l'émet au demandeur.
4. Les navigateurs vérifient la présence de SCT valides avant de faire confiance au certificat.

Chacune de ces entrées de journal est publiquement interrogeable. Des services comme crt.sh offrent une interface de recherche gratuite sur les journaux. N'importe qui — y compris vous — peut rechercher tous les certificats jamais émis pour un domaine donné.

Ce que CT ne fait PAS : elle n'empêche pas les émissions abusives. Elle ne révoque pas les certificats malveillants. Elle fournit la détection, pas la prévention. Cela signifie que quelqu'un doit réellement surveiller les journaux et agir en conséquence. Ce quelqu'un, c'est vous.

Comment le détecter : interroger les journaux CT par programmation

Le moyen le plus accessible d'interroger les journaux de Certificate Transparency est crt.sh, Certificate Search, opéré par Sectigo. Il fournit une API JSON qui ne nécessite aucune authentification. Voici un script Python prêt pour la production qui interroge les journaux CT pour votre domaine et signale les émissions de certificats inattendues :

import requests
import json
from datetime import datetime, timedelta

# Domains to monitor — your game's API, auth, and matchmaker endpoints
MONITORED_DOMAINS = [
    "api.yourgame.com",
    "auth.yourgame.com",
    "match.yourgame.com",
]

# Issuers you expect and trust (adjust to your CDN/infrastructure provider)
TRUSTED_ISSUERS = {
    "C=US, O=Let's Encrypt, CN=R3",
    "C=US, O=Let's Encrypt, CN=E1",
    "C=US, O=Let's Encrypt, CN=R10",
    "C=US, O=Cloudflare, Inc., CN=Cloudflare Inc ECC CA-3",
}

def query_ct_logs(domain: str, check_hours: int = 72) -> list[dict]:
    """Query crt.sh for certificates issued for a domain in the last N hours."""
    url = f"https://crt.sh/?q=%25.{domain}&output=json"
    headers = {"User-Agent": "GameBackend-CT-Monitor/1.0"}

    try:
        resp = requests.get(url, headers=headers, timeout=60)
        resp.raise_for_status()
        certificates = resp.json()
    except requests.RequestException as e:
        print(f"[ERROR] Failed to query crt.sh for {domain}: {e}")
        return []

    cutoff = datetime.utcnow() - timedelta(hours=check_hours)
    results = []
    for cert in certificates:
        # crt.sh returns not_before as "2024-01-15T09:00:00" UTC
        try:
            not_before = datetime.strptime(cert["not_before"], "%Y-%m-%dT%H:%M:%S")
        except (ValueError, KeyError):
            continue
        if not_before > cutoff:
            results.append({
                "id": cert.get("id"),
                "domain": cert.get("common_name"),
                "issuer": cert.get("issuer_name"),
                "not_before": cert.get("not_before"),
                "not_after": cert.get("not_after"),
                "serial_number": cert.get("serial_number"),
            })
    return results

def run_monitor():
    """Check all monitored domains and return unauthorized certificates."""
    all_alerts = []
    for domain in MONITORED_DOMAINS:
        recent_certs = query_ct_logs(domain, check_hours=72)
        for cert in recent_certs:
            issuer = cert["issuer"]
            # Normalize: crt.sh sometimes adds whitespace variants
            issuer_normalized = issuer.strip()
            is_trusted = any(
                trusted in issuer_normalized for trusted in TRUSTED_ISSUERS
            )
            if not is_trusted:
                all_alerts.append(cert)
                print(
                    f"⚠️  ALERT: Unexpected certificate for {cert['domain']}\n"
                    f"   Issuer:    {issuer}\n"
                    f"   Valid:     {cert['not_before']} → {cert['not_after']}\n"
                    f"   Serial:    {cert['serial_number']}\n"
                    f"   crt.sh ID: https://crt.sh/?q={cert['serial_number']}\n"
                )
    if not all_alerts:
        print("✅ No unexpected certificates found across all monitored domains.")
    return all_alerts

if __name__ == "__main__":
    run_monitor()

Exécutez ceci avec une tâche cron toutes les 12 heures, et vous disposez d'un système de surveillance CT rudimentaire mais efficace :

0 */12 * * * /usr/bin/python3 /opt/monitor/ct_monitor.py >> /var/log/ct_monitor.log 2>&1

Ce que ce script fait bien

• Interroge crt.sh (gratuit, sans clé API, illimité pour des fréquences d'interrogation raisonnables)
• Filtre par date d'émission afin de ne voir que les certificats des 72 dernières heures
• Vérifie l'émetteur par rapport à une liste blanche de confiance pour signaler les certificats provenant de CA inattendues
• Produit une sortie structurée que vous pouvez envoyer vers Slack, Discord, PagerDuty ou par e-mail

Les limites de ce script

L'approche par liste blanche ne fonctionne que si vous connaissez tous les émetteurs à l'avance. Si vous passez de Let's Encrypt à ZeroSSL, vous recevrez une fausse alerte. Et crt.sh a une latence — généralement de 15 minutes à quelques heures entre l'émission et l'apparition dans le journal, plus un délai supplémentaire pour que crt.sh indexe l'entrée. L'alerte en temps réel nécessite une surveillance directe des journaux CT, ce qui est nettement plus complexe.

Il y a aussi le problème du bruit, qui a failli briser entièrement le modèle de surveillance.

Le problème du bruit : la fatigue d'alerte causée par vos propres certificats

Voici la partie qui tue la plupart des configurations de surveillance CT : le bruit généré par vos propres certificats légitimes.

Les certificats TLS sont conçus pour avoir une durée de vie courte. Un certificat Let's Encrypt standard est valide 90 jours et se renouvelle automatiquement vers le 60e jour. Les certificats Cloudflare Universal SSL peuvent se renouveler tous les 60 jours — environ six fois par an. Le CA/Browser Forum a voté la réduction de la durée de vie maximale des certificats à 47 jours d'ici 2029, ce qui doublera presque la cadence de renouvellement.

Chacun de ces renouvellements apparaît dans les journaux CT. Chaque entrée de journal déclenche votre script de surveillance. Si vous gérez trois domaines de backend de jeu avec renouvellement automatique des certificats, vous obtenez 18 alertes par an et par domaine provenant de votre propre infrastructure — chacune apparaissant comme un certificat « nouveau » dans les journaux.

Un client de Cloudflare a expliqué avoir désactivé la surveillance CT sur tous ses sites parce qu'il en avait assez de « recevoir des tonnes de renouvellements de certificats tout à fait normaux », ajoutant : « Je ne les lisais même plus à la fin. »

Lorsque le signal qui vous intéresse est un unique certificat anormal noyé dans un flux de renouvellements automatiques impossibles à distinguer de l'extérieur, le système cesse de fonctionner. Vous avez besoin d'un moyen d'identifier et de supprimer les alertes pour les certificats que vous avez émis vous-même.

La solution : l'empreinte SPKI pour distinguer vos certificats des inconnus

Cloudflare a récemment résolu ce problème à grande échelle en utilisant les hachages SubjectPublicKeyInfo (SPKI) comme identifiant cohérent entre leurs systèmes d'émission de certificats et d'alertes CT. L'approche se généralise à toute infrastructure, et les développeurs de jeux qui gèrent leurs propres certificats peuvent adopter la même technique.

Pourquoi une simple recherche ne fonctionne pas

Le premier réflexe est de suivre les certificats émis dans une base de données et de recouper leurs numéros de série ou empreintes avec les entrées des journaux CT. Le problème est le timing :

1. Une CA génère un pré-certificat et le soumet aux journaux CT.
2. Le journal CT enregistre le pré-certificat.
3. La CA intègre les Signed Certificate Timestamps (SCT) dans le certificat final.
4. La CA enregistre le certificat final.
5. La CA vous livre le certificat final.

L'empreinte hachée du pré-certificat et celle du certificat final diffèrent légèrement, car le certificat final contient les SCT intégrés que le pré-certificat ne possédait pas. Si votre système de surveillance voit l'entrée du pré-certificat dans le journal CT avant que la CA ne livre le certificat final à votre système de commande, il n'y a aucun enregistrement à comparer. Vous obtenez une fausse alerte.

Le hachage SPKI : un identifiant présent à chaque étape

Le hachage SPKI résout le problème de timing car la clé publique est identique dans le pré-certificat et le certificat final. Elle est générée lors de la création de la clé — avant l'émission de tout certificat — et elle ne change pas.

L'identifiant est : spki_sha256 = SHA-256(DER-encoded SubjectPublicKeyInfo)

Voici comment le calculer :

from cryptography import x509
from cryptography.hazmat.primitives import hashes, serialization
import hashlib

def compute_spki_sha256_from_pem(pem_data: str) -> str:
    """Compute spki_sha256 from any PEM-encoded certificate (pre-cert or final)."""
    cert = x509.load_pem_x509_certificate(pem_data.encode("utf-8"))
    spki_der = cert.public_key().public_bytes(
        encoding=serialization.Encoding.DER,
        format=serialization.PublicFormat.SubjectPublicKeyInfo,
    )
    return hashlib.sha256(spki_der).hexdigest()

def compute_spki_sha256_from_csr(csr_pem: str) -> str:
    """Compute spki_sha256 from a Certificate Signing Request (earliest possible point)."""
    csr = x509.load_pem_x509_csr(csr_pem.encode("utf-8"))
    spki_der = csr.public_key().public_bytes(
        encoding=serialization.Encoding.DER,
        format=serialization.PublicFormat.SubjectPublicKeyInfo,
    )
    return hashlib.sha256(spki_der).hexdigest()

Le flux de surveillance avec filtrage SPKI

L'architecture de surveillance mise à jour fonctionne comme suit :

De votre côté (émission de certificats) :

1. Générez une nouvelle paire de clés pour chaque commande de certificat.
2. Calculez spki_sha256 à partir du CSR ou de la clé publique.
3. Stockez le hachage dans votre base de données de suivi immédiatement — avant même que la CA ne commence l'émission.
4. Conservez les hachages pendant la durée de vie du certificat plus une marge de sécurité (par exemple, 30 jours après l'expiration).

Du côté de la surveillance (analyse des journaux CT) :

1. Analysez les nouvelles entrées des journaux CT pour vos domaines.
2. Extrayez la clé publique de chaque entrée de journal et calculez spki_sha256.
3. Recherchez le hachage dans votre base de données de suivi.
4. Correspondance trouvée → ce certificat provient de votre infrastructure. Supprimez l'alerte.
5. Aucune correspondance → ce certificat n'a pas été émis par votre système. Déclenchez une alerte.

Cela élimine les faux positifs de vos propres renouvellements sans manquer les certificats véritablement suspects provenant de CA externes.

Runbook complet : mise en place de la surveillance Certificate Transparency pour les serveurs de jeu

Prérequis

• Une liste de tous les domaines et sous-domaines utilisés par votre backend de jeu (y compris CDN, auth, matchmaking, télémétrie, livraison d'actifs)
• Python 3.9+ avec les bibliothèques requests et cryptography
• Un endpoint d'alerte (webhook Slack, webhook Discord, e-mail SMTP ou PagerDuty)
• Un accès à votre système de gestion de certificats pour enregistrer les hachages SPKI au moment de l'émission

Étape 1 : Inventoriez votre surface d'attaque

Avant de surveiller, vous avez besoin d'un inventaire complet des domaines. Si vous en oubliez un, il reste sans surveillance. Les domaines courants de backend de jeu incluent :

• api.yourgame.com — API principale du jeu
• auth.yourgame.com / login.yourgame.com — endpoints d'authentification
• match.yourgame.com / lobby.yourgame.com — serveurs de matchmaking et de lobby
• cdn.yourgame.com / assets.yourgame.com — livraison d'actifs statiques
• telemetry.yourgame.com — analytique et rapport de crash
• status.yourgame.com — page de statut (souvent un service séparé)

Les domaines génériques (par exemple, *.yourgame.com) élargissent encore la surface. Chaque certificat générique couvrant votre domaine est un vecteur d'attaque s'il est émis abusivement.

Étape 2 : Mettez en place le suivi des hachages SPKI

Intégrez l'enregistrement des hachages dans votre pipeline de déploiement de certificats. Chaque fois qu'un certificat est demandé ou généré, calculez et stockez le hachage SPKI. Une approche simple consiste à utiliser une base SQLite locale ou une clé Redis partagée :

import sqlite3
from datetime import datetime, timezone

DB_PATH = "/opt/monitor/spki_hashes.db"

def init_db():
    conn = sqlite3.connect(DB_PATH)
    conn.execute("""
        CREATE TABLE IF NOT EXISTS known_hashes (
            spki_hash TEXT PRIMARY KEY,
            domain TEXT NOT NULL,
            recorded_at TEXT NOT NULL,
            expires_at TEXT
        )
    """)
    conn.commit()
    conn.close()

def register_certificate(spki_hash: str, domain: str, expires_at: str):
    conn = sqlite3.connect(DB_PATH)
    conn.execute(
        "INSERT OR REPLACE INTO known_hashes (spki_hash, domain, recorded_at, expires_at) VALUES (?, ?, ?, ?)",
        (spki_hash, domain, datetime.now(timezone.utc).isoformat(), expires_at),
    )
    conn.commit()
    conn.close()

def is_known_certificate(spki_hash: str) -> bool:
    conn = sqlite3.connect(DB_PATH)
    row = conn.execute(
        "SELECT 1 FROM known_hashes WHERE spki_hash = ?", (spki_hash,)
    ).fetchone()
    conn.close()
    return row is not None

Étape 3 : Construisez le pipeline d'alertes

Combinez le script d'interrogation CT avec la vérification de la base SPKI. Lorsqu'un nouveau certificat apparaît dans les journaux CT :

1. Calculez son hachage SPKI.
2. Vérifiez-le dans votre base de hachages connus.
3. S'il est inconnu, alertez immédiatement.
4. Incluez le lien crt.sh, l'émetteur, la fenêtre de validité et le nom d'hôte dans la charge utile de l'alerte.

Router les alertes vers un webhook Slack ou Discord est rapide à configurer et donne à votre équipe une visibilité immédiate :

import os
import requests

SLACK_WEBHOOK_URL = os.environ.get("SLACK_CT_WEBHOOK_URL")

def send_slack_alert(cert: dict):
    if not SLACK_WEBHOOK_URL:
        print("[WARN] No Slack webhook configured; alert not sent.")
        return
    payload = {
        "text": (
            f"🚨 *Unauthorized TLS Certificate Detected*\n"
            f"*Domain:* {cert['domain']}\n"
            f"*Issuer:* {cert['issuer']}\n"
            f"*Valid:* {cert['not_before']} → {cert['not_after']}\n"
            f"*CT Log Entry:* https://crt.sh/?q={cert['serial_number']}\n"
            f"_Investigate immediately._"
        )
    }
    requests.post(SLACK_WEBHOOK_URL, json=payload, timeout=10)

Étape 4 : Définissez votre playbook de réponse aux incidents

Lorsqu'une alerte se déclenche, vous avez besoin d'une séquence de réponse documentée. Une fausse alerte coûte 5 minutes d'investigation. Une véritable émission abusive ignorée coûte les identifiants de vos joueurs.

Actions immédiates (dans l'heure suivant l'alerte) :

1. Ouvrez le lien crt.sh et vérifiez les détails du certificat (domaine, émetteur, type de clé, dates de validité).
2. Vérifiez si l'émetteur vous est connu. Des CA inconnues comme une autorité régionale obscure émettant des certificats pour votre domaine .com sont un signal d'alarme.
3. Vérifiez si le certificat est toujours valide et accessible sur le port 443 via les enregistrements DNS de votre domaine (openssl s_client -connect yourgame.com:443 -servername yourgame.com).
4. Comparez l'empreinte de la clé publique du certificat avec vos clés connues.

Si le certificat est non autorisé :

1. Soumettez un Certificate Problem Report à la CA émettrice (la plupart des CA ont un contact abuse@ ou security@).
2. Contactez simultanément la CA via son interface web ou son canal d'escalade direct.
3. Si la CA ne répond pas sous 24 heures, escaladez vers le CA/Browser Forum ou les programmes de racine des navigateurs (contact Chromium Security de Chrome, plaintes CA de Mozilla).
4. Si l'émission abusive résultait d'un échec de validation de domaine (quelqu'un a prouvé une propriété qu'il n'avait pas), auditez tous vos enregistrements DNS et WHOIS pour détecter des signes de compromission.
5. Envisagez de déployer des enregistrements DNS CAA (Certificate Authority Authorization) pour restreindre les CA autorisées à émettre des certificats pour votre domaine :

yourgame.com.  IN  CAA  0 issue "letsencrypt.org"
yourgame.com.  IN  CAA  0 issuewild "letsencrypt.org"
yourgame.com.  IN  CAA  0 iodef "security@yourgame.com"

Les enregistrements CAA sont vérifiés par les CA conformes avant l'émission. Ils n'arrêteront pas une CA non conforme, mais ils réduisent considérablement la surface d'attaque et rendent impossible l'émission abusive par les CA qui respectent les enregistrements CAA.

Étape 5 : Automatisez la prévention des récidives

Une fois l'incident traité, renforcez votre posture :

• Déployez des enregistrements CAA pour tous les domaines du backend de jeu (si ce n'est pas déjà fait).
• Activez l'authentification DNS des entités nommées (DANE) avec des enregistrements TLSA si votre fournisseur DNS le prend en charge — cela lie des clés de certificat spécifiques à votre domaine au niveau DNS.
• Raccourcissez votre propre fenêtre de renouvellement de certificats. Des certificats à durée de vie plus courte signifient un rayon d'explosion plus petit en cas de compromission d'une clé privée.
• Journalisez tous les événements d'émission de certificats de votre propre infrastructure comme entrées de piste d'audit avec horodatages et hachages SPKI.

Bonnes pratiques : renforcer la gestion des certificats TLS pour les serveurs de jeu

1. Surveillez chaque domaine utilisé par votre jeu, pas seulement l'API principale. Les endpoints de télémétrie, les origines CDN, les balises analytiques et les serveurs de staging représentent tous une surface d'attaque. Un certificat émis pour un sous-domaine oublié comme old-matchmaking.yourgame.com peut encore être utilisé pour une interception si ce domaine résout vers quelque chose d'accessible.

2. Déployez des enregistrements DNS CAA pour chaque domaine que vous contrôlez. Un simple enregistrement CAA 0 issue "letsencrypt.org" indique aux CA conformes de refuser les demandes d'émission de toute autre autorité. C'est un changement DNS de cinq minutes qui bloque toute une classe d'émissions abusives. Ajoutez iodef pour recevoir des notifications par e-mail lorsqu'une CA rejette une demande d'émission à cause de votre politique CAA.

3. Stockez les hachages SPKI de vos propres certificats au moment de l'émission, pas après le déploiement. La fenêtre entre l'enregistrement du pré-certificat par la CA et la réception du certificat final par votre système est là où vivent les fausses alertes. Enregistrer le hachage SPKI au moment de la génération de la clé — avant même la soumission du CSR — élimine complètement cet écart.

4. Définissez une cadence de surveillance plus rapide que votre cycle de renouvellement de certificats. Si vos certificats se renouvellent tous les 60 jours, vérifier les journaux CT une fois par jour vous donne une latence de détection maximale de 24 heures. Pour les backends de jeu en production où les jetons d'authentification sont la cible la plus précieuse, c'est acceptable mais pas idéal. Toutes les 6 à 12 heures est un bon compromis compte tenu de la latence d'indexation de crt.sh.

5. Intégrez les alertes CT dans votre canal de réponse aux incidents existant. Une surveillance CT qui envoie des e-mails vers une boîte partagée que personne ne consulte est pire qu'inutile — elle crée une fausse confiance. Routez les alertes vers le même canal Slack ou Discord que votre équipe d'astreinte surveille déjà pour les alertes de santé serveur. (Cela diffère des protocoles de crash serveur généraux, mais la cadence de réponse doit être similaire — sensible au temps, documentée, avec un responsable clair.)

Comment horizOn gère la gestion des certificats

Suivre manuellement les hachages SPKI, interroger les journaux CT, déployer des enregistrements CAA et maintenir un playbook de réponse aux incidents représente un vrai travail — généralement 2 à 3 semaines d'ingénierie infrastructure pour une petite équipe. horizOn gère le provisionnement et le renouvellement des certificats TLS dans le cadre de sa plateforme backend pour les développeurs de jeux, ce qui signifie que les certificats émis via la plateforme sont déjà suivis en interne. Le volet surveillance (lecture des journaux CT pour détecter des émetteurs inattendus) nécessite encore des outils externes, mais la moitié du problème — savoir quels certificats sont les vôtres — est résolue automatiquement.

Si vous construisez un backend de jeu et souhaitez éviter de câbler vous-même la gestion des certificats, l'automatisation des renouvellements et le suivi SPKI, horizOn vous offre une base préconstruite pour vous concentrer sur la logique de gameplay plutôt que sur la plomberie PKI.

Prochaines étapes

Commencez par le script de cet article. Pointez-le dès aujourd'hui sur les domaines de votre jeu et exécutez-le manuellement pour voir ce qui existe déjà dans les journaux CT pour votre infrastructure. Vous serez peut-être surpris par le volume de certificats historiques — et vous saurez au moins à quoi ressemble votre base de référence avant d'automatiser les alertes. Ajoutez ensuite le suivi des hachages SPKI pour filtrer vos propres renouvellements, et vous disposerez d'un système de surveillance qui fait réellement remonter l'essentiel : les certificats que vous n'attendiez pas, émis par des CA que vous n'avez pas choisies.

---

Source : La surveillance Certificate Transparency est désormais généralement disponible