مشكلة في طلب الشهادة بسبب تعارض CNAME و TXT
Categories:
لا يمكن لـ CNAME و TXT ذات البادئة نفسها العيش معًا
ربما يعرف من يتعاملون مع المجالات أنه لا يمكن لسجلات (A، AAAA) العيش مع سجلات CNAME، ولكن ربما لا يعرفون عن تعارض TXT مع CNAME.
في أي حالة يمكن لـ TXT أن تستخدم نفس البادئة مع CNAME؟
هناك حالة واحدة، وهي عند طلب شهادة LetsEncrypt باستخدام تحدي DNS-01 للتحقق من ملكية المجال.
- سيستخدم Certbot مفتاح ackey و acsecret أو token لإنشاء سجل TXT لـ
_acme-challenge.example.com - ستحقق Letsencrypt من سجل TXT للتأكد من أن الطرف المُقدِم له الحق في إنشاء سجل DNS، وبالتالي إثبات ملكيته للمجال.
- تصدر Letsencrypt الشهادة
- يقوم Certbot بتنظيف سجل TXT لـ
_acme-challenge.example.com
إذا كان هناك بالفعل سجل CNAME لـ _acme-challenge.example.com عند إنشاء سجل TXT، فقد يفشل إنشاء سجل TXT، مما يؤدي إلى فشل التحقق من التحدي للمجال.
لماذا يوجد سجل CNAME لـ _acme-challenge.example.com؟
أطلقت Alibaba Cloud مؤخرًا ESA (Edge Security Acceleration)، مشابهة لـ Cloudflare، وهي نسخة مطورة من DCDN (التسريع الشامل). في البداية، لم تدعم ESA طلب شهادات Wildcard، لذلك كنت أستخدم نصوصًا لنقل شهادات Wildcard التي أحصل عليها دوريًا إلى ESA، مما يجعل الإدارة صعبة بعض الشيء. لاحقًا، ظهرت خاصية “إدارة DCV”، والتي تسمح بطلب وتحديث شهادات Wildcard ذاتيًا. وفقًا للتعليمات، يمكن بالفعل إدارة شهادات Wildcard ذاتيًا. ولكن كان هناك خطر مخفي ظل غير مكتشف لعدة أشهر. هذا السجل CNAME يستمر في الوجود، مما يؤدي إلى عدم القدرة على إنشاء سجل TXT بنفس البادئة، وبالتالي لا يمكنني إثبات ملكية المجال في أماكن أخرى.
الحلول
الحل الأول: عدم استخدام إدارة DCV
تتطلب إدارة DCV إدخال قيمة محددة لـ _acme-challenge.example.com، وجوهرها هو الإعلان عن أن هذا المجال ينتمي إلى طرف ثالث، وأنك لم تعد تملك السيطرة عليه.
إذا كنت بحاجة إلى شهادة Wildcard، يمكنك استخدام نصوص مهام لاستدعاء API الخاص بـ ESA وتحميل شهادة Wildcard إلى ESA بشكل دوري.
الحل الثاني: عدم استخدام التحقق DNS-01 من ملكية المجال
يوفر Certbot عدة طرق للتحقق من ملكية المجال (Challenge)، إلى جانب التحقق من الجذر DNS-01، يمكن أيضًا استخدام طرق مثل HTTP-01 و TLS-ALPN-01.
تتطلب طرق HTTP-01 و TLS-ALPN-01 وجود خدمة أولاً، ثم التحقق من إمكانية الوصول قبل إصدار الشهادة.
يمكن لـ DNS-01 الحصول على الشهادة قبل إعداد الخدمة.
الحل الثالث: كسر الحائط بين ESA و DNS في Cloud Resolver
هاتان الخدمتان تنتميان إلى Alibaba Cloud، لكن كل منهما نفذ واجهة DNS API منفصلة. إذا كان بإمكان ESA إعداد سجلات CNAME أو TXT في Cloud Resolver ذاتيًا، والحصول على الشهادة ثم حذف السجلات، فلن يؤثر ذلك على استخدام تحدي DNS-01 في أماكن أخرى.
الحل الرابع: عدم استخدام ESA من Alibaba
لا توجد مثل هذه المشكلة على Cloudflare، فالشهادات متوفرة بحرية.