خطای CAA در صدور SSL؛ بررسی DNS و سی‌پنل

خطای CAA هنگام صدور SSL دو مسیر مهم دارد: رکوردِ مؤثر، صادرکنندهٔ گواهی را مجاز نمی‌کند؛ یا جست‌وجوی CAA در DNS با خطا روبه‌رو شده و صادرکننده نمی‌تواند مجوز را تشخیص دهد. ابتدا متن دقیق خطا، نام دامنه و نام مرجع صدور گواهی را مشخص کنید؛ سپس پاسخ عمومی CAA را بخوانید. حذف همهٔ رکوردهای CAA، راه‌حل عمومی و امن این مسئله نیست.

این راهنما برای تشخیص پیش از تغییر است؛ در آن رکوردی ویرایش نمی‌کنیم و AutoSSL را اجرا نمی‌کنیم. برای مبانی گواهی، راهنمای SSL به زبان ساده و برای گردش کار عمومی سی‌پنل، آموزش بررسی AutoSSL را ببینید.

۱. اول خطای واقعی و نام دقیق را پیدا کنید

در سی‌پنل، بخش SSL/TLS Status را باز کنید. در رابط یکپارچهٔ جدید، مسیر SSL/TLS Certificates → Status است.
نام دامنه را جست‌وجو و ستون Certificate Status را بخوانید. نام اصلی و www ممکن است نتیجه‌های متفاوتی داشته باشند.
متن کامل خطا و زمان آن را یادداشت کنید. اگر نام CAA در پیام نیست، صرف صادرنشدن گواهی را خطای CAA ننامید.
مرجع صدور یا CA مورد استفاده را از تنظیمات معتبر سرویس یا پشتیبانی بگیرید. AutoSSL نام فرایند خودکار است؛ نام یک CA نیست.

زبانهٔ واقعی Status در SSL/TLS Certificates سی‌پنل با نام‌های دامنهٔ بلورشده و ستون Certificate Status — عکس واقعی از محیط هاست مجاز؛ این ردیف‌ها وضعیت عادی AutoSSL Domain Validated دارند و نمونهٔ خطای CAA نیستند. تصویر محل خواندن وضعیت را نشان می‌دهد؛ اطلاعات دامنه بلور شده است.

در مستند رسمی SSL/TLS Status، نمایش این صفحه به‌صورت مستقل یا زبانهٔ رابط یکپارچه توضیح داده شده است. اگر خطای آخرین اجرای AutoSSL برای دامنه ثبت شده باشد، ستون وضعیت می‌تواند آن را نمایش دهد. برای تهیهٔ عکس بالا هیچ درخواست صدور یا تمدیدی اجرا نشده است.

۲. پاسخ عمومی CAA را بدون تغییر تنظیمات بخوانید

CAA یا Certification Authority Authorization سیاست مجازبودن صادرکنندگان گواهی را در DNS بیان می‌کند؛ رکورد آدرس سایت یا محتوای گواهی نیست. تعریف استاندارد آن در RFC8659 آمده است.

ابزار رسمی Google Public DNS را باز کنید.
در DNS Name، نام عمومیِ دقیقِ ذکرشده در خطا را وارد کنید؛ بدون https:// و مسیر صفحه.
در RR Type مقدار CAA را انتخاب و Resolve را بزنید. گزینهٔ Disable DNSSEC validation باید خاموش بماند.
ابتدا Status و سپس Answer را بخوانید. نام، نوع سؤال و زمان بررسی را کنار نتیجه نگه دارید.

بخشی از پاسخ واقعی CAA دامنهٔ عمومی letsencrypt.org در Google Public DNS شامل Status صفر و رکوردهای issue و issuewild — برش پاسخ واقعیِ دامنهٔ عمومی letsencrypt.org در زمان تهیهٔ آموزش؛ فقط بخشی از فهرست Answer نشان داده شده است. این مقادیر، الگوی آمادهٔ تنظیم DNS سایت شما نیستند.

در این نمونهٔ واقعی، سؤال از نوع 257 یعنی CAA و پاسخ Status: 0 بود. در بخش data، هم issuewild و هم issue دیده می‌شود. معنی فیلدهای JSON را می‌توانید در مرجع رسمی پاسخ DNS گوگل بررسی کنید. بازشدن صفحهٔ ابزار یا HTTP200، به‌تنهایی موفقیت پرس‌وجوی DNS را ثابت نمی‌کند.

حریم خصوصی: فقط نام‌های عمومی را در ابزار عمومی وارد کنید؛ نام داخلی سازمان و دادهٔ مشتری را نفرستید. این پرس‌وجو تنظیمات DNS دستگاه یا رکوردهای دامنه را تغییر نمی‌دهد.

۳. سه جزء رکورد را درست تفسیر کنید

برای خواندن شکل رکورد، این مثال آموزشی را در نظر بگیرید؛ دستور اجرا یا پیشنهاد تغییر فوری نیست:


0 issue "letsencrypt.org"

عدد اول Flags، واژهٔ بعدی Tag و رشتهٔ آخر Value است. اگر پرچم بحرانی با مقدار 128 روی یک تگ ناشناخته یا پشتیبانی‌نشده تنظیم شده باشد، مرجع صدور سازگار نباید برای آن نام گواهی صادر کند؛ وجود این پرچم را هم هنگام بررسی سیاست CAA در نظر بگیرید. شناسهٔ CAA برای Let’s Encrypt در راهنمای رسمی CAA آن مرجع، letsencrypt.org اعلام شده است؛ برای CA دیگر، شناسه را از مستند همان صادرکننده بگیرید، نه از نام شرکت هاست.

چیزی که می‌بینید	برداشت درست
issue	مجوز صدور عادی را مشخص می‌کند؛ اگر issuewild موجود نباشد، برای wildcard هم اثر دارد.
issuewild	سیاست صدور wildcard را مشخص می‌کند و در آن حالت بر issue اولویت دارد؛ برای نام عادی بررسی نمی‌شود.
چند رکورد issue	مجوزها جمع می‌شوند؛ صرف وجود چند صادرکننده تعارض نیست. باید CA موردنظر مجاز باشد.
0 issue “;”	این ردیف صادرکننده‌ای را مجاز نمی‌کند؛ اگر issue مجازکنندهٔ دیگری نباشد، صدور عادی محدود می‌شود. مجموعهٔ کامل را بخوانید.

جزئیات مجوز تهی و جمع‌شدن مجوزها در RFC8659 تعریف شده است. اگر Value پارامترهایی مانند validationmethods یا accounturi دارد، فقط دیدن نام CA کافی نیست؛ محدودیت روش اعتبارسنجی یا حساب نیز باید بررسی شود. پارامترها را برای رفع خطا بی‌بررسی حذف نکنید.

۴. فقط رکورد دامنهٔ اصلی را بررسی نکنید

گواهی ممکن است برای چند نام درخواست شده باشد. طبق استاندارد CAA، مجوز هر نامِ داخل درخواست باید بررسی شود؛ سالم‌بودن نام اصلی، وضعیت www یا wildcard را ثابت نمی‌کند.

زیردامنه: اگر CAA روی نام دقیق نباشد، جست‌وجو به سمت والدها ادامه پیدا می‌کند و نخستین مجموعهٔ CAA پیدا‌شده اهمیت دارد. خالی‌بودن پاسخِ یک نام، پایان بررسی نیست.
CNAME: مسیر نام مستعار هم در یافتن پاسخ مؤثر نقش دارد؛ مقصد CNAME را از قلم نیندازید.
چند سرویس گواهی: ممکن است گواهی لبهٔ CDN و گواهی هاست را صادرکنندگان متفاوتی ارائه کنند؛ سیاست باید نیاز واقعی هر دو مسیر را در نظر بگیرد.

برای زمینهٔ CDN و اثر سیاست CAA بر صدور گواهی، راهنمای CAA در Cloudflare را ببینید. فهرست صادرکنندگان یک سرویس را به همهٔ سایت‌ها تعمیم ندهید.

۵. خطای جست‌وجو را از ممنوعیت صدور جدا کنید

نتیجهٔ بررسی	قدم بعدی
پاسخ موفق و CAA مؤثر موجود است	CA، نوع عادی یا wildcard و محدودیت‌های Value را با درخواست تطبیق دهید.
پاسخ موفق، بدون CAA برای نام پرسیده‌شده	والدها و نام مستعار را بررسی کنید؛ هنوز نمی‌توان نبود هرگونه سیاست را نتیجه گرفت.
SERVFAIL	اول علت شکست DNS را پیدا کنید؛ افزودن یک مجوز دیگر لزوماً مشکل جست‌وجو را حل نمی‌کند.
timeout	پاسخ در مهلت نرسیده؛ مسیر و نیم‌سرورهای مرجع باید بررسی شوند.

Let’s Encrypt در بخش خطاهای CAA توضیح می‌دهد که حتی دامنهٔ بدون رکورد CAA هم ممکن است هنگام این بررسی خطای DNS داشته باشد. برای مسیر SERVFAIL، آموزش تشخیص خطای SERVFAIL در DNS را دنبال کنید؛ خاموش‌کردن DNSSEC روش عمومی رفع این وضعیت نیست.

آنچه واقعاً آزمایش شد: در پرس‌وجوهای فقط‌خواندنیِ این آموزش، CAA برای letsencrypt.org پاسخ و رکورد داشت؛ برای example.com پاسخ موفق بدون رکورد CAA برگشت؛ و برای نام آزمایشیِ دارای DNSSEC معیوبِ dnssec-failed.org پاسخ SERVFAIL دریافت شد. این‌ها نمونهٔ تفاوت پاسخ‌ها هستند؛ هیچ صدور گواهی یا اصلاح دامنهٔ مشتری آزمایش نشده است.

۶. در سی‌پنل کجا را مشاهده کنید؟

ابتدا مشخص کنید DNS دامنه واقعاً کجا مدیریت می‌شود. اگر مرجع فعال سرویس دیگری است، تغییر در Zone محلی این هاست جواب عمومی را اصلاح نمی‌کند.

در سی‌پنل از بخش Domains وارد Zone Editor شوید.
کنار دامنه، Manage را باز کنید.
نام رکورد و ستون Type را کنترل کنید. A، MX و TXT جایگزین CAA نیستند؛ CAA باید نوع مستقل خود را داشته باشد.
اگر رابط فیلتر CAA ندارد، صرف نبود این دکمه را نبود پشتیبانی یا نبود رکورد ندانید. فهرست و صفحه‌بندی را بررسی و نتیجهٔ DNS عمومی را هم تطبیق دهید.

فهرست واقعی Manage Zone در سی‌پنل با ستون Type و مقادیر خصوصی بلورشده؛ ردیف‌های A و MX و CNAME در قاب دیده می‌شوند — عکس واقعی Manage Zone؛ قاب، ستون نوع رکورد و محل مشاهدهٔ مقادیر را نشان می‌دهد و نمونهٔ رکورد CAA نیست. در این رابط، میان‌بُر فیلتر CAA وجود نداشت. اطلاعات دامنه، نیم‌سرورها و مقادیر بلور شده‌اند؛ هیچ Edit، Delete یا Save اجرا نشده است.

ساختار جدول و پشتیبانی نوع CAA در مرجع رسمی Zone Editor آمده است؛ دسترسی رابط می‌تواند به تنظیمات ارائه‌دهنده وابسته باشد. آموزش عمومی رکوردها در راهنمای مدیریت DNS در سی‌پنل قرار دارد.

۷. اصلاح هدفمند را چطور پیگیری کنید؟

به‌جای درخواست «همهٔ CAAها را پاک کنید»، گزارش مشخص بدهید: نام خطادار، زمان، CA موردنیاز، درخواست عادی یا wildcard، مجموعهٔ مؤثر CAA و نتیجهٔ جست‌وجوی DNS. اگر درخواست چند نام دارد، نامِ ناموفق را جدا مشخص کنید.

CAA مجوز لازم را ندارد: مسئول DNS باید سیاست موجود و نیاز سرویس‌های دیگر را بررسی و اصلاح محدودِ همان مجوز را طراحی کند؛ حذف کلی سیاست لازم نیست.
جست‌وجو شکست می‌خورد: گزارش را به ارائه‌دهندهٔ DNS بدهید؛ قبل از دستکاری مجوز، پاسخ‌گویی و اعتبارسنجی DNS بررسی شود.
بعد از اصلاح: همان نام‌ها و نوع CAA دوباره بررسی شوند؛ سپس وضعیت درخواست گواهی طبق فرایند مجاز سرویس پیگیری شود. نتیجهٔ DNS به‌تنهایی اثبات صدور موفق نیست.

قبل از هر تغییر مدیریتی: رکورد مؤثر فعلی، TTL، وابستگی سرویس‌ها، مقدار موردنیاز از مستند CA، شرط توقف و راه بازگرداندن همان رکورد باید مشخص باشد. این آموزش تغییر عملیاتی DNS یا صدور مکرر گواهی را انجام نمی‌دهد؛ کلید خصوصی، رمز و توکن هم برای تشخیص CAA لازم نیست به اشتراک گذاشته شوند.

۸. پرسش‌های رایج

چون سایتم باز می‌شود، CAA حتماً درست است؟

خیر. بازشدن سایت و معتبر‌بودن گواهی فعلی، مجازبودن یک درخواست صدور یا تمدید جدید با CA مشخص را ثابت نمی‌کند؛ پاسخ و سیاست مربوط به همان درخواست را بررسی کنید.