خطای 526 کلودفلر چیست؟ رفع مشکل گواهی سرور بدون خاموش‌کردن امنیت

سایت پشت Cloudflare قرار دارد و به‌جای صفحه سایت پیام Error 526: Invalid SSL certificate دیده می‌شود. در حالت معمول، این پیام می‌گوید کلودفلر نتوانسته گواهی ارائه‌شده توسط سرور اصلی سایت را طبق تنظیمات اعتبارسنجی کند. ممکن است تاریخ گواهی گذشته باشد، نام آن با نام مورد انتظار فرق کند یا سرور گواهی و زنجیره درست را ارائه ندهد.

دو اتصال جدا را تصور کنید: مرورگر شما به Cloudflare وصل می‌شود و Cloudflare نیز به سرور اصلی یا Origin متصل می‌شود. سبز بودن اتصال مرورگر در زمانی دیگر، به‌تنهایی ثابت نمی‌کند گواهی مسیر دوم درست است. راهکار پایدار این است که گواهی مناسب روی سرور اصلی نصب و بررسی شود.

اگر فقط بازدیدکننده هستید، زمان خطا و نشانی صفحه را به صاحب سایت بگویید. مراحل زیر برای مدیر دامنه یا سرور است و بسته به پنل و تنظیمات واقعی شما تفاوت دارد.

نشانی کامل، زمان همراه منطقه زمانی و در صورت نمایش، Ray ID را یادداشت کنید. اگر خطا 522 است، موضوع اصلی زمان انتظار اتصال به سرور است و راهنمای خطای ۵۲۲ مناسب‌تر است. خطای ۵۲۶ در حالت معمول به اعتبارسنجی گواهی origin مربوط می‌شود. مستندات Cloudflare درباره 526 شرایط و علت‌های رایج آن را توضیح می‌دهد.

در پنل Cloudflare به بخش SSL/TLS ← Overview بروید و حالت فعلی و تنظیمات احتمالی Origin Rule را بخوانید. در حالت Full (strict)، Cloudflare باید گواهی origin را طبق شرایط آن معتبر تشخیص دهد. پیش از تغییر هر گزینه، مقدار فعلی را ثبت کنید. تغییر به حالت غیرسخت‌گیرانه ممکن است نشانه را پنهان کند ولی اعتبارسنجی گواهی سرور اصلی را تضعیف می‌کند؛ برای رفع دائمی، علت گواهی را اصلاح کنید.

در پنل هاست یا اطلاعات مدیر سرور، نام سایتی را که باید روی origin پاسخ بدهد، IP سرور و نوع گواهی نصب‌شده را پیدا کنید. اگر قانون Origin Rule یا تنظیم سفارشی نام میزبان و SNI وجود دارد، نامی که Cloudflare برای ارتباط استفاده می‌کند ممکن است با فرض اولیه شما فرق کند. آن تنظیم را نیز در بررسی لحاظ کنید.

IPهایی که از DNS عمومی یک رکورد پراکسی‌شده برمی‌گردند معمولاً نشانی شبکه Cloudflare هستند؛ آن‌ها را بدون تطبیق با پنل هاست، IP اصلی سرور فرض نکنید. اگر چند سرور پشت یک نام یا Load Balancer دارید، ممکن است فقط یکی گواهی اشتباه داشته باشد و خطا گاهی دیده شود؛ هر مقصد واقعی باید جدا بررسی شود.

در پنل مدیریت گواهی سرور یا خروجی ابزار مدیر سرور، این موارد را بررسی کنید:

۱. نام‌ها: نام مورد انتظار باید در نام‌های گواهی پوشش داده شده باشد. گواهی *.example.com معمولاً یک سطح مانند shop.example.com را پوشش می‌دهد، نه خود example.com یا api.shop.example.com؛ مگر نام‌های لازم جداگانه در گواهی ثبت شده باشند. ۲. تاریخ اعتبار: تاریخ شروع و پایان گواهی و هر گواهی میانی لازم را ببینید. منقضی‌شدن یکی از اجزای زنجیره می‌تواند مشکل بسازد. ۳. مرجع و زنجیره: گواهی باید از مرجعی باشد که Cloudflare برای اتصال origin می‌پذیرد و زنجیره موردنیاز به‌درستی ارائه شود. گواهی خودامضای تصادفی در حالت معمول Full strict کافی نیست. ۴. محل نصب: صدور موفق در پنل کافی نیست؛ همان گواهی باید روی میزبان و پورت واقعی نصب و توسط وب‌سرور ارائه شود. ممکن است وب‌سرور هنوز گواهی قبلی یا گواهی سایت دیگری را نشان دهد.

Cloudflare Origin CA یکی از گزینه‌های قابل استفاده برای اتصال Cloudflare به origin است، اما مرورگر معمولی ممکن است آن را برای اتصال مستقیم کاربر به سرور قابل اعتماد نداند. اگر به دسترسی مستقیم عمومی نیز نیاز دارید، گواهی و معماری را با مدیر سرویس هماهنگ کنید. کلید خصوصی گواهی را در فضای عمومی یا تیکت قرار ندهید.

اگر مدیر سرور اجازه اتصال مستقیم از شبکه شما را داده و ابزار openssl در دسترس است، برای بررسی گواهی ارائه‌شده روی یک origin می‌توانید از نمونه زیر استفاده کنید. نام و IP نمونه را با مقصد واقعی و مجاز خودتان جایگزین کنید:

این فرمان در ترمینال لینوکس اتصال TLS به IP مشخص را امتحان می‌کند و با -servername نام میزبان را برای انتخاب گواهی می‌فرستد. -verify_hostname هم تطبیق نام را بررسی می‌کند. اگر سرور فقط اتصال از شبکه Cloudflare را مجاز بداند، آزمون از رایانه شما ممکن است قطع شود؛ این نتیجه به‌تنهایی خرابی گواهی را ثابت نمی‌کند.

اگر origin از Cloudflare Origin CA استفاده می‌کند، مجموعه گواهی‌های قابل اعتماد رایانه شما ممکن است آن مرجع را نشناسد. در این صورت خطای اعتماد در تست مستقیم را باید با زنجیره Origin CA معتبر و روش مستند همان سرویس تفسیر کرد، نه اینکه بررسی گواهی را خاموش کنیم. همچنین در معماری دارای Origin Rule، نام SNI و hostname مؤثر را از تنظیم واقعی بردارید.

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

اگر مدیریت سرور با شماست، گواهی معتبر و زنجیره موردنیاز را طبق مستندات وب‌سرور و ارائه‌دهنده گواهی نصب کنید. پیش از تغییر، مسیر فایل‌ها و تنظیمات قبلی را ثبت کنید و پس از ویرایش، آزمون تنظیمات وب‌سرور را اجرا کنید. برای مثال فقط در سروری که Nginx مسئول سایت است، فرمان آزمون پیکربندی به شکل زیر است:

این فرمان تنظیمات Nginx را آزمایش می‌کند؛ به‌تنهایی ثابت نمی‌کند Cloudflare گواهی صحیح را می‌بیند. پس از موفقیت، بازخوانی تنظیمات باید مطابق روش و زمان مناسب همان سرویس انجام شود. اگر سایت روی هاست اشتراکی است و این دسترسی را ندارید، نام دامنه، زمان، خطا و وضعیت گواهی را به مدیر هاست بدهید.

با حفظ حالت اعتبارسنجی مناسب، آدرس عادی سایت را از مسیر Cloudflare باز کنید. صفحه اصلی و نامی را که قبلاً خطا می‌داد چند بار در بازه وقوع مشکل آزمایش کنید. اگر چند سرور origin دارید، هرکدام را نیز با روش مجاز بررسی کنید. ناپدیدشدن یک خطا برای یک درخواست، به‌تنهایی سلامت همه مسیرها را ثابت نمی‌کند.

اگر همچنان ۵۲۶ می‌بینید، نام مؤثر، تاریخ، زنجیره، مسیر نصب و قانون origin را دوباره با خروجی همان سرور تطبیق دهید. از قرار دادن کلید خصوصی یا رمز در تصویر گزارش خودداری کنید. اگر تغییر تنظیم وب‌سرور مشکل تازه ساخت، نسخه قبلی را با برنامه بازگشت برگردانید و دوباره اتصال را بسنجید.

برای بررسی مشخصات میزبانی سایت، صفحه هاست وردپرس نت‌آرام را ببینید. نوع و محل گواهی به تنظیم واقعی سایت و استفاده از پراکسی بستگی دارد.