حالت‌های SSL در CDN؛ Flexible، Full یا Full Strict، کدام را انتخاب کنیم؟

دو اتصال، نه یکی

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

1. اتصال اول: از مرورگر کاربر تا سرور لبهٔ CDN. گواهی این بخش را CDN مدیریت می‌کند و قفل مرورگر فقط دربارهٔ همین بخش است.
2. اتصال دوم: از سرور لبهٔ CDN تا سرور اصلی شما (Origin). این بخش برای کاربر نامرئی است و نحوهٔ برقراری آن را «حالت SSL» در تنظیمات CDN تعیین می‌کند.

اگر اتصال دوم رمزنگاری نشده باشد، داده‌های کاربران، از جمله رمزها و اطلاعات فرم‌ها، در فاصلهٔ CDN تا سرور شما به‌صورت متن ساده عبور می‌کنند، در حالی که کاربر قفل امن را می‌بیند. به همین دلیل انتخاب حالت SSL تصمیم امنیتی مهمی است. اگر با معماری CDN آشنا نیستید، ابتدا CDN چیست را بخوانید.

دو اتصال در مسیر CDN

حالت Off

هیچ HTTPSی وجود ندارد؛ نه بین کاربر و CDN و نه بین CDN و سرور. امروزه مرورگرها چنین سایت‌هایی را «ناامن» نشان می‌دهند، فرم‌ها هشدار می‌دهند و موتورهای جست‌وجو هم HTTPS را ترجیح می‌دهند. جز برای آزمایش، دلیلی برای این حالت وجود ندارد.

حالت Flexible: امنیت ظاهری

در Flexible، کاربر با HTTPS به CDN وصل می‌شود، اما CDN با HTTP ساده روی پورت ۸۰ به سرور شما وصل می‌شود. مزیتش این است که روی سرور به هیچ گواهی‌ای نیاز ندارید؛ به همین دلیل گزینهٔ وسوسه‌انگیزی برای شروع سریع است.

اما Flexible دو مشکل جدی دارد:

• امنیت ناقص: نیمهٔ دوم مسیر رمزنگاری نشده است. هر کسی در مسیر بین دیتاسنتر CDN و سرور شما بتواند ترافیک را ببیند، داده‌ها را به‌صورت متن ساده می‌بیند.
• حلقهٔ ریدایرکت: اگر سرور یا برنامهٔ شما (مثلاً وردپرس، لاراول یا تنظیمات Nginx) همهٔ درخواست‌های HTTP را به HTTPS ریدایرکت کند، چون CDN همیشه با HTTP درخواست می‌دهد، سرور دائماً ریدایرکت برمی‌گرداند و مرورگر خطای ERR_TOO_MANY_REDIRECTS نشان می‌دهد. این یکی از رایج‌ترین مشکلات پس از فعال‌سازی CDN است.

Flexible را فقط به‌عنوان راه‌حل موقت و وقتی واقعاً امکان نصب گواهی روی سرور ندارید در نظر بگیرید.

حالت Full: رمزنگاری بدون بررسی هویت

در Full، CDN با HTTPS روی پورت ۴۴۳ به سرور شما وصل می‌شود، اما گواهی سرور را اعتبارسنجی نمی‌کند. یعنی گواهی می‌تواند خودامضا (Self-signed)، منقضی یا برای دامنهٔ دیگری باشد و اتصال همچنان برقرار می‌شود.

این حالت رمزنگاری را تأمین می‌کند و جلوی شنود ساده را می‌گیرد، اما در برابر حملهٔ مرد میانی (Man-in-the-Middle) محافظتی ندارد؛ کسی که بتواند خودش را جای سرور شما جا بزند، با هر گواهی‌ای پذیرفته می‌شود. Full از Flexible بسیار بهتر است، اما هنوز بهترین انتخاب نیست.

چهار حالت SSL از ضعیف به قوی

Offبدون HTTPS در هیچ بخش

FlexibleHTTPS تا CDN، سپس HTTP ساده تا سرور

FullHTTPS تا سرور، بدون بررسی گواهی

Full (Strict)HTTPS تا سرور با گواهی معتبر؛ توصیه‌شده

حالت Full (Strict): انتخاب درست

در Full Strict، CDN با HTTPS به سرور وصل می‌شود و گواهی را کامل بررسی می‌کند: باید معتبر باشد، منقضی نشده باشد و برای همان دامنه صادر شده باشد. این تنها حالتی است که کل مسیر را واقعاً امن می‌کند.

برای استفاده از Full Strict، سرور اصلی به یکی از این دو نوع گواهی نیاز دارد:

• گواهی عمومی معتبر، مثل Let's Encrypt که رایگان است و خودکار تمدید می‌شود. مراحل صدور آن را در آموزش Nginx و Let's Encrypt ببینید. نکته: وقتی دامنه پشت CDN است، روش اعتبارسنجی HTTP-01 معمولاً از طریق CDN هم کار می‌کند، اما اگر CDN مسیر /.well-known/acme-challenge/ را کش یا مسدود کند، به مشکل می‌خورید؛ روش DNS-01 در این حالت مطمئن‌تر است.
• گواهی مبدأ (Origin Certificate) که خود CDN صادر می‌کند. فقط CDN به آن اعتماد دارد و مرورگرها آن را نمی‌شناسند، اما چون کاربران هرگز مستقیم به سرور شما وصل نمی‌شوند، اشکالی ندارد. اعتبار طولانی دارد و نیاز به تمدید مکرر ندارد.

جدول مقایسه

مهاجرت از Flexible به Full Strict بدون قطعی

اگر سایت شما الان روی Flexible است، به این ترتیب جابه‌جا شوید:

1. روی سرور، گواهی معتبر (Let's Encrypt یا گواهی مبدأ CDN) نصب کنید و Nginx را برای گوش دادن روی ۴۴۳ پیکربندی کنید.
2. از روی سرور یا با تغییر موقت فایل hosts کامپیوتر خود، مطمئن شوید سایت روی HTTPS مستقیم پاسخ درست می‌دهد.
3. در CDN حالت را به Full تغییر دهید و سایت را بررسی کنید.
4. اگر همه‌چیز درست بود، حالت را به Full Strict ببرید.
5. ریدایرکت HTTP به HTTPS را ترجیحاً در خود CDN فعال کنید (گزینه‌ای مثل Always Use HTTPS) تا دوبار ریدایرکت نشود.

خطاهای رایج پس از تغییر حالت

• ERR_TOO_MANY_REDIRECTS: تقریباً همیشه Flexible به‌همراه ریدایرکت HTTPS روی سرور است. حالت را به Full یا Full Strict تغییر دهید.
• خطای 525 یا 526 (در برخی CDNها): CDN نمی‌تواند دست‌دهی SSL با سرور را کامل کند یا گواهی سرور نامعتبر است. گواهی، تاریخ انقضا و نام دامنه روی سرور را بررسی کنید.
• خطای 521 یا 522: سرور روی پورت ۴۴۳ پاسخ نمی‌دهد یا فایروال آی‌پی‌های CDN را مسدود کرده است.

برای عیب‌یابی کامل‌تر، خطاهای 5xx در CDN و قطعی سایت بعد از فعال‌سازی CDN را بخوانید.

مهاجرت از Flexible به Full Strict

1. نصب گواهی روی سرور

   Let's Encrypt یا گواهی مبدأ CDN؛ Nginx روی ۴۴۳.

2. تست مستقیم

   با فایل hosts مطمئن شوید سرور روی HTTPS پاسخ می‌دهد.

3. تغییر به Full

   سایت را بررسی کنید.

4. تغییر به Full Strict

   اگر خطای گواهی ندیدید، حالت نهایی را فعال کنید.

5. ریدایرکت در CDN

   HTTP به HTTPS را در خود CDN انجام دهید.

HSTS: قدم بعدی، با احتیاط

پس از اینکه مطمئن شدید سایت به‌طور کامل و پایدار روی HTTPS کار می‌کند، می‌توانید هدر HSTS را فعال کنید. این هدر به مرورگر می‌گوید برای مدت مشخصی هرگز با HTTP به سایت وصل نشود؛ در نتیجه حتی اولین درخواست هم مستقیم با HTTPS ارسال می‌شود و فرصت حملهٔ تنزل پروتکل از بین می‌رود.

اما HSTS را عجولانه فعال نکنید. اگر بعداً مشکلی در گواهی پیش بیاید یا بخواهید موقتاً HTTPS را خاموش کنید، مرورگرهایی که هدر را دیده‌اند تا پایان مدت تعیین‌شده سایت را باز نمی‌کنند. با مدت کوتاه شروع کنید، گزینهٔ includeSubDomains را فقط وقتی اضافه کنید که همهٔ زیردامنه‌ها HTTPS دارند و بعد از اطمینان کامل، مدت را افزایش دهید.

گام آخر: بستن دسترسی مستقیم به سرور

پس از راه‌اندازی درست Full Strict، بهتر است سرور اصلی فقط به درخواست‌های CDN پاسخ دهد. با محدود کردن پورت‌های ۸۰ و ۴۴۳ در فایروال به محدودهٔ آی‌پی‌های CDN، یا با استفاده از گواهی کلاینت (Authenticated Origin Pulls) در CDNهایی که پشتیبانی می‌کنند، مهاجم نمی‌تواند با پیدا کردن آی‌پی سرور، CDN و محافظت‌هایش را دور بزند.

CDN اختصاصی کلودیفای اتصال کاربر را روی پورت ۴۴۳ با TLS برقرار می‌کند و با صورتحساب به‌ازای مصرف کار می‌کند؛ مراحل اتصال دامنهٔ اختصاصی در راهنمای تنظیم CNAME آمده است.

سؤالات متداول