Oyun Sunucularında Yetkisiz TLS Sertifikaları: Certificate Transparency Günlükleri Güvenlik Duvarlarının Kaçırdığını Nasıl Yakalar

Şu anda, internetteki her alan adı için verilen her TLS sertifikasının halka açık, yalnızca eklenebilir bir günlüğü var — sizinki dahil. Yarın birisi bir Sertifika Otoritesine gidip api.yourgame.com için geçerli bir TLS sertifikası düzenletirse, bu sertifika dakikalar içinde Certificate Transparency (CT) günlüklerinde görünecektir. Tek soru, fark edip etmeyeceğiniz.

Çoğu oyun geliştiricisi fark etmez. Oyuncular SSL hataları bildirdiğinde, bir sızma testi uzmanı sorunu işaretlediğinde veya daha kötüsü — kötü niyetli bir sertifika, oyuncular ile giriş uç noktası arasında bir ortadaki adam proxy'si sağladığı için çalınan kimlik doğrulama token'ları ikincil piyasalarda görünmeye başladığında öğrenirler.

Bu yazı, oyun backend alan adlarınıza karşı Certificate Transparency günlüklerini izlemek için bir runbook'tur. CT günlüklerinin gerçekte ne olduğunu, programatik olarak nasıl sorgulanacağını, kendi rutin yenilemelerinizden gelen gürültüyü nasıl filtreleyeceğinizi ve yetkisiz sertifika verilmesini ihlal haline gelmeden önce yakalayan bir uyarı hattı oluşturmayı kapsar.

Ne Bozulur: Oyun Backend'lerine Karşı Yetkisiz TLS Sertifikası Verilmesi

Herkese açık olarak güvenilen bir Sertifika Otoritesi (CA) tarafından verilen her TLS sertifikası, en az iki halka açık Certificate Transparency günlüğüne kaydedilmelidir. Bu, Nisan 2018'de Chrome'un tüm yeni sertifikalar için CT dahil edilmesini zorunlu kılmaya başlamasından bu yana fiilen zorunludur. Apple Safari de benzer gereksinimlerle takip etti. Günlüğe kaydedilmeyen herhangi bir sertifika, büyük tarayıcılar tarafından güvenilmez.

CT ekosistemi, yanlış verilme — bir CA'nın, isteyenin kontrol etmediği bir alan adı için sertifika düzenlediği durumlar — tespit etmek için vardır. Oyun backend'leri için tehdit modeli şöyle görünür:

• Kimlik bilgisi ele geçirme: Bir saldırgan auth.yourgame.com için geçerli bir sertifika alır, oyuncular ile gerçek kimlik doğrulama sunucunuz arasında bir proxy kurar ve giriş token'larını toplar. Oyuncu için bağlantı meşru görünür çünkü tarayıcı sertifikaya güvenir.
• API taklidi: matchmaking.yourgame.com için bir sertifika, kötü niyetli bir tarafın TLS bağlantılarını sonlandırmasına, sahte oyun mantığı enjekte etmesine veya oyuncuları sahte bir sunucuya yönlendirmesine olanak tanır.
• Yeniden oynatma ve düşürme saldırıları: Geçerli bir sertifika ile saldırgan TLS'i kaldırabilir ve trafiği aktarabilir, böylece düzgün yapılandırılmış şifreli bir uç noktaya karşı başarısız olacak oturum yeniden oynatma veya protokol düşürme saldırılarını mümkün kılar.

Bu teorik değil. CT izleme, 2015'teki CNNIC MITM olayını ve Chrome'un tüm Symantec sertifikalarına güvenmemesine yol açan birden fazla Symantec yanlış verilmesini yakaladı. Ulus devlet CA ihlallerini yakalayan aynı mekanizma, bağımsız oyununuzun API sunucusu için de çalışır.

Certificate Transparency Nedir (ve Ne Değildir)

Certificate Transparency, kurduğunuz bir güvenlik aracı değildir. Katılımcı CA'lar tarafından verilen her sertifikayı kaydeden, herkese açık çalışan, kriptografik olarak denetlenebilir günlük sunucuları kümesidir. Bir sertifika verildiğinde şunlar olur:

1. CA bir ön sertifika üretir ve bunu bir veya daha fazla CT günlüğüne gönderir.
2. Her günlük, günlüğün sertifikayı kaydettiğine dair kriptografik bir taahhüt olan Signed Certificate Timestamp (SCT) döndürür.
3. CA bu SCT'leri final sertifikaya gömer ve isteyene verir.
4. Tarayıcılar, sertifikaya güvenmeden önce geçerli SCT'lerin mevcut olduğunu doğrular.

Bu günlük girişlerinin her biri herkese açık olarak sorgulanabilir. crt.sh gibi hizmetler, günlükler üzerinde ücretsiz bir arama arayüzü sağlar. Herkes — siz de dahil — belirli bir alan adı için verilmiş tüm sertifikaları arayabilir.

CT'nin YAPMADIĞI şey: yanlış verilmesini engellemez. Kötü sertifikaları iptal etmez. Tespit sağlar, önleme değil. Bu, birinin gerçekten günlükleri izlemesi ve bulduklarına göre hareket etmesi gerektiği anlamına gelir. O biri sizsiniz.

Nasıl Tespit Edilir: CT Günlüklerini Programatik Olarak Sorgulama

Certificate Transparency günlüklerini sorgulamanın en erişilebilir yolu, Sectigo tarafından işletilen crt.sh Certificate Search üzerinden geçer. Kimlik doğrulama gerektirmeyen bir JSON API sağlar. İşte alan adınız için CT günlüklerini sorgulayan ve beklenmeyen sertifika verilmelerini işaretleyen üretime hazır bir Python betiği:

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

Bunu her 12 saatte bir cron işiyle çalıştırın ve ilkel ama etkili bir CT izleme sistemine sahip olursunuz:

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

Bu Betiğin İyi Yaptığı Şeyler

• crt.sh'yi sorgular (ücretsiz, API anahtarı yok, makul yoklama oranları için sınırsız)
• Verilme zamanına göre filtreler böylece yalnızca son 72 saatteki sertifikaları görürsünüz
• Vericiyi bilinen iyi bir izin listesine karşı kontrol eder beklenmeyen CA'lardan gelen sertifikaları işaretlemek için
• Yapılandırılmış çıktı üretir Slack, Discord, PagerDuty veya e-postaya yönlendirebilirsiniz

Bu Betiğin Eksik Kaldığı Yerler

İzin listesi yaklaşımı yalnızca her vericiyi önceden biliyorsanız çalışır. Let's Encrypt'ten ZeroSSL'e geçerseniz yanlış alarm alırsınız. Ayrıca crt.sh'nin gecikmesi vardır — verilme ile günlükte görünme arasında genellikle 15 dakika ile birkaç saat, ayrıca crt.sh'nin girişi dizine eklemesi için ek süre. Gerçek zamanlı uyarı, doğrudan CT günlüğü izleme gerektirir ve bu önemli ölçüde daha karmaşıktır.

Ayrıca gürültü sorunu var ve neredeyse izleme modelini tamamen bozdu.

Gürültü Sorunu: Kendi Sertifikalarınızdan Kaynaklanan Uyarı Yorgunluğu

İşte çoğu CT izleme kurulumunu öldüren kısım: kendi meşru sertifikalarınızdan gelen gürültü.

TLS sertifikaları tasarım gereği kısa ömürlüdür. Standart bir Let's Encrypt sertifikası 90 gün geçerlidir ve 60. gün civarında otomatik olarak yenilenir. Cloudflare Universal SSL sertifikaları her 60 günde bir yenilenebilir — yılda yaklaşık altı kez. CA/Browser Forum, 2029'a kadar maksimum sertifika ömrünü 47 güne indirmeye karar verdi, bu da yenileme sıklığını neredeyse ikiye katlayacak.

Bu yenilemelerin her biri CT günlüklerinde görünür. Her günlük girişi izleme betiğinizi tetikler. Otomatik sertifika yenileme ile üç oyun backend alan adı çalıştırıyorsanız, kendi altyapınızdan alan adı başına yılda 18 uyarı alırsınız — her biri günlüklerde "yeni" bir sertifika olarak görünür.

Bir Cloudflare müşterisi, "tamamen normal sertifika yenilemeleriyle spam almak"tan yoruldukları için tüm sitelerinde CT izlemeyi devre dışı bıraktıklarını anlattı ve "Sonunda onları gerçekten okumuyordum bile" diye ekledi.

Önemsediğiniz sinyal, dışarıdan ayırt edemediğiniz otomatik yenilemeler akışına gömülü tek bir anormal sertifika olduğunda, sistem çalışmayı durdurur. Kendi verdiğiniz sertifikalar için uyarıları tanımlamanın ve bastırmanın bir yoluna ihtiyacınız var.

Çözüm: Sertifikalarınızı Bilinmeyenlerden Ayırmak için SPKI Parmak İzi

Cloudflare yakın zamanda bu sorunu, sertifika verilmesi ve CT uyarı sistemlerinde tutarlı bir tanımlayıcı olarak SubjectPublicKeyInfo (SPKI) hash'lerini kullanarak ölçekte çözdü. Yaklaşım herhangi bir altyapıya genelleştirilebilir ve kendi sertifika yönetimini sürdüren oyun geliştiricileri aynı tekniği benimseyebilir.

Basit Bir Arama Neden Çalışmaz

İlk içgüdü, verilen sertifikaları bir veritabanında izlemek ve seri numaralarını veya parmak izlerini CT günlük girişleriyle çapraz referanslamaktır. Sorun zamanlamadır:

1. Bir CA bir ön sertifika üretir ve CT günlüklerine gönderir.
2. CT günlüğü ön sertifikayı kaydeder.
3. CA, Signed Certificate Timestamps (SCT'ler) final sertifikaya gömer.
4. CA final sertifikayı günlüğe kaydeder.
5. CA final sertifikayı size teslim eder.

Ön sertifikanın ve final sertifikanın hash'lenmiş parmak izi biraz farklıdır, çünkü final sertifika, ön sertifikada olmayan gömülü SCT'leri içerir. İzleme sisteminiz, CA final sertifikayı sipariş sisteminize teslim etmeden önce CT günlüğündeki ön sertifika girişini görürse, eşleşecek bir kayıt yoktur. Yanlış alarm alırsınız.

SPKI Hash: Her Aşamada Görünen Tek Tanımlayıcı

SPKI hash, zamanlama sorununu çözer çünkü genel anahtar ön sertifikada ve final sertifikada aynıdır. Anahtar oluşturma zamanında — herhangi bir sertifika verilmeden önce — üretilir ve değişmez.

Tanımlayıcı şudur: spki_sha256 = SHA-256(DER-encoded SubjectPublicKeyInfo)

Nasıl hesaplanacağı aşağıda:

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

SPKI Filtreleme ile İzleme Akışı

Güncellenmiş izleme mimarisi şu şekilde çalışır:

Sizin tarafınızda (sertifika verilmesi):

1. Her sertifika siparişi için yeni bir anahtar çifti oluşturun.
2. CSR veya genel anahtardan spki_sha256 hesaplayın.
3. Hash'i hemen takip veritabanınıza kaydedin — CA verilmeye başlamadan önce.
4. Hash'leri sertifikanın ömrü boyunca artı bir güvenlik marjı (örneğin, sona ermeden 30 gün sonra) saklayın.

İzleme tarafında (CT günlüğü taraması):

1. Alan adlarınız için yeni CT günlük girişlerini ayrıştırın.
2. Her günlük girişinden genel anahtarı çıkarın ve spki_sha256 hesaplayın.
3. Hash'i takip veritabanınızda arayın.
4. Eşleşme bulundu → bu sertifika altyapınızdan geldi. Uyarıyı bastırın.
5. Eşleşme yok → bu sertifika sisteminiz tarafından verilmedi. Uyarı oluşturun.

Bu, harici CA'lardan gelen gerçekten şüpheli sertifikaları kaçırmadan kendi yenilemelerinizden kaynaklanan yanlış pozitifleri ortadan kaldırır.

Tam Runbook: Oyun Sunucuları için Certificate Transparency İzleme Kurulumu

Ön Koşullar

• Oyun backend'iniz tarafından kullanılan tüm alan adları ve alt alan adlarının listesi (CDN, kimlik doğrulama, eşleştirme, telemetri, varlık teslimi dahil)
• requests ve cryptography kütüphaneleriyle Python 3.9+
• Bir uyarı uç noktası (Slack webhook, Discord webhook, e-posta SMTP veya PagerDuty)
• Sertifika verilmesi sırasında SPKI hash'lerini kaydetmek için sertifika yönetim sisteminize erişim

Adım 1: Saldırı Yüzeyinizi Listeleyin

İzlemeye başlamadan önce, alan adlarının eksiksiz bir envanterine ihtiyacınız var. Birini kaçırırsanız, izlenmeden kalır. Yaygın oyun backend alan adları şunları içerir:

• api.yourgame.com — ana oyun API'si
• auth.yourgame.com / login.yourgame.com — kimlik doğrulama uç noktaları
• match.yourgame.com / lobby.yourgame.com — eşleştirme ve lobi sunucuları
• cdn.yourgame.com / assets.yourgame.com — statik varlık teslimi
• telemetry.yourgame.com — analitik ve çökme raporlama
• status.yourgame.com — durum sayfası (genellikle ayrı bir hizmet)

Joker alan adları (örneğin, *.yourgame.com) yüzeyi daha da genişletir. Alan adınızı kapsayan her joker sertifika, yanlış verilirse bir saldırı vektörüdür.

Adım 2: SPKI Hash Takibi Kurun

Hash kaydını sertifika dağıtım hattınıza entegre edin. Bir sertifika her istendiğinde veya oluşturulduğunda, SPKI hash'ini hesaplayın ve saklayın. Basit bir yaklaşım, yerel bir SQLite veritabanı veya paylaşılan bir Redis anahtarıdır:

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

Adım 3: Uyarı Hattını Oluşturun

CT sorgu betiğini SPKI veritabanı kontrolüyle birleştirin. CT günlüklerinde yeni bir sertifika göründüğünde:

1. SPKI hash'ini hesaplayın.
2. Bilinen hash'ler veritabanınıza karşı kontrol edin.
3. Bilinmiyorsa, hemen uyarı verin.
4. Uyarı yüküne crt.sh bağlantısını, vericiyi, geçerlilik penceresini ve ana bilgisayar adını ekleyin.

Uyarıları bir Slack veya Discord webhook'una yönlendirmek hızlı kurulur ve ekibinize anında görünürlük sağlar:

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)

Adım 4: Olay Müdahale Playbook'unuzu Tanımlayın

Bir uyarı tetiklendiğinde, belgelenmiş bir yanıt dizisine ihtiyacınız var. Yanlış alarm 5 dakikalık araştırma maliyetindedir. Göz ardı edilen gerçek bir yanlış verilme, oyuncularınızın kimlik bilgilerine mal olur.

Hemen yapılacaklar (uyarıdan sonraki 1 saat içinde):

1. crt.sh bağlantısını açın ve sertifika ayrıntılarını doğrulayın (alan adı, verici, anahtar türü, geçerli tarihler).
2. Vericinin tanıdık olup olmadığını kontrol edin. .com alan adınız için sertifika veren belirsiz bir bölgesel otorite gibi bilinmeyen CA'lar kırmızı bayraktır.
3. Sertifikanın hâlâ geçerli olup olmadığını ve alan adınızın DNS kayıtlarına karşı 443 numaralı bağlantı noktasında erişilebilir olup olmadığını kontrol edin (openssl s_client -connect yourgame.com:443 -servername yourgame.com).
4. Sertifikanın genel anahtar parmak izini bilinen iyi anahtarlarınızla karşılaştırın.

Sertifika yetkisizse:

1. Veren CA'ya bir Certificate Problem Report gönderin (çoğu CA'nın abuse@ veya security@ iletişimi vardır).
2. Aynı anda CA ile web arayüzü veya doğrudan yükseltme kanalı üzerinden iletişime geçin.
3. CA 24 saat içinde yanıt vermezse, CA/Browser Forum veya tarayıcı satıcılarının kök programlarına (Chrome'un Chromium Security iletişimi, Mozilla'nın CA Şikayetleri) yükseltin.
4. Yanlış verilme bir alan adı doğrulama hatasıysa (birisi sahip olmadığı bir sahipliği kanıtladıysa), tüm DNS ve WHOIS kayıtlarınızı uzlaşma belirtileri için denetleyin.
5. Alan adınız için hangi CA'ların sertifika verebileceğini kısıtlamak için CAA (Certificate Authority Authorization) DNS kayıtları dağıtmayı düşünün:

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 kayıtları, verilmeden önce uyumlu CA'lar tarafından kontrol edilir. Uyumlu olmayan bir CA'yı durdurmazlar, ancak saldırı yüzeyini önemli ölçüde daraltır ve CAA kayıtlarına uyan CA'lardan yanlış verilmesini imkânsız hale getirirler.

Adım 5: Tekrarlanma Önlemesini Otomatikleştirin

Bir olayı ele aldıktan sonra duruşunuzu güçlendirin:

• Tüm oyun backend alan adları için CAA kayıtları dağıtın (zaten yoksa).
• DNS sağlayıcınız destekliyorsa TLSA kayıtlarıyla DNS tabanlı Adlandırılmış Varlık Kimlik Doğrulaması (DANE) etkinleştirin — bu, belirli sertifika anahtarlarını DNS düzeyinde alan adınıza bağlar.
• Kendi sertifika yenileme pencerenizi kısaltın. Daha kısa ömürlü sertifikalar, tehlikeye giren özel anahtarın patlama yarıçapının daha küçük olduğu anlamına gelir.
• Kendi altyapınızdan tüm sertifika verilme olaylarını zaman damgaları ve SPKI hash'leriyle denetim izi girişleri olarak günlüğe kaydedin.

En İyi Uygulamalar: Oyun Sunucuları için TLS Sertifika Yönetimini Güçlendirme

1. Oyununuzun kullandığı her alan adını izleyin, yalnızca ana API'yi değil. Telemetri uç noktaları, CDN kökenleri, analitik işaretçileri ve hazırlama sunucuları saldırı yüzeyini temsil eder. old-matchmaking.yourgame.com gibi unutulmuş bir alt alan adı için verilen bir sertifika, bu alan adı erişilebilir herhangi bir şeye çözümleniyorsa yine de araya girme için kullanılabilir.
2. Kontrol ettiğiniz her alan adı için CAA DNS kayıtları dağıtın. Tek bir CAA 0 issue "letsencrypt.org" kaydı, uyumlu CA'lara başka herhangi bir otoriteden gelen verilme isteklerini reddetmelerini söyler. Bu, tüm bir yanlış verilme sınıfını engelleyen beş dakikalık bir DNS değişikliğidir. CAA politikanız nedeniyle bir CA verilme isteğini reddettiğinde e-posta bildirimleri almak için iodef ekleyin.
3. SPKI hash'lerini kendi sertifikalarınızdan dağıtımdan sonra değil, verilme zamanında saklayın. CA'nın ön sertifikayı günlüğe kaydetmesi ile sisteminizin final sertifikayı alması arasındaki pencere, yanlış alarmların yaşadığı yerdir. SPKI hash'ini anahtar oluşturma zamanında — CSR gönderilmeden önce — kaydetmek bu boşluğu tamamen ortadan kaldırır.
4. İzleme sıklığınızı sertifika yenileme döngünüzden daha hızlı ayarlayın. Sertifikalarınız her 60 günde bir yenileniyorsa, CT günlüklerini günde bir kez kontrol etmek size maksimum 24 saatlik tespit gecikmesi verir. Kimlik doğrulama token'larının en yüksek değerli hedef olduğu üretim oyun backend'leri için bu kabul edilebilir ancak ideal değildir. crt.sh'nin dizin oluşturma gecikmesi göz önüne alındığında her 6 ila 12 saatte bir pratik bir tatlı noktadır.
5. CT uyarılarını mevcut olay müdahale kanalınıza entegre edin. Kimsenin kontrol etmediği paylaşılan bir gelen kutusuna e-posta gönderen CT izleme, yararsızdan da kötüdür — sahte güven yaratır. Uyarıları, nöbetçi ekibinizin sunucu sağlığı uyarıları için zaten izlediği aynı Slack veya Discord kanalına yönlendirin. (Bu, genel sunucu çökme protokollerinden farklıdır, ancak yanıt sıklığı benzer olmalıdır — zamana duyarlı, belgelenmiş ve sahipli.)

horizOn Sertifika Yönetimini Nasıl Ele Alıyor

SPKI hash'lerini manuel olarak izlemek, CT günlüklerini sorgulamak, CAA kayıtları dağıtmak ve bir olay müdahale playbook'u sürdürmek gerçek bir iştir — küçük bir ekip için genellikle 2-3 haftalık altyapı mühendisliği. horizOn, oyun geliştiricileri için backend platformunun bir parçası olarak TLS sertifika sağlama ve yenilemeyi yönetir; bu, platform aracılığıyla verilen sertifikaların dahili olarak zaten izlendiği anlamına gelir. İzleme tarafı (beklenmeyen vericiler için CT günlüklerini okumak) hâlâ harici araçlar gerektirir, ancak bulmacanın yarısı — hangi sertifikaların sizin olduğunu bilmek — otomatik olarak çözülür.

Bir oyun backend'i kuruyorsanız ve sertifika yönetimi, yenileme otomasyonu ve SPKI takibini kendiniz yapmaktan kaçınmak istiyorsanız, horizOn size önceden oluşturulmuş bir temel sağlar; böylece PKI tesisatı yerine oyun mantığına odaklanabilirsiniz.

Sonraki Adımlar

Bu yazıdaki betikle başlayın. Bugün oyununuzun alan adlarına yönlendirin ve altyapınız için CT günlüklerinde zaten ne olduğunu görmek için manuel olarak çalıştırın. Tarihsel sertifikaların hacmine şaşırabilirsiniz — ve en azından uyarıları otomatikleştirmeye başlamadan önce temel çizginizin neye benzediğini bileceksiniz. Ardından kendi yenilemelerinizi filtrelemek için SPKI hash takibini ekleyin ve gerçekten önemli olanı yüzeye çıkaran bir izleme sistemine sahip olacaksınız: beklemediğiniz, seçmediğiniz CA'lar tarafından verilen sertifikalar.

---

Kaynak: Certificate Transparency Monitoring artık genel olarak kullanılabilir