Unberechtigte TLS-Zertifikate auf Game-Servern: Wie Certificate-Transparency-Logs aufdecken, was Firewalls übersehen

Gerade jetzt gibt es ein öffentliches, append-only Log aller TLS-Zertifikate, die für jede Domain im Internet ausgestellt wurden – auch für Ihre. Wenn morgen jemand zu einer Zertifizierungsstelle geht und sie überzeugt, ein gültiges TLS-Zertifikat für Ihre Spiel-API unter api.yourgame.com auszustellen, wird dieses Zertifikat innerhalb von Minuten in den Certificate-Transparency-Logs (CT-Logs) erscheinen. Die einzige Frage ist, ob Sie es bemerken.

Die meisten Spieleentwickler werden es nicht. Sie erfahren es, wenn Spieler SSL-Fehler melden, wenn ein Penetrationstester das Problem aufdeckt, oder schlimmer – wenn gestohlene Auth-Tokens auf Sekundärmärkten auftauchen, weil ein bösartiges Zertifikat einen Man-in-the-Middle-Proxy zwischen Spielern und dem Login-Endpoint ermöglicht hat.

Dieser Beitrag ist ein Runbook für die Überwachung von Certificate-Transparency-Logs für Ihre Game-Backend-Domains. Er behandelt, was CT-Logs tatsächlich sind, wie man sie programmatisch abfragt, wie man das Rauschen aus Ihren eigenen routinemäßigen Erneuerungen herausfiltert und wie man eine Alerting-Pipeline aufbaut, die unbefugte Zertifikatsausstellungen erkennt, bevor sie zu Sicherheitsvorfällen werden.

Was kaputtgeht: Unbefugte TLS-Zertifikatsausstellung gegen Game-Backends

Jedes TLS-Zertifikat, das von einer öffentlich vertrauenswürdigen Zertifizierungsstelle (CA) ausgestellt wird, muss in mindestens zwei öffentlichen Certificate-Transparency-Logs protokolliert werden. Dies ist seit April 2018 effektiv Pflicht, als Chrome die CT-Aufnahme für alle neuen Zertifikate verlangte. Apple Safari folgte mit ähnlichen Anforderungen. Jedes Zertifikat, das nicht protokolliert wird, wird von den großen Browsern nicht vertraut.

Das CT-Ökosystem existiert, um Fehlausstellungen zu erkennen – Situationen, in denen eine CA ein Zertifikat für eine Domain ausstellt, die der Antragsteller nicht kontrolliert. Für Game-Backends sieht das Bedrohungsmodell so aus:

• Credential-Interception: Ein Angreifer erhält ein gültiges Zertifikat für auth.yourgame.com, richtet einen Proxy zwischen Spielern und Ihrem echten Auth-Server ein und erntet Login-Tokens. Für den Spieler sieht die Verbindung legitim aus, weil der Browser dem Zertifikat vertraut.
• API-Imitation: Ein Zertifikat für matchmaking.yourgame.com ermöglicht es einer böswilligen Partei, TLS-Verbindungen zu beenden und gefälschte Spiellogik einzuschleusen oder Spieler auf einen gefälschten Server umzuleiten.
• Replay- und Downgrade-Angriffe: Mit einem gültigen Zertifikat in der Hand kann ein Angreifer TLS entfernen und Datenverkehr weiterleiten, was Session-Replay- oder Protokoll-Downgrade-Angriffe ermöglicht, die sonst gegen einen ordnungsgemäß konfigurierten verschlüsselten Endpoint scheitern würden.

Das ist nicht theoretisch. CT-Überwachung hat den CNNIC-MITM-Vorfall im Jahr 2015 und mehrere Symantec-Fehlausstellungen aufgedeckt, die dazu führten, dass Chrome allen Symantec-Zertifikaten misstraute. Derselbe Mechanismus, der Kompromittierungen von staatlichen CAs erkennt, funktioniert auch für den API-Server Ihres Indie-Spiels.

Was ist Certificate Transparency (und was es nicht ist)

Certificate Transparency ist kein Sicherheitstool, das Sie installieren. Es ist eine Reihe öffentlich betriebener, kryptografisch prüfbarer Log-Server, die jedes von teilnehmenden CAs ausgestellte Zertifikat aufzeichnen. So läuft es ab, wenn ein Zertifikat ausgestellt wird:

1. Die CA erzeugt ein Pre-Zertifikat und übermittelt es an ein oder mehrere CT-Logs.
2. Jedes Log gibt einen Signed Certificate Timestamp (SCT) zurück – ein kryptografisches Versprechen, dass das Log das Zertifikat aufgezeichnet hat.
3. Die CA bettet diese SCTs in das endgültige Zertifikat ein und stellt es dem Antragsteller aus.
4. Browser prüfen, ob gültige SCTs vorhanden sind, bevor sie dem Zertifikat vertrauen.

Jeder dieser Log-Einträge ist öffentlich abfragbar. Dienste wie crt.sh bieten eine kostenlose Suchoberfläche über die Logs. Jeder – auch Sie – kann nach allen Zertifikaten suchen, die jemals für eine bestimmte Domain ausgestellt wurden.

Was CT NICHT tut: Es verhindert keine Fehlausstellungen. Es widerruft keine schlechten Zertifikate. Es bietet Erkennung, nicht Prävention. Das bedeutet, dass jemand die Logs tatsächlich überwachen und auf das reagieren muss, was er findet. Diese Person sind Sie.

So erkennen Sie es: CT-Logs programmatisch abfragen

Der einfachste Weg, Certificate-Transparency-Logs abzufragen, ist über crt.sh, Certificate Search, betrieben von Sectigo. Es bietet eine JSON-API, die keine Authentifizierung erfordert. Hier ist ein produktionsreifes Python-Skript, das CT-Logs für Ihre Domain abfragt und unerwartete Zertifikatsausstellungen kennzeichnet:

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()

Führen Sie dies mit einem Cron-Job alle 12 Stunden aus, und Sie haben ein rudimentäres, aber effektives CT-Überwachungssystem:

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

Was dieses Skript gut kann

• Fragt crt.sh ab (kostenlos, ohne API-Schlüssel, unbegrenzt bei angemessenen Abfrageintervallen)
• Filtert nach Ausstellungszeit, sodass Sie nur Zertifikate aus den letzten 72 Stunden sehen
• Prüft den Aussteller gegen eine bekannte Whitelist, um Zertifikate von unerwarteten CAs zu kennzeichnen
• Gibt strukturierte Ausgaben aus, die Sie an Slack, Discord, PagerDuty oder E-Mail weiterleiten können

Wo dieses Skript an seine Grenzen stößt

Der Whitelist-Ansatz funktioniert nur, wenn Sie jeden Aussteller im Voraus kennen. Wenn Sie von Let's Encrypt zu ZeroSSL wechseln, erhalten Sie einen Fehlalarm. Und crt.sh hat eine Latenz – typischerweise 15 Minuten bis zu einigen Stunden zwischen Ausstellung und Erscheinen im Log, plus zusätzliche Zeit für crt.sh, um den Eintrag zu indizieren. Echtzeit-Warnungen erfordern direktes CT-Log-Monitoring, was erheblich komplexer ist.

Es gibt auch das Rauschproblem, und es hat das Überwachungsmodell fast vollständig zum Scheitern gebracht.

Das Rauschproblem: Alert-Müdigkeit durch Ihre eigenen Zertifikate

Hier ist der Teil, der die meisten CT-Überwachungssetups tötet: Rauschen durch Ihre eigenen legitimen Zertifikate.

TLS-Zertifikate sind von Natur aus kurzlebig. Ein Standard-Let's-Encrypt-Zertifikat ist 90 Tage gültig und erneuert sich automatisch um Tag 60. Cloudflare Universal SSL-Zertifikate können sich alle 60 Tage erneuern – etwa sechsmal pro Jahr. Das CA/Browser Forum hat beschlossen, die maximale Zertifikatslebensdauer bis 2029 auf 47 Tage zu senken, was die Erneuerungsfrequenz fast verdoppeln wird.

Jede dieser Erneuerungen erscheint in den CT-Logs. Jeder Log-Eintrag löst Ihr Überwachungsskript aus. Wenn Sie drei Game-Backend-Domains mit automatischer Zertifikatserneuerung betreiben, haben Sie 18 Alerts pro Jahr pro Domain aus Ihrer eigenen Infrastruktur – jeder erscheint als „neues“ Zertifikat in den Logs.

Ein Cloudflare-Kunde beschrieb, dass er die CT-Überwachung auf allen seinen Websites deaktiviert hat, weil er es satt hatte, „mit einer Flut völlig normaler Zertifikatserneuerungen zugespammt zu werden“, und fügte hinzu: „Ich habe sie am Ende nicht einmal mehr wirklich gelesen.“

Wenn das Signal, das Sie interessiert, ein einzelnes anomales Zertifikat ist, das in einem Strom automatisierter Erneuerungen vergraben ist, die Sie von außen nicht unterscheiden können, funktioniert das System nicht mehr. Sie brauchen eine Möglichkeit, Alerts für Zertifikate, die Sie selbst ausgestellt haben, zu identifizieren und zu unterdrücken.

Die Lösung: SPKI-Fingerprinting, um Ihre Zertifikate von unbekannten zu trennen

Cloudflare hat dieses Problem kürzlich in großem Maßstab gelöst, indem es SubjectPublicKeyInfo (SPKI)-Hashes als konsistenten Identifikator über ihre Zertifikatsausstellung und CT-Alerting-Systeme verwendet. Der Ansatz lässt sich auf jede Infrastruktur übertragen, und Spieleentwickler, die ihr eigenes Zertifikatsmanagement betreiben, können dieselbe Technik übernehmen.

Warum eine einfache Suche nicht funktioniert

Der erste Instinkt ist, ausgestellte Zertifikate in einer Datenbank zu verfolgen und ihre Seriennummern oder Fingerabdrücke mit CT-Log-Einträgen abzugleichen. Das Problem ist das Timing:

1. Eine CA erzeugt ein Pre-Zertifikat und übermittelt es an CT-Logs.
2. Das CT-Log zeichnet das Pre-Zertifikat auf.
3. Die CA bettet Signed Certificate Timestamps (SCTs) in das endgültige Zertifikat ein.
4. Die CA protokolliert das endgültige Zertifikat.
5. Die CA liefert das endgültige Zertifikat an Sie aus.

Ein gehashter Fingerabdruck des Pre-Zertifikats und des endgültigen Zertifikats unterscheiden sich geringfügig, da das endgültige Zertifikat die eingebetteten SCTs enthält, die das Pre-Zertifikat nicht hatte. Wenn Ihr Überwachungssystem den Pre-Zertifikat-Eintrag im CT-Log sieht, bevor die CA das endgültige Zertifikat an Ihr Bestellsystem liefert, gibt es keinen Datensatz zum Abgleich. Sie erhalten einen Fehlalarm.

Der SPKI-Hash: Ein Identifikator, der in jeder Phase erscheint

Der SPKI-Hash löst das Timing-Problem, weil der öffentliche Schlüssel im Pre-Zertifikat und im endgültigen Zertifikat identisch ist. Er wird bei der Schlüsselerstellung generiert – bevor ein Zertifikat ausgestellt wird – und ändert sich nicht.

Der Identifikator ist: spki_sha256 = SHA-256(DER-encoded SubjectPublicKeyInfo)

So berechnen Sie ihn:

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()

Der Überwachungsablauf mit SPKI-Filterung

Die aktualisierte Überwachungsarchitektur funktioniert so:

Auf Ihrer Seite (Zertifikatsausstellung):

1. Erzeugen Sie ein neues Schlüsselpaar für jede Zertifikatsbestellung.
2. Berechnen Sie spki_sha256 aus dem CSR oder dem öffentlichen Schlüssel.
3. Speichern Sie den Hash sofort in Ihrer Tracking-Datenbank – bevor die CA überhaupt mit der Ausstellung beginnt.
4. Behalten Sie die Hashes für die Lebensdauer des Zertifikats plus eine Sicherheitsmarge (z. B. 30 Tage nach Ablauf).

Auf der Überwachungsseite (CT-Log-Scanning):

1. Parsen Sie neue CT-Log-Einträge für Ihre Domains.
2. Extrahieren Sie den öffentlichen Schlüssel aus jedem Log-Eintrag und berechnen Sie spki_sha256.
3. Suchen Sie den Hash in Ihrer Tracking-Datenbank.
4. Übereinstimmung gefunden → dieses Zertifikat stammt aus Ihrer Infrastruktur. Unterdrücken Sie den Alert.
5. Keine Übereinstimmung → dieses Zertifikat wurde nicht von Ihrem System ausgestellt. Lösen Sie einen Alert aus.

Dies eliminiert Fehlalarme durch Ihre eigenen Erneuerungen, ohne wirklich verdächtige Zertifikate von externen CAs zu übersehen.

Vollständiges Runbook: Einrichtung der Certificate-Transparency-Überwachung für Game-Server

Voraussetzungen

• Eine Liste aller Domains und Subdomains, die von Ihrem Game-Backend verwendet werden (einschließlich CDN, Auth, Matchmaking, Telemetrie, Asset-Auslieferung)
• Python 3.9+ mit den Bibliotheken requests und cryptography
• Einen Alerting-Endpoint (Slack-Webhook, Discord-Webhook, E-Mail-SMTP oder PagerDuty)
• Zugriff auf Ihr Zertifikatsmanagementsystem, um SPKI-Hashes zum Zeitpunkt der Ausstellung zu erfassen

Schritt 1: Erfassen Sie Ihre Angriffsfläche

Vor der Überwachung benötigen Sie ein vollständiges Inventar der Domains. Wenn Sie eine übersehen, bleibt sie unüberwacht. Häufige Game-Backend-Domains sind:

• api.yourgame.com — Haupt-Game-API
• auth.yourgame.com / login.yourgame.com — Authentifizierungs-Endpoints
• match.yourgame.com / lobby.yourgame.com — Matchmaking- und Lobby-Server
• cdn.yourgame.com / assets.yourgame.com — statische Asset-Auslieferung
• telemetry.yourgame.com — Analytik und Crash-Reporting
• status.yourgame.com — Statusseite (oft ein separater Dienst)

Wildcard-Domains (z. B. *.yourgame.com) erweitern die Angriffsfläche weiter. Jedes Wildcard-Zertifikat, das Ihre Domain abdeckt, ist ein Angriffsvektor, wenn es fehlausgestellt wird.

Schritt 2: SPKI-Hash-Tracking einrichten

Integrieren Sie die Hash-Erfassung in Ihre Zertifikatsbereitstellungspipeline. Jedes Mal, wenn ein Zertifikat angefordert oder generiert wird, berechnen und speichern Sie den SPKI-Hash. Ein einfacher Ansatz ist eine lokale SQLite-Datenbank oder ein gemeinsamer Redis-Schlüssel:

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

Schritt 3: Die Alerting-Pipeline aufbauen

Kombinieren Sie das CT-Abfrageskript mit der SPKI-Datenbankprüfung. Wenn ein neues Zertifikat in CT-Logs erscheint:

1. Berechnen Sie seinen SPKI-Hash.
2. Prüfen Sie gegen Ihre Datenbank bekannter Hashes.
3. Wenn unbekannt, alarmieren Sie sofort.
4. Fügen Sie den crt.sh-Link, Aussteller, Gültigkeitsfenster und Hostname in die Alert-Payload ein.

Das Weiterleiten von Alerts an einen Slack- oder Discord-Webhook ist schnell eingerichtet und gibt Ihrem Team sofortige Sichtbarkeit:

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)

Schritt 4: Definieren Sie Ihr Incident-Response-Playbook

Wenn ein Alert ausgelöst wird, benötigen Sie eine dokumentierte Reaktionssequenz. Ein Fehlalarm kostet 5 Minuten Untersuchung. Eine echte Fehlausstellung, die ignoriert wird, kostet die Zugangsdaten Ihrer Spieler.

Sofortmaßnahmen (innerhalb von 1 Stunde nach dem Alert):

1. Öffnen Sie den crt.sh-Link und überprüfen Sie die Zertifikatsdetails (Domain, Aussteller, Schlüsseltyp, Gültigkeitsdaten).
2. Prüfen Sie, ob der Aussteller einer ist, den Sie kennen. Unbekannte CAs wie eine obskure regionale Behörde, die Zertifikate für Ihre .com-Domain ausstellt, sind eine rote Flagge.
3. Prüfen Sie, ob das Zertifikat noch gültig und über Port 443 gegen Ihre DNS-Einträge erreichbar ist (openssl s_client -connect yourgame.com:443 -servername yourgame.com).
4. Vergleichen Sie den Fingerabdruck des öffentlichen Schlüssels des Zertifikats mit Ihren bekannten guten Schlüsseln.

Wenn das Zertifikat unbefugt ist:

1. Reichen Sie einen Certificate Problem Report bei der ausstellenden CA ein (die meisten CAs haben einen abuse@- oder security@-Kontakt).
2. Kontaktieren Sie gleichzeitig die CA über ihre Weboberfläche oder einen direkten Eskalationskanal.
3. Wenn die CA innerhalb von 24 Stunden nicht reagiert, eskalieren Sie an das CA/Browser Forum oder die Root-Programme der Browser (Chromium-Sicherheitskontakt von Chrome, Mozilla CA Complaints).
4. Wenn die Fehlausstellung auf einen Domain-Validierungsfehler zurückzuführen ist (jemand hat Eigentum nachgewiesen, das er nicht hatte), prüfen Sie alle Ihre DNS- und WHOIS-Einträge auf Anzeichen einer Kompromittierung.
5. Erwägen Sie die Bereitstellung von CAA (Certificate Authority Authorization)-DNS-Einträgen, um einzuschränken, welche CAs Zertifikate für Ihre Domain ausstellen dürfen:

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"

CAA-Einträge werden von konformen CAs vor der Ausstellung geprüft. Sie stoppen keine nicht-konforme CA, aber sie verengen die Angriffsfläche erheblich und machen Fehlausstellungen von CAs, die CAA-Einträge respektieren, unmöglich.

Schritt 5: Automatisieren Sie die Prävention von Wiederholungen

Sobald Sie einen Vorfall bearbeitet haben, härten Sie Ihre Haltung:

• Stellen Sie CAA-Einträge für alle Game-Backend-Domains bereit (falls noch nicht vorhanden).
• Aktivieren Sie DNS-based Authentication of Named Entities (DANE) mit TLSA-Einträgen, wo Ihr DNS-Anbieter dies unterstützt – dies bindet spezifische Zertifikatsschlüssel auf DNS-Ebene an Ihre Domain.
• Verkürzen Sie Ihr eigenes Zertifikatserneuerungsfenster. Kürzerlebige Zertifikate bedeuten, dass der Schadensradius eines kompromittierten privaten Schlüssels kleiner ist.
• Protokollieren Sie alle Zertifikatsausstellungsereignisse aus Ihrer eigenen Infrastruktur als Audit-Trail-Einträge mit Zeitstempeln und SPKI-Hashes.

Best Practices: Härtung des TLS-Zertifikatsmanagements für Game-Server

1. Überwachen Sie jede Domain, die Ihr Spiel verwendet, nicht nur die Haupt-API. Telemetrie-Endpoints, CDN-Ursprünge, Analytik-Beacons und Staging-Server stellen alle Angriffsfläche dar. Ein Zertifikat, das für eine vergessene Subdomain wie old-matchmaking.yourgame.com ausgestellt wurde, kann immer noch für Abfangen verwendet werden, wenn diese Domain zu etwas Erreichbarem aufgelöst wird.

2. Stellen Sie CAA-DNS-Einträge für jede Domain bereit, die Sie kontrollieren. Ein einzelner CAA 0 issue "letsencrypt.org"-Eintrag weist konforme CAs an, Ausstellungsanfragen von jeder anderen Behörde abzulehnen. Das ist eine DNS-Änderung in fünf Minuten, die eine ganze Klasse von Fehlausstellungen blockiert. Fügen Sie iodef hinzu, um E-Mail-Benachrichtigungen zu erhalten, wenn eine CA eine Ausstellungsanfrage aufgrund Ihrer CAA-Richtlinie ablehnt.

3. Speichern Sie SPKI-Hashes Ihrer eigenen Zertifikate zum Zeitpunkt der Ausstellung, nicht nach der Bereitstellung. Das Fenster zwischen der Protokollierung des Pre-Zertifikats durch die CA und dem Erhalt des endgültigen Zertifikats durch Ihr System ist der Ort, an dem Fehlalarme entstehen. Die Aufzeichnung des SPKI-Hashes zum Zeitpunkt der Schlüsselerstellung – bevor der CSR überhaupt eingereicht wird – eliminiert diese Lücke vollständig.

4. Legen Sie Ihre Überwachungsfrequenz schneller fest als Ihren Zertifikatserneuerungszyklus. Wenn Ihre Zertifikate alle 60 Tage erneuert werden, ergibt eine tägliche Prüfung der CT-Logs eine maximale Erkennungslatenz von 24 Stunden. Für Produktions-Game-Backends, in denen Auth-Tokens das wertvollste Ziel sind, ist das akzeptabel, aber nicht ideal. Alle 6 bis 12 Stunden ist ein praktischer Sweet Spot angesichts der Indizierungslatenz von crt.sh.

5. Integrieren Sie CT-Alerts in Ihren bestehenden Incident-Response-Kanal. CT-Überwachung, die E-Mails an ein gemeinsames Postfach sendet, das niemand überprüft, ist schlimmer als nutzlos – sie erzeugt falsches Vertrauen. Leiten Sie Alerts an denselben Slack- oder Discord-Kanal weiter, den Ihr Bereitschaftsteam bereits für Server-Health-Alerts überwacht. (Dies unterscheidet sich von allgemeinen Server-Crash-Protokollen, aber die Reaktionsfrequenz sollte ähnlich sein – zeitkritisch, dokumentiert, mit Verantwortlichkeit.)

Wie horizOn Zertifikatsmanagement handhabt

Das manuelle Verfolgen von SPKI-Hashes, das Abfragen von CT-Logs, das Bereitstellen von CAA-Einträgen und das Pflegen eines Incident-Response-Playbooks ist echte Arbeit – typischerweise 2-3 Wochen Infrastruktur-Engineering für ein kleines Team. horizOn übernimmt die Bereitstellung und Erneuerung von TLS-Zertifikaten als Teil seiner Backend-Plattform für Spieleentwickler, was bedeutet, dass Zertifikate, die über die Plattform ausgestellt werden, intern bereits verfolgt werden. Die Überwachungsseite (Lesen von CT-Logs auf unerwartete Aussteller) erfordert weiterhin externe Tools, aber die halbe Aufgabe – zu wissen, welche Zertifikate Ihre sind – ist automatisch gelöst.

Wenn Sie ein Game-Backend aufbauen und vermeiden möchten, Zertifikatsmanagement, Erneuerungsautomatisierung und SPKI-Tracking selbst einzurichten, bietet Ihnen horizOn ein vorgefertigtes Fundament, sodass Sie sich auf Spiellogik konzentrieren können, anstatt auf PKI-Infrastruktur.

Nächste Schritte

Beginnen Sie mit dem Skript in diesem Beitrag. Richten Sie es heute auf die Domains Ihres Spiels und führen Sie es manuell aus, um zu sehen, was bereits in den CT-Logs für Ihre Infrastruktur vorhanden ist. Sie werden vielleicht über die Menge historischer Zertifikate überrascht sein – und Sie werden zumindest wissen, wie Ihre Baseline aussieht, bevor Sie mit der Automatisierung von Alerts beginnen. Fügen Sie dann das SPKI-Hash-Tracking hinzu, um Ihre eigenen Erneuerungen zu filtern, und Sie haben ein Überwachungssystem, das tatsächlich das aufdeckt, was zählt: Zertifikate, die Sie nicht erwartet haben, ausgestellt von CAs, die Sie nicht gewählt haben.

---

Quelle: Certificate-Transparency-Überwachung ist jetzt allgemein verfügbar