المشكلة التي تحلّها CAA

مئات سلطات الشهادات (CAs) موثوقة من المتصفّحات الكبرى. أيّ منها، من حيث المبدأ، يستطيع إصدار شهادة SSL لأيّ نطاق — بما في ذلك نطاقك. معظمها مُدارة جيّداً؛ قلّة منها اختُرقت أو أصدرت شهادات بشكل خاطئ على مرّ السنين.

إن أصدرت CA خبيثة أو مُختَرَقة شهادة لـyourdomain.com، يستطيع مهاجم يحمل تلك الشهادة انتحال موقعك دون تحذير المتصفّحات للمستخدمين. هذا نموذج التهديد الذي تُعالجه سجلّات CAA.

سجلّ CAA (Certification Authority Authorization) إدخال DNS يسرد صراحةً أيّ CAs مسموح لها بإصدار شهادات لنطاقك. CAs مطالبة بالامتثال — إصدار شهادة لنطاق يحظر CAA الخاصّ به ذلك أساس لعدم ثقة المتصفّح بـCA نفسها.

كيف يبدو سجلّ CAA

سجلّ نمطي:

example.com. IN CAA 0 issue "letsencrypt.org"

قراءته: "معرّف CA هو letsencrypt.org. فقط Let's Encrypt يُصرَّح له بإصدار شهادات لـexample.com أو نطاقاته الفرعية".

تستطيع تحديد سجلّات CAA متعدّدة لتفويض CAs متعدّدة:

  • example.com. IN CAA 0 issue "letsencrypt.org"
  • example.com. IN CAA 0 issue "digicert.com"
  • example.com. IN CAA 0 issue "sectigo.com"

ولمنع إصدار wildcard بشكل منفصل:

  • example.com. IN CAA 0 issuewild "letsencrypt.org"

أنواع علامات CAA الثلاثة

  • issue: يُفوّض CA المُسمّى لإصدار شهادات عادية لهذا النطاق.
  • issuewild: يُفوّض CA المُسمّى لإصدار شهادات wildcard (*.example.com).
  • iodef: يُحدّد بريداً أو URL لـCA للاتّصال إن اكتُشف انتهاك.

العلم (الـ"0" في الأمثلة) تقني — اضبطه على 0 ما لم يكن لديك سبب محدّد لخلاف ذلك.

خدعة "لا CAs مسموح لها"

لمنع أيّ CA صراحةً من إصدار شهادات لنطاقك (مفيد للنطاقات المركونة أو التي يجب ألّا تُقدّم زيارات أبداً):

example.com. IN CAA 0 issue ";"

الفاصلة المنقوطة تعني "لا CA مُفوَّض". أيّ CA يستلم طلب إصدار لهذا النطاق يجب أن يرفض.

لماذا التبنّي منخفض

CAA إلزامية لـCAs منذ 2017. رغم ذلك، تبنّيها بين مالكي النطاقات ما زال تحت 20% حتّى 2026. الأسباب:

  • غير مرئية — لا عنصر واجهة يقول "يجب أن تُضيف هذا".
  • غير مطلوبة لعمل HTTPS — المواقع تعمل جيّداً بدون CAA.
  • تتطلّب فهم أيّ CAs تستخدمها بنيتك التحتية، وهو ما لا يتتبّعه معظم الملّاك.
  • بعض تنفيذات CAA المبكّرة كانت بها أخطاء كسرت إصدار الشهادات، ممّا جعل المُشغّلين حذرين.

النتيجة: الحماية متاحة على نطاق واسع ونادراً ما تُنشَر. سدّ هذه الفجوة على نطاقاتك يستغرق 5 دقائق.

كيف تضبط سجلّات CAA

الخطوة 1: حدّد CAs الخاصّة بك

أيّ سلطات شهادات تُصدر شهادات لنطاقك حالياً؟ افحص:

  • CDN الخاصّ بك (Cloudflare عادةً يستخدم Let's Encrypt أو Google Trust Services).
  • منصّة استضافتك (Vercel، Netlify، Heroku — عادةً Let's Encrypt).
  • أيّ شهادات صريحة اشتريتها (DigiCert، Sectigo، إلخ).
  • شغّل crt.sh?q=yourdomain.com لرؤية كلّ الشهادات الصادرة على الإطلاق — هذا السجلّ القانوني.

اعمل قائمة. معظم النطاقات تستخدم 1–2 CAs. بعضها يستخدم 3–4 عبر CDNs ومنصّات.

الخطوة 2: أضف سجلّات CAA

في لوحة مزوّد DNS، أضف سجلّات CAA لكلّ CA مُفوَّض. المعرّفات الشائعة:

  • Let's Encrypt: letsencrypt.org
  • Google Trust Services: pki.goog
  • DigiCert: digicert.com
  • Sectigo: sectigo.com
  • GlobalSign: globalsign.com
  • Cloudflare: cloudflare.com (لـSSL على نطاقات مُدارة من Cloudflare، وإن كان عادةً يُفوّض LE/GTS)
  • Amazon (ACM): amazon.com

إن كنت تستخدم واجهة DNS لـCloudflare، نوع سجلّ CAA في القائمة المنسدلة. نفس الشيء لـRoute 53 وDNSimple ومعظم المزوّدين الحديثين.

الخطوة 3: تحقّق

افحص سجلّات CAA الخاصّة بك بـ:

dig CAA example.com

المخرجات يجب أن تُظهر سجلّاتك المُهيَّأة. إن رأيتها، CAs التي تستعلم عن تفويض الإصدار سترى نفس الإجابة.

الخطوة 4: اختبر الإصدار

حاول تجديد شهادتك الحالية (أو فعّل إصداراً عبر منصّتك). يجب أن ينجح. إن فشل بخطأ متعلّق بـCAA، إمّا حذفت المُصدِر الفعلي أو استخدمت معرّفاً خاطئاً — أصلح وأعد المحاولة.

الحالات الأصعب

شهادات Wildcard

إن استخدمت شهادات wildcard (*.example.com)، تحتاج سجلّ issuewild بالإضافة إلى issue. تفويض wildcard منفصل عن التفويض العادي.

CAA للنطاقات الفرعية

سجلّات CAA تتدرّج: سجلّ على example.com يُطبَّق على api.example.com ما لم يكن لـapi.example.com سجلّ CAA خاصّ به. تستطيع أن تكون أكثر تقييداً على النطاقات الفرعية من القمّة إن لزم.

CAs متعدّدة عبر الخصائص

إن كانت قمّتك تستخدم Let's Encrypt ونطاق فرعي محدّد يستخدم DigiCert، تحتاج كليهما مُفوَّضاً — إمّا كلاهما عند القمّة (أوسع) أو منقسماً بين القمّة وسجلّات CAA للنطاق الفرعي (أضيق).

إضافة CA جديد

إن بدأت استخدام CA جديد (تسجيل في منصّة جديدة، تبديل CDNs)، أضف سجلّ CAA الخاصّ به أوّلاً، ثمّ فعّل الإصدار. دون تحديث CAA، الإصدار سيفشل.

أخطاء CAA الشائعة

  • نسيان تفويض CA الخاصّ بـCDN. قمّتك تستخدم LE؛ تُضيف CAA لـletsencrypt.org. ثمّ تضع Cloudflare أمامها وCloudflare يستخدم Google Trust Services — وتوفير الشهادة يفشل بصمت.
  • استخدام معرّف CA خاطئ. كلّ CA لديها سلسلة محدّدة. إملاؤها خطأً يُعطّل التفويض. راجع القائمة الرسمية قبل التهيئة.
  • ضبط CAA "لا CAs" على نطاق حيّ. يقفل كلّ إصدار شهادات. التجديدات ستفشل، تتركك بشهادة منتهية. اختبر دائماً على نطاق اختبار أوّلاً.
  • نسيان issuewild لـwildcards. الإصدار العادي يعمل؛ إصدار wildcard يفشل بصمت حتّى تُضيف سجلّ issuewild.

ما وراء CAA: قيود على مستوى الحساب

بعض CAs (خصوصاً Let's Encrypt وDigiCert) تدعم طبقة أكثر دقّة: قيود على مستوى الحساب. تستطيع تهيئة CAA بحيث فقط الشهادات الصادرة عبر حسابك المحدّد عند ذلك CA صالحة:

example.com. IN CAA 0 issue "letsencrypt.org;accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/12345"

الآن حتّى المهاجم الذي خدع Let's Encrypt بطريقة ما لا يستطيع إصدار شهادة تحت نطاقك ما لم يملك أيضاً حسابك. هذه خطوة معتبرة للأعلى للنطاقات عالية القيمة.

إجراء الـ5 دقائق

  1. حدّد CAs 1–2 التي يستخدمها نطاقك حالياً.
  2. أضف سجلّات CAA لتلك CAs في مزوّد DNS.
  3. تحقّق بـdig CAA yourdomain.com.
  4. اختبر بتفعيل أو انتظار تجديد شهادة.

هذا الإعداد كاملاً. الحماية حقيقية: مهاجم يخترق CA مختلفاً لا يستطيع إصدار شهادة صالحة لنطاقك. التكلفة صفر. الدفاع أحد أرخص المكاسب الأمنية على الويب الحديث — وهو مُهمَل على معظم النطاقات.