شهادات TLS المارقة على خوادم الألعاب: كيف تلتقط سجلات Certificate Transparency ما تفوته جدران الحماية

في هذه اللحظة، يوجد سجل عام قابل للإلحاق فقط (append-only) لكل شهادة TLS صادرة لكل نطاق على الإنترنت — بما في ذلك نطاقك. إذا ذهب شخص غدًا إلى جهة إصدار شهادات (Certificate Authority) وأقنعها بإصدار شهادة TLS صالحة لواجهة برمجة تطبيقات لعبتك على api.yourgame.com، ستظهر تلك الشهادة في سجلات Certificate Transparency (CT) خلال دقائق. السؤال الوحيد هو: هل ستلاحظ ذلك؟

معظم مطوري الألعاب لن يلاحظوا. يكتشفون الأمر عندما يبلغ اللاعبون عن أخطاء SSL، أو عندما يشير مختبِر الاختراق إلى المشكلة، أو الأسوأ — عندما تبدأ رموز المصادقة المسروقة في الظهور في الأسواق الثانوية لأن شهادة خبيثة مكّنت وكيل وسيط (man-in-the-middle) بين اللاعبين ونقطة تسجيل الدخول.

هذا المقال هو دليل تشغيلي (runbook) لمراقبة سجلات Certificate Transparency مقابل نطاقات الواجهة الخلفية للعبتك. يشرح ما هي سجلات CT في الواقع، وكيفية الاستعلام عنها برمجيًا، وكيفية تصفية الضوضاء الناتجة عن تجديداتك الروتينية، وكيفية بناء خط تنبيه يلتقط إصدارات الشهادات غير المصرح بها قبل أن تتحول إلى اختراقات.

ما المشكلة: إصدار شهادات TLS غير مصرح بها ضد الواجهات الخلفية للألعاب

يجب تسجيل كل شهادة TLS صادرة عن جهة إصدار شهادات موثوقة عمومًا (CA) في سجلّي Certificate Transparency عامين على الأقل. أصبح هذا إلزاميًا فعليًا منذ أبريل 2018، عندما بدأ Chrome في اشتراط تضمين CT لجميع الشهادات الجديدة. تبعته Apple Safari بمتطلبات مماثلة. أي شهادة غير مسجلة لن تثق بها المتصفحات الرئيسية.

يوجد نظام CT البيئي لاكتشاف الإصدار الخاطئ (mis-issuance) — أي المواقف التي تُصدر فيها جهة CA شهادة لنطاق لا يتحكم فيه مقدم الطلب. بالنسبة للواجهات الخلفية للألعاب، يبدو نموذج التهديد كما يلي:

• اعتراض بيانات الاعتماد: يحصل المهاجم على شهادة صالحة لـ auth.yourgame.com، وينشئ وكيلًا بين اللاعبين وخادم المصادقة الحقيقي، ويجمع رموز تسجيل الدخول. بالنسبة للاعب، يبدو الاتصال شرعيًا لأن المتصفح يثق بالشهادة.
• انتحال واجهة API: شهادة لـ matchmaking.yourgame.com تسمح لطرف خبيث بإنهاء اتصالات TLS وحقن منطق لعبة مزيف أو إعادة توجيه اللاعبين إلى خادم مزيف.
• هجمات إعادة التشغيل (Replay) وخفض الإصدار (Downgrade): بوجود شهادة صالحة في اليد، يمكن للمهاجم إزالة TLS وتمرير حركة المرور، مما يتيح إعادة تشغيل الجلسة أو هجمات خفض إصدار البروتوكول التي كانت ستفشل ضد نقطة نهاية مشفرة ومهيأة بشكل صحيح.

هذا ليس نظريًا. رصد CT التقط حادثة CNNIC MITM في 2015 والعديد من حالات الإصدار الخاطئ من Symantec التي أدت إلى عدم ثقة Chrome بجميع شهادات Symantec. الآلية نفسها التي تكتشف اختراقات هيئات إصدار الشهادات على مستوى الدول تعمل مع خادم API للعبتك المستقلة.

ما هي Certificate Transparency (وما ليست عليه)

Certificate Transparency ليست أداة أمان تقوم بتثبيتها. إنها مجموعة من خوادم السجلات العامة القابلة للتدقيق التشفيري التي تسجل كل شهادة تصدرها هيئات CA المشاركة. إليك ما يحدث عند إصدار شهادة:

1. تُنشئ هيئة CA شهادة مسبقة (pre-certificate) وتُرسلها إلى سجل CT واحد أو أكثر.
2. يُرجع كل سجل طابعًا زمنيًا موقّعًا للشهادة (SCT) — وهو وعد تشفيري بأن السجل قد سجّل الشهادة.
3. تدمج هيئة CA هذه الـ SCTs في الشهادة النهائية وتصدرها لمقدم الطلب.
4. تتحقق المتصفحات من وجود SCTs صالحة قبل الثقة بالشهادة.

كل إدخال من هذه الإدخالات في السجلات قابل للاستعلام علنًا. خدمات مثل crt.sh توفر واجهة بحث مجانية عبر السجلات. أي شخص — بما فيهم أنت — يمكنه البحث عن جميع الشهادات التي صدرت لنطاق معين.

ما لا تفعله CT: لا تمنع الإصدار الخاطئ. لا تلغي الشهادات السيئة. إنها توفر الكشف، وليس المنع. هذا يعني أن شخصًا ما يجب أن يراقب السجلات فعليًا ويتصرف بناءً على ما يجده. وهذا الشخص هو أنت.

كيفية اكتشاف ذلك: الاستعلام عن سجلات CT برمجيًا

الطريقة الأسهل للاستعلام عن سجلات Certificate Transparency هي عبر crt.sh، وهو بحث الشهادات، الذي تشغله Sectigo. يوفر واجهة برمجة تطبيقات JSON لا تتطلب مصادقة. إليك سكربت Python جاهز للإنتاج يستعلم سجلات CT لنطاقك ويعلّم عن إصدارات الشهادات غير المتوقعة:

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

شغّل هذا عبر وظيفة cron كل 12 ساعة، وستحصل على نظام مراقبة CT بدائي لكنه فعّال:

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

ما يجيده هذا السكربت

• يستعلم crt.sh (مجاني، بدون مفتاح API، غير محدود لمعدلات استعلام معقولة)
• يصفّي حسب وقت الإصدار بحيث ترى فقط الشهادات من آخر 72 ساعة
• يفحص جهة الإصدار مقابل قائمة مسموح بها معروفة لتمييز الشهادات الصادرة عن هيئات CA غير متوقعة
• يُخرج بيانات منظمة يمكنك توجيهها إلى Slack أو Discord أو PagerDuty أو البريد الإلكتروني

أين يقصّر هذا السكربت

نهج القائمة المسموح بها يعمل فقط إذا كنت تعرف كل جهة إصدار مسبقًا. إذا انتقلت من Let's Encrypt إلى ZeroSSL، فستحصل على إنذار كاذب. كما أن crt.sh لديه زمن استجابة — عادة من 15 دقيقة إلى بضع ساعات بين الإصدار وظهور السجل، بالإضافة إلى وقت إضافي ليفهرس crt.sh الإدخال. التنبيه في الوقت الفعلي يتطلب مراقبة مباشرة لسجلات CT، وهو أكثر تعقيدًا بشكل كبير.

هناك أيضًا مشكلة الضوضاء، وقد كادت أن تكسر نموذج المراقبة بالكامل.

مشكلة الضوضاء: إرهاق التنبيهات من شهاداتك الخاصة

إليك الجزء الذي يقتل معظم إعدادات مراقبة CT: الضوضاء الناتجة عن شهاداتك الشرعية.

شهادات TLS قصيرة العمر بطبيعتها. شهادة Let's Encrypt القياسية صالحة لمدة 90 يومًا وتتجدد تلقائيًا حول اليوم 60. شهادات Cloudflare Universal SSL يمكن أن تتجدد كل 60 يومًا — أي حوالي ست مرات سنويًا. صوّت منتدى CA/Browser Forum على خفض الحد الأقصى لعمر الشهادة إلى 47 يومًا بحلول 2029، مما سيضاعف تقريبًا وتيرة التجديد.

كل واحد من هذه التجديدات يظهر في سجلات CT. كل إدخال في السجل يشغّل سكربت المراقبة. إذا كنت تدير ثلاثة نطاقات للواجهة الخلفية للعبة مع تجديد تلقائي للشهادات، فأنت تنظر إلى 18 تنبيهًا سنويًا لكل نطاق من بنيتك التحتية الخاصة — كل واحد يظهر كشهادة "جديدة" في السجلات.

وصف أحد عملاء Cloudflare أنه عطّل مراقبة CT عبر جميع مواقعه لأنه سئم من "تلقي كميات هائلة من تجديدات الشهادات الطبيعية تمامًا"، مضيفًا: "لم أكن حتى أقرأها في النهاية."

عندما تكون الإشارة التي تهمك هي شهادة شاذة واحدة مدفونة في تيار من التجديدات التلقائية التي لا يمكنك تمييزها من الخارج، يتوقف النظام عن العمل. تحتاج إلى طريقة لتحديد وكتم التنبيهات للشهادات التي أصدرتها بنفسك.

الحل: بصمة SPKI للفصل بين شهاداتك والشهادات غير المعروفة

حلّت Cloudflare هذا مؤخرًا على نطاق واسع باستخدام تجزئات SubjectPublicKeyInfo (SPKI) كمعرّف ثابت عبر أنظمة إصدار الشهادات والتنبيه بـ CT لديها. هذا النهج قابل للتعميم على أي بنية تحتية، ويمكن لمطوري الألعاب الذين يديرون شهاداتهم الخاصة تبنّي نفس الأسلوب.

لماذا لا يكفي البحث البسيط

أول ما يخطر بالبال هو تتبع الشهادات الصادرة في قاعدة بيانات ومطابقة أرقامها التسلسلية أو بصماتها مع إدخالات سجلات CT. المشكلة هي التوقيت:

1. تُنشئ هيئة CA شهادة مسبقة وتُرسلها إلى سجلات CT.
2. يسجّل سجل CT الشهادة المسبقة.
3. تدمج هيئة CA طوابع Signed Certificate Timestamps (SCTs) في الشهادة النهائية.
4. تسجّل هيئة CA الشهادة النهائية.
5. تُسلّم هيئة CA الشهادة النهائية إليك.

تختلف البصمة المشفرة للشهادة المسبقة عن الشهادة النهائية قليلًا، لأن الشهادة النهائية تحتوي على SCTs المدمجة التي لم تكن موجودة في الشهادة المسبقة. إذا رأى نظام المراقبة لديك إدخال الشهادة المسبقة في سجل CT قبل أن تُسلّم هيئة CA الشهادة النهائية إلى نظام الطلبات لديك، فلن يكون هناك سجل للمطابقة. ستحصل على إنذار كاذب.

تجزئة SPKI: معرّف واحد يظهر في كل مرحلة

تجزئة SPKI تحل مشكلة التوقيت لأن المفتاح العام متطابق في الشهادة المسبقة والشهادة النهائية. يتم إنشاؤه في وقت إنشاء المفتاح — قبل إصدار أي شهادة — ولا يتغير.

المعرّف هو: spki_sha256 = SHA-256(DER-encoded SubjectPublicKeyInfo)

إليك كيفية حسابه:

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

تعمل بنية المراقبة المحدّثة على النحو التالي:

من جانبك (إصدار الشهادات):

1. أنشئ زوج مفاتيح جديدًا لكل طلب شهادة.
2. احسب spki_sha256 من CSR أو المفتاح العام.
3. خزّن التجزئة في قاعدة بيانات التتبع فورًا — قبل أن تبدأ هيئة CA الإصدار حتى.
4. احتفظ بالتجزئات طوال عمر الشهادة بالإضافة إلى هامش أمان (مثل 30 يومًا بعد انتهاء الصلاحية).

من جانب المراقبة (فحص سجلات CT):

1. اقرأ إدخالات سجلات CT الجديدة لنطاقاتك.
2. استخرج المفتاح العام من كل إدخال واحسب spki_sha256.
3. ابحث عن التجزئة في قاعدة بيانات التتبع.
4. تم العثور على تطابق → هذه الشهادة صادرة عن بنيتك التحتية. أكتم التنبيه.
5. لا يوجد تطابق → هذه الشهادة لم تصدر عن نظامك. أطلق تنبيهًا.

هذا يلغي الإيجابيات الكاذبة من تجديداتك الخاصة دون تفويت الشهادات المشبوهة حقًا الصادرة عن هيئات CA خارجية.

دليل تشغيلي كامل: إعداد مراقبة Certificate Transparency لخوادم الألعاب

المتطلبات الأساسية

• قائمة بجميع النطاقات والنطاقات الفرعية المستخدمة في الواجهة الخلفية للعبتك (بما في ذلك CDN والمصادقة والمطابقة والقياس وتوصيل الأصول)
• Python 3.9+ مع مكتبتي requests و cryptography
• نقطة تنبيه (Slack webhook أو Discord webhook أو بريد SMTP أو PagerDuty)
• وصول إلى نظام إدارة الشهادات لديك لتسجيل تجزئات SPKI وقت الإصدار

الخطوة 1: حصر سطح الهجوم لديك

قبل المراقبة، تحتاج إلى جرد كامل للنطاقات. إذا فاتك نطاق واحد، فسيظل غير مراقب. نطاقات الواجهة الخلفية الشائعة للألعاب تشمل:

• api.yourgame.com — واجهة API الرئيسية للعبة
• auth.yourgame.com / login.yourgame.com — نقاط نهاية المصادقة
• match.yourgame.com / lobby.yourgame.com — خوادم المطابقة واللوبي
• cdn.yourgame.com / assets.yourgame.com — توصيل الأصول الثابتة
• telemetry.yourgame.com — التحليلات والإبلاغ عن الأعطال
• status.yourgame.com — صفحة الحالة (غالبًا خدمة منفصلة)

النطاقات البدل (مثل *.yourgame.com) توسّع السطح أكثر. كل شهادة بدل تغطي نطاقك هي ناقل هجوم إذا صدرت بشكل خاطئ.

الخطوة 2: إعداد تتبع تجزئة SPKI

أدمج تسجيل التجزئة في خط أنابيب نشر الشهادات لديك. في كل مرة يتم طلب شهادة أو إنشاؤها، احسب تجزئة SPKI وخزّنها. النهج البسيط هو قاعدة بيانات SQLite محلية أو مفتاح 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

الخطوة 3: بناء خط التنبيه

ادمج سكربت استعلام CT مع فحص قاعدة بيانات SPKI. عندما تظهر شهادة جديدة في سجلات CT:

1. احسب تجزئة SPKI الخاصة بها.
2. تحقق من قاعدة بيانات التجزئات المعروفة لديك.
3. إذا كانت غير معروفة، أطلق تنبيهًا فورًا.
4. تضمين رابط crt.sh وجهة الإصدار وفترة الصلاحية واسم المضيف في حمولة التنبيه.

توجيه التنبيهات إلى Slack أو Discord webhook سريع الإعداد ويمنح فريقك رؤية فورية:

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)

الخطوة 4: حدد دليل الاستجابة للحوادث

عندما يُطلق تنبيه، تحتاج إلى تسلسل استجابة موثق. الإنذار الكاذب يكلف 5 دقائق من التحقيق. الإصدار الخاطئ الحقيقي الذي يتم تجاهله يكلف بيانات اعتماد لاعبيك.

إجراءات فورية (خلال ساعة واحدة من التنبيه):

1. افتح رابط crt.sh وتحقق من تفاصيل الشهادة (النطاق، جهة الإصدار، نوع المفتاح، التواريخ الصالحة).
2. تحقق مما إذا كانت جهة الإصدار معروفة لديك. هيئات CA غير المعروفة مثل سلطة إقليمية غامضة تصدر شهادات لنطاق .com الخاص بك هي علامة حمراء.
3. تحقق مما إذا كانت الشهادة لا تزال صالحة ويمكن الوصول إليها على المنفذ 443 عبر سجلات DNS لنطاقك (openssl s_client -connect yourgame.com:443 -servername yourgame.com).
4. قارن بصمة المفتاح العام للشهادة مع مفاتيحك المعروفة والصالحة.

إذا كانت الشهادة غير مصرح بها:

1. أرسل تقرير مشكلة شهادة (Certificate Problem Report) إلى هيئة CA المُصدرة (معظم هيئات CA لديها جهة اتصال abuse@ أو security@).
2. في نفس الوقت، تواصل مع هيئة CA عبر واجهة الويب أو قناة التصعيد المباشرة.
3. إذا لم تستجب هيئة CA خلال 24 ساعة، صعّد الأمر إلى منتدى CA/Browser Forum أو برامج الجذور لموردي المتصفحات (جهة اتصال Chromium Security في Chrome، وشكاوى CA في Mozilla).
4. إذا كان الإصدار الخاطئ ناتجًا عن فشل في التحقق من النطاق (شخص أثبت ملكية لا يملكها)، فدقق جميع سجلات DNS وWHOIS لديك بحثًا عن علامات الاختراق.
5. فكر في نشر سجلات CAA (Certificate Authority Authorization) في DNS لتقييد هيئات CA التي يمكنها إصدار شهادات لنطاقك:

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 يتم فحصها بواسطة هيئات CA الملتزمة قبل الإصدار. لن توقف هيئة CA غير ملتزمة، لكنها تضيّق سطح الهجوم بشكل كبير وتجعل الإصدار الخاطئ من هيئات CA التي تحترم سجلات CAA مستحيلًا.

الخطوة 5: أتمتة منع التكرار

بمجرد التعامل مع حادثة، قوّي وضعك الأمني:

• انشر سجلات CAA لجميع نطاقات الواجهة الخلفية للألعاب (إذا لم تكن موجودة بالفعل).
• فعّل مصادقة الكيانات المسماة المستندة إلى DNS (DANE) مع سجلات TLSA حيث يدعم مزود DNS الخاص بك ذلك — وهذا يربط مفاتيح شهادات محددة بنطاقك على مستوى DNS.
• قصّر نافذة تجديد الشهادات الخاصة بك. الشهادات قصيرة العمر تعني أن نصف قطر الانفجار للمفتاح الخاص المخترق أصغر.
• سجّل جميع أحداث إصدار الشهادات من بنيتك التحتية كإدخالات مسار تدقيق مع طوابع زمنية وتجزئات SPKI.

أفضل الممارسات: تقوية إدارة شهادات TLS لخوادم الألعاب

1. راقب كل نطاق تستخدمه لعبتك، ليس فقط واجهة API الرئيسية. نقاط نهاية القياس، وأصول CDN، وإشارات التحليلات، وخوادم الاختبار كلها تمثل سطح هجوم. الشهادة الصادرة لنطاق فرعي منسي مثل old-matchmaking.yourgame.com يمكن استخدامها للاعتراض إذا كان هذا النطاق يحل إلى أي شيء يمكن الوصول إليه.

2. انشر سجلات CAA في DNS لكل نطاق تتحكم فيه. سجل واحد CAA 0 issue "letsencrypt.org" يخبر هيئات CA الملتزمة برفض طلبات الإصدار من أي سلطة أخرى. هذا تغيير DNS يستغرق خمس دقائق يحجب فئة كاملة من الإصدار الخاطئ. أضف iodef لتلقي إشعارات البريد الإلكتروني عندما ترفض هيئة CA طلب إصدار بسبب سياسة CAA الخاصة بك.

3. خزّن تجزئات SPKI من شهاداتك الخاصة وقت الإصدار، وليس بعد النشر. النافذة بين تسجيل هيئة CA للشهادة المسبقة واستلام نظامك للشهادة النهائية هي المكان الذي تعيش فيه الإنذارات الكاذبة. تسجيل تجزئة SPKI في وقت إنشاء المفتاح — قبل إرسال CSR حتى — يزيل هذه الفجوة تمامًا.

4. اجعل وتيرة المراقبة أسرع من دورة تجديد الشهادات. إذا كانت شهاداتك تتجدد كل 60 يومًا، فإن فحص سجلات CT مرة يوميًا يعطيك أقصى زمن اكتشاف يبلغ 24 ساعة. بالنسبة للواجهات الخلفية للألعاب في الإنتاج حيث تكون رموز المصادقة هي الهدف الأعلى قيمة، هذا مقبول لكنه ليس مثاليًا. كل 6 إلى 12 ساعة هو النطاق الأمثل عمليًا بالنظر إلى زمن فهرسة crt.sh.

الخطوات التالية

ابدأ بالسكربت في هذا المقال. وجّهه إلى نطاقات لعبتك اليوم وشغّله يدويًا لترى ما هو موجود بالفعل في سجلات CT لبنيتك التحتية. قد تتفاجأ بحجم الشهادات التاريخية — وستعرف على الأقل كيف تبدو خط الأساس لديك قبل أن تبدأ في أتمتة التنبيهات. ثم أضف تتبع تجزئة SPKI لتصفية تجديداتك الخاصة، وستحصل على نظام مراقبة يُظهر فعليًا ما يهم: شهادات لم تتوقعها، صادرة عن هيئات CA لم تخترها.

---

المصدر: مراقبة Certificate Transparency أصبحت متاحة بشكل عام الآن