Nieautoryzowane certyfikaty TLS na serwerach gier: Jak logi Certificate Transparency wykrywają to, czego firewalle nie widzą

W tej chwili istnieje publiczny, append-only rejestr każdego certyfikatu TLS wydanego dla każdej domeny w internecie — w tym dla Twojej. Jeśli jutro ktoś podejdzie do urzędu certyfikacji (CA) i przekona go do wydania ważnego certyfikatu TLS dla Twojego API gry pod adresem api.yourgame.com, ten certyfikat pojawi się w logach Certificate Transparency (CT) w ciągu kilku minut. Pytanie brzmi tylko, czy to zauważysz.

Większość deweloperów gier nie zauważy. Dowiadują się, gdy gracze zgłaszają błędy SSL, gdy pentester oznaczy problem, albo co gorsza — gdy skradzione tokeny autoryzacyjne zaczynają pojawiać się na wtórnych rynkach, ponieważ złośliwy certyfikat umożliwił atak man-in-the-middle między graczami a endpointem logowania.

Ten post to runbook do monitorowania logów Certificate Transparency pod kątem domen backendu Twojej gry. Omawia, czym właściwie są logi CT, jak je odpytywać programistycznie, jak odfiltrować szum z własnych rutynowych odnowień oraz jak zbudować pipeline alertujący, który wykryje nieautoryzowane wydania certyfikatów, zanim staną się naruszeniami bezpieczeństwa.

Co się psuje: Nieautoryzowane wydanie certyfikatu TLS dla backendu gry

Każdy certyfikat TLS wydany przez publicznie zaufany urząd certyfikacji (CA) musi być zalogowany w co najmniej dwóch publicznych logach Certificate Transparency. Jest to faktycznie obowiązkowe od kwietnia 2018 roku, gdy Chrome zaczął wymagać dołączenia CT dla wszystkich nowych certyfikatów. Apple Safari wprowadziło podobne wymagania. Każdy certyfikat, który nie jest zalogowany, nie będzie zaufany przez główne przeglądarki.

Ekologia CT istnieje po to, aby wykrywać mis-issuance — sytuacje, w których CA wydaje certyfikat dla domeny, której requester nie kontroluje. Dla backendów gier model zagrożeń wygląda tak:

• Przechwytywanie poświadczeń: Atakujący uzyskuje ważny certyfikat dla auth.yourgame.com, ustawia proxy między graczami a Twoim prawdziwym serwerem auth i zbiera tokeny logowania. Dla gracza połączenie wygląda na legalne, ponieważ przeglądarka ufa certyfikatowi.
• Impersonacja API: Certyfikat dla matchmaking.yourgame.com pozwala złośliwej stronie zakończyć połączenia TLS i wstrzykiwać fałszywą logikę gry lub przekierowywać graczy na spreparowany serwer.
• Ataki replay i downgrade: Z ważnym certyfikatem w ręku atakujący może usunąć TLS i przekazywać ruch, umożliwiając ataki typu session replay lub downgrade protokołu, które w innym przypadku nie powiodłyby się przeciwko poprawnie skonfigurowanemu zaszyfrowanemu endpointowi.

To nie jest teoria. Monitoring CT wykrył incydent MITM z CNNIC w 2015 roku oraz wiele przypadków mis-issuance od Symantec, które doprowadziły do całkowitego odrzucenia certyfikatów Symantec przez Chrome. Ten sam mechanizm, który wykrywa kompromitacje CA na poziomie państwowym, działa dla serwera API Twojej indie gry.

Czym jest Certificate Transparency (a czym nie jest)

Certificate Transparency to nie narzędzie bezpieczeństwa, które instalujesz. To zestaw publicznie uruchomionych, kryptograficznie audytowalnych serwerów logów, które rejestrują każdy certyfikat wydany przez uczestniczące CA. Oto co się dzieje, gdy certyfikat zostaje wydany:

1. CA generuje pre-certyfikat i przesyła go do jednego lub więcej logów CT.
2. Każdy log zwraca Signed Certificate Timestamp (SCT) — kryptograficzną obietnicę, że log zarejestrował certyfikat.
3. CA osadza te SCT w finalnym certyfikacie i wydaje go requesterowi.
4. Przeglądarki weryfikują obecność ważnych SCT przed zaufaniem certyfikatowi.

Każdy z tych wpisów logów jest publicznie odpytywalny. Usługi takie jak crt.sh zapewniają darmowy interfejs wyszukiwania w logach. Każdy — w tym Ty — może wyszukać wszystkie certyfikaty kiedykolwiek wydane dla danej domeny.

Czego CT NIE robi: nie zapobiega mis-issuance. Nie odwołuje złych certyfikatów. Zapewnia detekcję, nie prewencję. To oznacza, że ktoś musi faktycznie monitorować logi i reagować na to, co znajdzie. Tym kimś jesteś Ty.

Jak to wykryć: Programistyczne odpytywanie logów CT

Najbardziej dostępnym sposobem odpytywania logów Certificate Transparency jest crt.sh, Certificate Search, obsługiwany przez Sectigo. Udostępnia API JSON, które nie wymaga autoryzacji. Oto gotowy do produkcji skrypt w Pythonie, który odpytuje logi CT dla Twojej domeny i flaguje nieoczekiwane wydania certyfikatów:

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

Uruchom to przez cron co 12 godzin, a otrzymasz podstawowy, ale skuteczny system monitorowania CT:

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

Co ten skrypt robi dobrze

• Odpytuje crt.sh (darmowe, bez klucza API, bez limitu dla rozsądnych częstotliwości odpytywania)
• Filtruje według czasu wydania, więc widzisz tylko certyfikaty z ostatnich 72 godzin
• Sprawdza wystawcę względem listy dozwolonych, aby flagować certyfikaty od nieoczekiwanych CA
• Generuje ustrukturyzowane wyjście, które możesz przekierować do Slacka, Discorda, PagerDuty lub e-maila

Gdzie ten skrypt zawodzi

Podejście z listą dozwolonych działa tylko wtedy, gdy znasz wszystkich wystawców z góry. Jeśli przejdziesz z Let's Encrypt na ZeroSSL, dostaniesz fałszywy alarm. Dodatkowo crt.sh ma opóźnienie — zwykle od 15 minut do kilku godzin między wydaniem a pojawieniem się w logu, plus dodatkowy czas na indeksację wpisu przez crt.sh. Alerting w czasie rzeczywistym wymaga bezpośredniego monitorowania logów CT, co jest znacznie bardziej złożone.

Jest też problem szumu, który niemal zabił cały model monitorowania.

Problem szumu: Zmęczenie alertami od własnych certyfikatów

Oto część, która zabija większość konfiguracji monitorowania CT: szum z własnych legalnych certyfikatów.

Certyfikaty TLS są z założenia krótkotrwałe. Standardowy certyfikat Let's Encrypt jest ważny 90 dni i automatycznie odnawia się około 60. dnia. Certyfikaty Cloudflare Universal SSL mogą odnawiać się co 60 dni — mniej więcej sześć razy w roku. Forum CA/Browser zagłosowało za skróceniem maksymalnego okresu ważności certyfikatów do 47 dni do 2029 roku, co niemal podwoi częstotliwość odnowień.

Każde z tych odnowień pojawia się w logach CT. Każdy wpis w logu wyzwala Twój skrypt monitorujący. Jeśli prowadzisz trzy domeny backendu gry z automatycznym odnawianiem certyfikatów, patrzysz na 18 alertów rocznie na domenę z własnej infrastruktury — każdy pojawiający się jako „nowy" certyfikat w logach.

Jeden z klientów Cloudflare opisał wyłączenie monitorowania CT na wszystkich swoich stronach, bo miał dość „spamu z tonami całkowicie normalnych odnowień certyfikatów", dodając: „Pod koniec nawet ich nie czytałem".

Gdy sygnał, na którym Ci zależy, to pojedynczy anomalny certyfikat zagrzebany w strumieniu automatycznych odnowień, których nie da się odróżnić z zewnątrz, system przestaje działać. Potrzebujesz sposobu na identyfikację i tłumienie alertów dla certyfikatów, które wydałeś sam.

Rozwiązanie: Odcisk SPKI do oddzielenia własnych certyfikatów od nieznanych

Cloudflare niedawno rozwiązał ten problem na dużą skalę, używając hashy SubjectPublicKeyInfo (SPKI) jako spójnego identyfikatora w swoich systemach wydawania certyfikatów i alertowania CT. To podejście generalizuje się na dowolną infrastrukturę, a deweloperzy gier zarządzający własnym zarządzaniem certyfikatami mogą przyjąć tę samą technikę.

Dlaczego proste wyszukiwanie nie działa

Pierwszym odruchem jest śledzenie wydanych certyfikatów w bazie danych i krzyżowe odwoływanie ich numerów seryjnych lub odcisków z wpisami w logach CT. Problem leży w timingu:

1. CA generuje pre-certyfikat i przesyła go do logów CT.
2. Log CT rejestruje pre-certyfikat.
3. CA osadza Signed Certificate Timestamps (SCT) w finalnym certyfikacie.
4. CA loguje finalny certyfikat.
5. CA dostarcza finalny certyfikat do Ciebie.

Zhashowany odcisk pre-certyfikatu i finalnego certyfikatu różnią się nieznacznie, ponieważ finalny certyfikat zawiera osadzone SCT, których pre-certyfikat nie miał. Jeśli Twój system monitorujący zobaczy wpis pre-certyfikatu w logu CT zanim CA dostarczy finalny certyfikat do Twojego systemu zamówień, nie ma rekordu do dopasowania. Dostajesz fałszywy alarm.

Hash SPKI: Jeden identyfikator obecny na każdym etapie

Hash SPKI rozwiązuje problem timingu, ponieważ klucz publiczny jest identyczny w pre-certyfikacie i finalnym certyfikacie. Jest generowany w momencie tworzenia klucza — zanim jakikolwiek certyfikat zostanie wydany — i nie zmienia się.

Identyfikator to: spki_sha256 = SHA-256(DER-encoded SubjectPublicKeyInfo)

Oto jak go obliczyć:

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

Przepływ monitorowania z filtrowaniem SPKI

Zaktualizowana architektura monitorowania działa tak:

Po Twojej stronie (wydawanie certyfikatów):

1. Wygeneruj nową parę kluczy dla każdego zamówienia certyfikatu.
2. Oblicz spki_sha256 z CSR lub klucza publicznego.
3. Zapisz hash w swojej bazie śledzenia natychmiast — zanim CA w ogóle zacznie wydawanie.
4. Przechowuj hashe przez cały okres ważności certyfikatu plus margines bezpieczeństwa (np. 30 dni po wygaśnięciu).

Po stronie monitorowania (skanowanie logów CT):

1. Parsuj nowe wpisy logów CT dla swoich domen.
2. Wyodrębnij klucz publiczny z każdego wpisu i oblicz spki_sha256.
3. Odwołaj się do hasha w swojej bazie śledzenia.
4. Znaleziono dopasowanie → ten certyfikat pochodzi z Twojej infrastruktury. Stłum alert.
5. Brak dopasowania → ten certyfikat nie został wydany przez Twój system. Podnieś alert.

To eliminuje fałszywe pozytywy z własnych odnowień bez pomijania naprawdę podejrzanych certyfikatów od zewnętrznych CA.

Pełny runbook: Konfiguracja monitorowania Certificate Transparency dla serwerów gier

Wymagania wstępne

• Lista wszystkich domen i subdomen używanych przez backend Twojej gry (w tym CDN, auth, matchmaking, telemetria, dostarczanie assetów)
• Python 3.9+ z bibliotekami requests i cryptography
• Endpoint alertujący (webhook Slack, webhook Discord, SMTP lub PagerDuty)
• Dostęp do systemu zarządzania certyfikatami w celu rejestrowania hashy SPKI w momencie wydania

Krok 1: Zinwentaryzuj swoją powierzchnię ataku

Przed monitorowaniem potrzebujesz pełnego inwentarza domen. Pominiesz jedną — pozostanie niemonitorowana. Typowe domeny backendu gry obejmują:

• api.yourgame.com — główne API gry
• auth.yourgame.com / login.yourgame.com — endpointy autoryzacji
• match.yourgame.com / lobby.yourgame.com — serwery matchmakingu i lobby
• cdn.yourgame.com / assets.yourgame.com — dostarczanie statycznych assetów
• telemetry.yourgame.com — analityka i raportowanie crashy
• status.yourgame.com — strona statusu (często osobna usługa)

Domeny wildcard (np. *.yourgame.com) poszerzają powierzchnię jeszcze bardziej. Każdy wildcardowy certyfikat pokrywający Twoją domenę jest wektorem ataku, jeśli zostanie błędnie wydany.

Krok 2: Skonfiguruj śledzenie hashy SPKI

Zintegruj rejestrowanie hashy ze swoim pipeline'em wdrażania certyfikatów. Za każdym razem, gdy certyfikat jest zamawiany lub generowany, oblicz i zapisz hash SPKI. Proste podejście to lokalna baza SQLite lub współdzielony klucz Redis:

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

Krok 3: Zbuduj pipeline alertujący

Połącz skrypt odpytywania CT z bazą hashy SPKI. Gdy nowy certyfikat pojawi się w logach CT:

1. Oblicz jego hash SPKI.
2. Sprawdź względem bazy znanych hashy.
3. Jeśli nieznany, alertuj natychmiast.
4. Dołącz link crt.sh, wystawcę, okno ważności i hostname w payloadzie alertu.

Kierowanie alertów do webhooka Slack lub Discord jest szybkie w konfiguracji i daje Twojemu zespołowi natychmiastową widoczność:

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)

Krok 4: Zdefiniuj playbook reagowania na incydenty

Gdy alert się wyzwoli, potrzebujesz udokumentowanej sekwencji reakcji. Fałszywy alarm kosztuje 5 minut analizy. Prawdziwe mis-issuance zignorowane kosztuje poświadczenia Twoich graczy.

Natychmiastowe działania (w ciągu 1 godziny od alertu):

1. Otwórz link crt.sh i zweryfikuj szczegóły certyfikatu (domena, wystawca, typ klucza, daty ważności).
2. Sprawdź, czy wystawca jest Ci znany. Nieznane CA, jak mało znany regionalny urząd wydający certyfikaty dla Twojej domeny .com, to czerwona flaga.
3. Sprawdź, czy certyfikat jest nadal ważny i osiągalny na porcie 443 względem rekordów DNS Twojej domeny (openssl s_client -connect yourgame.com:443 -servername yourgame.com).
4. Porównaj odcisk klucza publicznego certyfikatu ze swoimi znanymi, dobrymi kluczami.

Jeśli certyfikat jest nieautoryzowany:

1. Prześlij Certificate Problem Report do wydającego CA (większość CA ma kontakt abuse@ lub security@).
2. Równolegle skontaktuj się z CA przez ich interfejs webowy lub bezpośredni kanał eskalacji.
3. Jeśli CA nie odpowiada w ciągu 24 godzin, eskaluj do Forum CA/Browser lub programów root przeglądarek (kontakt Chromium Security w Chrome, skargi CA w Mozilli).
4. Jeśli mis-issuance było wynikiem błędu walidacji domeny (ktoś udowodnił własność, której nie miał), zrewiduj wszystkie swoje rekordy DNS i WHOIS pod kątem oznak kompromitacji.
5. Rozważ wdrożenie rekordów DNS CAA (Certificate Authority Authorization), aby ograniczyć, które CA mogą wydawać certyfikaty dla Twojej domeny:

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"

Rekordy CAA są sprawdzane przez zgodne CA przed wydaniem. Nie powstrzymają niezgodnego CA, ale znacząco zawężają powierzchnię ataku i uniemożliwiają mis-issuance od CA, które honorują rekordy CAA.

Krok 5: Zautomatyzuj zapobieganie nawrotom

Po obsłużeniu incydentu wzmocnij swoją postawę:

• Wdróż rekordy CAA dla wszystkich domen backendu gry (jeśli jeszcze ich nie ma).
• Włącz DNS-based Authentication of Named Entities (DANE) z rekordami TLSA, jeśli Twój dostawca DNS to wspiera — to wiąże konkretne klucze certyfikatów z Twoją domeną na poziomie DNS.
• Skróć własne okno odnawiania certyfikatów. Krótsze certyfikaty oznaczają mniejszy promień rażenia w przypadku kompromitacji klucza prywatnego.
• Loguj wszystkie zdarzenia wydawania certyfikatów z własnej infrastruktury jako wpisy audytowe z timestampami i hashami SPKI.

Najlepsze praktyki: Wzmacnianie zarządzania certyfikatami TLS dla serwerów gier

1. Monitoruj każdą domenę używaną przez Twoją grę, nie tylko główne API. Endpointy telemetrii, originy CDN, beacon'y analityczne i serwery stagingowe to wszystko powierzchnia ataku. Certyfikat wydany dla zapomnianej subdomeny jak old-matchmaking.yourgame.com może nadal być użyty do przechwytywania, jeśli ta domena rozwiązuje się na cokolwiek osiągalnego.

2. Wdróż rekordy DNS CAA dla każdej domeny, którą kontrolujesz. Pojedynczy rekord CAA 0 issue "letsencrypt.org" mówi zgodnym CA, aby odmówiły wydania od jakiegokolwiek innego urzędu. To pięciominutowa zmiana DNS, która blokuje całą klasę mis-issuance. Dodaj iodef, aby otrzymywać powiadomienia e-mail, gdy CA odrzuci żądanie wydania z powodu Twojej polityki CAA.

3. Przechowuj hashe SPKI z własnych certyfikatów w momencie wydania, nie po wdrożeniu. Okno między zalogowaniem pre-certyfikatu przez CA a otrzymaniem finalnego certyfikatu przez Twój system to miejsce, gdzie żyją fałszywe alarmy. Rejestrowanie hasha SPKI w momencie generowania klucza — zanim CSR zostanie w ogóle przesłany — eliminuje tę lukę całkowicie.

4. Ustaw kadencję monitorowania szybszą niż cykl odnawiania certyfikatów. Jeśli Twoje certyfikaty odnawiają się co 60 dni, sprawdzanie logów CT raz dziennie daje maksymalne opóźnienie detekcji 24 godziny. Dla produkcyjnych backendów gier, gdzie tokeny auth są najcenniejszym celem, to akceptowalne, ale nie idealne. Co 6 do 12 godzin to praktyczny sweet spot, biorąc pod uwagę opóźnienie indeksacji crt.sh.

5. Zintegruj alerty CT z istniejącym kanałem reagowania na incydenty. Monitorowanie CT, które wysyła e-maile na współdzieloną skrzynkę, której nikt nie sprawdza, jest gorsze niż bezużyteczne — tworzy fałszywe poczucie bezpieczeństwa. Kieruj alerty do tego samego kanału Slack lub Discord, który Twój zespół dyżurny już monitoruje pod kątem alertów o zdrowiu serwerów. (To odrębne od ogólnych protokołów naprawy crashy serwerów, ale kadencja reakcji powinna być podobna — wrażliwa na czas, udokumentowana, z jasnym właścicielem.)

Jak horizOn radzi sobie z zarządzaniem certyfikatami

Ręczne śledzenie hashy SPKI, odpytywanie logów CT, wdrażanie rekordów CAA i utrzymywanie playbooka reagowania na incydenty to realna praca — zwykle 2-3 tygodnie inżynierii infrastruktury dla małego zespołu. horizOn zajmuje się provisioningiem i odnawianiem certyfikatów TLS jako częścią swojej platformy backendowej dla deweloperów gier, co oznacza, że certyfikaty wydane przez platformę są już wewnętrznie śledzone. Strona monitorowania (czytanie logów CT pod kątem nieoczekiwanych wystawców) nadal wymaga zewnętrznych narzędzi, ale połowa układanki — wiedza o tym, które certyfikaty są Twoje — jest rozwiązana automatycznie.

Jeśli budujesz backend gry i chcesz uniknąć samodzielnego konfigurowania zarządzania certyfikatami, automatyzacji odnawiania i śledzenia SPKI, horizOn daje Ci gotowy fundament, abyś mógł skupić się na logice rozgrywki zamiast na hydraulice PKI.

Następne kroki

Zacznij od skryptu z tego posta. Skieruj go na domeny swojej gry już dziś i uruchom ręcznie, aby zobaczyć, co już jest w logach CT dla Twojej infrastruktury. Możesz być zaskoczony wolumenem historycznych certyfikatów — a przynajmniej poznasz swoją linię bazową, zanim zaczniesz automatyzować alerty. Następnie dodaj śledzenie hashy SPKI, aby filtrować własne odnowienia, a otrzymasz system monitorowania, który faktycznie wyciąga to, co istotne: certyfikaty, których się nie spodziewałeś, wydane przez CA, których nie wybrałeś.

---

Źródło: Certificate Transparency Monitoring is now generally available