آموزش فعالسازی SSL در Cloudflare؛ تنظیم HTTPS، SSL/TLS و رفع خطاها

امنیت ارتباط میان کاربر و وبسایت یکی از مهمترین بخشهای راهاندازی هر سایت است. وقتی کاربر آدرس سایتی را با https:// باز میکند، اطلاعاتی که بین مرورگر و سایت ردوبدل میشود با استفاده از پروتکل TLS رمزنگاری میشود و افراد دیگر نمیتوانند بهسادگی محتوای این ارتباط را مشاهده یا تغییر دهند. به همین دلیل امروزه HTTPS دیگر یک قابلیت جانبی محسوب نمیشود و برای تقریباً هر وبسایتی، از یک سایت شرکتی ساده گرفته تا فروشگاه اینترنتی و سامانههای دارای حساب کاربری، یک ضرورت است.
Cloudflare یکی از سادهترین راهها برای فعال کردن HTTPS و مدیریت SSL/TLS سایت است. این سرویس برای دامنههایی که روی Cloudflare فعال شدهاند، گواهینامه عمومی رایگان ارائه میکند و بخش زیادی از فرایند صدور و تمدید آن را بهصورت خودکار انجام میدهد. با این حال، فعال کردن SSL در Cloudflare فقط به معنای روشن کردن یک گزینه در پنل نیست؛ زیرا در معماری Cloudflare، ارتباط میان بازدیدکننده و Cloudflare از ارتباط میان Cloudflare و سرور سایت جداست.
در این مقاله، فعال سازی SSL در Cloudflare را از صفر بررسی میکنیم؛ یعنی ابتدا توضیح میدهیم Cloudflare دقیقاً کجای مسیر ارتباطی سایت قرار میگیرد، SSL رایگان آن چه کاری انجام میدهد، چه زمانی باید روی هاست یا سرور نیز SSL نصب کنید، تفاوت Flexible، Full و Full (strict) چیست، چگونه Origin Certificate بسازید و در نهایت چگونه خطاهایی مانند 525، 526، Mixed Content و ERR_TOO_MANY_REDIRECTS را برطرف کنید. هدف این است که حتی اگر آشنایی زیادی با SSL و Cloudflare ندارید، بتوانید کل فرایند را بدون ابهام انجام دهید.
در صورتی که با روند ثبت نام در سایت کلودفلر آشنایی ندارید، مقاله نحوه ایجاد حساب در Cloudflare و اضافه کردن وب سایت را مطالعه کنید.
همچنین از آنجایی که این مقاله، تمام بخشهای مرتبط با Cloudflare SSL را پوشش داده است و متن آن طولانی است، برای پیدا کردن جواب سوال خود، از منوی فهرست سمت راست همین صفحه استفاده کنید.
SSL در Cloudflare چگونه کار میکند؟
قبل از اینکه وارد تنظیمات پنل Cloudflare شوید، بهتر است یک مدل ساده از نحوه کار آن داشته باشید. این مدل ذهنی باعث میشود بعداً هنگام انتخاب Flexible یا Full (strict) بدانید دقیقاً چه اتفاقی در پشت صحنه رخ میدهد.
فرض کنید سایت شما روی یک هاست، سرور مجازی یا سرور اختصاصی قرار دارد. فایلهای سایت، دیتابیس و نرمافزارهای موردنیاز آن روی همین سرور قرار گرفتهاند. به این سرور در معماری کلودفلر، Origin یا سرور اصلی سایت گفته میشود. بنابراین هرجا در این مقاله از Origin صحبت میکنیم، منظور همان هاست یا سروری است که سایت شما واقعاً روی آن میزبانی میشود.
وقتی دامنه را به Cloudflare متصل میکنید و رکورد DNS آن را روی حالت Proxied قرار میدهید، بازدیدکننده دیگر بهصورت مستقیم به سرور اصلی شما متصل نمیشود. مسیر کلی ارتباط به این شکل خواهد بود:
بازدیدکننده ←→ Cloudflare ←→ سرور اصلی سایت
در این مسیر، دو ارتباط جداگانه وجود دارد. ارتباط اول میان مرورگر بازدیدکننده و Cloudflare است و ارتباط دوم میان Cloudflare و سرور اصلی سایت برقرار میشود. اینکه هرکدام از این دو ارتباط چگونه رمزنگاری شوند، به تنظیمات SSL/TLS شما بستگی دارد.
ارتباط کاربر با Cloudflare
وقتی کاربر آدرس HTTPS سایت را وارد میکند، مرورگر ابتدا به زیرساخت Cloudflare متصل میشود. اگر رکورد دامنه روی حالت Proxied باشد، Cloudflare درخواست را دریافت میکند و گواهینامه SSL مربوط به دامنه را به مرورگر ارائه میدهد.
این گواهینامه در سمت Cloudflare قرار دارد و به آن Edge Certificate گفته میشود. عبارت Edge در اینجا به سرورهای Cloudflare در لبه شبکه اشاره دارد؛ یعنی همان زیرساختی که بازدیدکننده در ابتدا به آن متصل میشود.
Universal SSL یکی از قابلیتهای Cloudflare برای همین بخش است. Cloudflare برای دامنههای فعال، گواهینامه عمومی رایگان صادر میکند و آن را بهصورت خودکار تمدید میکند. این گواهینامه برای مرورگرهای عمومی قابل اعتماد است و باعث میشود کاربر بتواند سایت را با HTTPS باز کند.
ارتباط Cloudflare با سرور اصلی سایت
بعد از اینکه Cloudflare درخواست کاربر را دریافت کرد، باید آن را به سرور اصلی سایت ارسال کند. اینجا بخش دوم ارتباط قرار دارد.
اگر Cloudflare برای اتصال به سرور از HTTP استفاده کند، اطلاعات در این بخش رمزنگاری نمیشوند. اگر از HTTPS استفاده کند، ارتباط Cloudflare با سرور نیز رمزنگاری خواهد شد.
بنابراین ممکن است سایتی در مرورگر شما کاملاً امن به نظر برسد، اما ارتباط میان Cloudflare و سرور اصلی آن همچنان با HTTP انجام شود. این دقیقاً همان چیزی است که در حالت Flexible اتفاق میافتد. Cloudflare نیز Flexible را یک حالت «نسبتاً امن» میداند، زیرا فقط ارتباط بازدیدکننده با Cloudflare رمزنگاری میشود و ارتباط Cloudflare با سرور بدون رمزنگاری باقی میماند.
برای یک سایت استاندارد، بهتر است هر دو بخش ارتباط HTTPS باشند:
بازدیدکننده ← HTTPS → Cloudflare ← HTTPS → سرور اصلی
تفاوت Edge Certificate و Origin Certificate
برای درک SSL در Cloudflare باید بین دو نوع گواهینامه تفاوت بگذاریم.
Edge Certificate گواهینامهای است که Cloudflare برای ارتباط با بازدیدکننده استفاده میکند. Universal SSL در همین دسته قرار دارد. این گواهینامه باید توسط مرورگرهای عمومی قابل اعتماد باشد، زیرا مرورگر کاربر مستقیماً آن را بررسی میکند.
Origin Certificate گواهینامهای است که روی سرور اصلی سایت نصب میشود. هدف آن امن کردن ارتباط میان Cloudflare و سرور شماست. Cloudflare Origin CA یکی از روشهای دریافت چنین گواهینامهای است. این گواهینامه برای ارتباط Cloudflare با سرور طراحی شده و نباید آن را با گواهینامه عمومی که مرورگر کاربران مستقیماً به آن اعتماد میکند اشتباه گرفت.
پس اگر بخواهیم بسیار ساده بگوییم:
- Universal SSL برای بازدیدکننده ←→ Cloudflare است.
- Origin Certificate برای Cloudflare ←→ سرور سایت است.
این دو میتوانند دو گواهینامه کاملا متفاوت باشند.
آیا فعال کردن SSL در Cloudflare به معنی نصب SSL روی سرور است؟
خیر. این یکی از مهمترین نکاتی است که باید از ابتدا بدانید.
وقتی Universal SSL در Cloudflare فعال میشود، گواهینامهای که Cloudflare برای بازدیدکنندگان ارائه میکند روی سرور شما نصب نمیشود. بنابراین اگر فقط Universal SSL را فعال کرده باشید، نباید تصور کنید که هاست یا سرور شما نیز بهصورت خودکار SSL دریافت کرده است.
برای مثال، فرض کنید سایت شما روی یک هاست لینوکسی قرار دارد. Cloudflare میتواند برای بازدیدکننده یک اتصال HTTPS ایجاد کند، اما برای اتصال خودش به هاست شما هنوز چند حالت مختلف وجود دارد. در حالت Flexible، Cloudflare به هاست با HTTP متصل میشود و روی هاست نیازی به SSL نیست. در حالت Full یا Full (strict)، Cloudflare باید بتواند به هاست شما از طریق HTTPS متصل شود.
به همین دلیل، اگر میخواهید پیکربندی SSL سایت از نظر امنیتی کامل باشد، بهتر است روی هاست یا سرور خود نیز SSL داشته باشید و سپس حالت SSL/TLS را روی Full (strict) قرار دهید. این SSL میتواند یک گواهینامه عمومی مانند Let's Encrypt یا گواهینامه Cloudflare Origin CA باشد. Full (strict) علاوه بر رمزنگاری ارتباط، اعتبار گواهینامه سرور را نیز بررسی میکند.
قبل از فعال کردن SSL در Cloudflare چه چیزهایی لازم است؟
قبل از تغییر تنظیمات SSL، چند مورد پایه باید درست باشند. اگر DNS اشتباه باشد یا Cloudflare نتواند به سرور شما دسترسی پیدا کند، تغییر Encryption Mode بهتنهایی مشکل را حل نمیکند و حتی ممکن است خطاهایی مانند 525 یا 526 ایجاد شود.
اضافه کردن دامنه به Cloudflare
ابتدا باید دامنه خود را به حساب Cloudflare اضافه کنید. بعد از اضافه کردن دامنه، Cloudflare رکوردهای DNS موجود را شناسایی میکند و از شما میخواهد Nameserverهای دامنه را به Nameserverهای اختصاصی خود تغییر دهید.
در این مرحله لازم نیست برای Universal SSL گواهینامهای خریداری کنید. Cloudflare برای دامنههای اضافه و فعالشده، Universal SSL رایگان ارائه میکند.
تنظیم Nameserverها
Nameserver مشخص میکند DNS دامنه شما توسط کدام سرویس مدیریت شود. اگر از روش معمول Full DNS Setup استفاده میکنید، Cloudflare دو Nameserver به شما میدهد و باید آنها را در پنل شرکتی که دامنه را از آن ثبت کردهاید قرار دهید.
تا زمانی که Nameserverها به Cloudflare تغییر نکرده باشند و دامنه در Cloudflare فعال نشده باشد، بسیاری از قابلیتهای Cloudflare از جمله Proxy و گواهینامه Edge آنطور که انتظار دارید عمل نمیکنند.
بعد از تغییر Nameserverها، باید منتظر بمانید تا وضعیت دامنه در Cloudflare به Active تغییر کند.
بررسی رکوردهای DNS
بعد از فعال شدن دامنه، وارد بخش DNS شوید و بررسی کنید رکوردهای اصلی سایت به IP صحیح سرور اشاره میکنند. اگر رکورد A دامنه به IP اشتباه اشاره کند، Cloudflare به سرور دیگری متصل میشود و حتی اگر SSL روی سرور واقعی کاملاً صحیح باشد، سایت با مشکل مواجه خواهد شد.
اگر سایت شما با www نیز در دسترس است، رکورد مربوط به آن را نیز بررسی کنید. همچنین اگر از IPv6 استفاده میکنید، رکورد AAAA را نیز کنترل کنید.
Proxy بودن رکورد دامنه
در DNS Cloudflare معمولاً برای رکوردهای قابل Proxy یک گزینه به شکل ابر نارنجی وجود دارد. وقتی رکورد روی Proxied قرار دارد، ترافیک آن از Cloudflare عبور میکند.
این نکته برای Universal SSL مهم است. Cloudflare ممکن است گواهینامه Universal SSL را برای دامنه Provision کرده باشد، اما گواهینامه را فقط زمانی به بازدیدکننده ارائه میکند که hostname از طریق Cloudflare Proxy شود.
اگر رکورد روی DNS only باشد، کاربر مستقیماً به سرور شما متصل میشود و در آن حالت SSL سرور خودتان تعیینکننده اعتبار HTTPS خواهد بود.
بررسی دسترسی HTTPS روی سرور اصلی
اگر قصد دارید Full یا Full (strict) را انتخاب کنید، باید مطمئن شوید سرور اصلی شما HTTPS را پشتیبانی میکند.
برای سایتهایی که روی هاست اشتراکی قرار دارند، معمولاً شرکت هاستینگ SSL را روی دامنه نصب کرده است. اگر مطمئن نیستید، ابتدا سایت را مستقیماً با HTTPS بررسی کنید یا از پشتیبانی هاست درباره فعال بودن SSL روی دامنه سؤال کنید.
در سرور مجازی یا سرور اختصاصی نیز باید SSL روی وبسرور مانند Nginx یا Apache نصب و HTTPS فعال شده باشد.
بررسی پورت 443
HTTPS معمولاً از پورت 443 استفاده میکند. بنابراین اگر فایروال سرور یا تنظیمات شبکه اجازه اتصال به این پورت را ندهد، Cloudflare نمیتواند ارتباط HTTPS را با سرور برقرار کند.
این موضوع یکی از دلایل رایج خطای 525 است. Cloudflare در مستندات خود بسته بودن پورت 443، نبود Certificate معتبر، نبود SNI و ناسازگاری Cipherها را از علتهای اصلی این خطا معرفی میکند.
Universal SSL در Cloudflare چیست و چگونه فعال میشود؟
Universal SSL سادهترین بخش فعالسازی HTTPS در Cloudflare است و برای بیشتر کاربران نیازی به تنظیم دستی ندارد.
Universal SSL چیست؟
Universal SSL گواهینامه عمومیای است که Cloudflare برای دامنه شما در سمت خودش صادر میکند. وقتی کاربر سایت را باز میکند، این گواهینامه در ارتباط میان مرورگر و Cloudflare استفاده میشود.
به زبان ساده، اگر هدف شما این است که کاربر وقتی سایت را باز میکند، آدرس را با https:// ببیند و مرورگر گواهینامه معتبر سایت را تشخیص دهد، Universal SSL همان بخشی است که این کار را در سمت Cloudflare انجام میدهد.
آیا Universal SSL رایگان است؟
بله. Cloudflare برای دامنههای اضافه و فعالشده، Universal SSL رایگان و عمومی ارائه میکند و فرایند تمدید آن را نیز مدیریت میکند.
بنابراین برای فعال کردن HTTPS در سمت بازدیدکننده، لازم نیست حتماً یک گواهینامه SSL جداگانه خریداری کنید.
Cloudflare چه زمانی Certificate را صادر میکند؟
در Full DNS Setup، Cloudflare اعلام میکند که Universal SSL معمولاً بین ۱۵ دقیقه تا ۲۴ ساعت بعد از فعال شدن دامنه Provision میشود. بنابراین اگر بلافاصله بعد از تغییر Nameserverها Certificate را ندیدید، هنوز لزوماً مشکلی وجود ندارد.
Universal SSL چه دامنهها و سابدامینهایی را پوشش میدهد؟
در Full DNS Setup، گواهینامه Universal SSL بهطور معمول دامنه اصلی مانند example.com و سابدامینهای سطح اول مانند www.example.com یا blog.example.com را پوشش میدهد. Cloudflare توضیح میدهد که این Certificate حتی ممکن است برای رکوردهای DNS only نیز Provision شود، اما ارائه آن به بازدیدکننده نیازمند Proxied بودن hostname است.
اگر از ساختارهای پیچیدهتر مانند سابدامینهای چندسطحی استفاده میکنید، باید پوشش Certificate را جداگانه بررسی کنید.
اگر Universal SSL فعال نشد چه کنیم؟
اگر دامنه تازه Active شده است، ابتدا کمی زمان بدهید؛ زیرا صدور Certificate میتواند تا ۲۴ ساعت طول بکشد. بعد از آن، وضعیت دامنه، hostname موردنظر و Proxy بودن رکورد را بررسی کنید.
همچنین باید مطمئن شوید مشکل مربوط به Certificate است، نه DNS یا سرور. اگر دامنه با HTTPS باز نمیشود، اطلاعات Certificate را در مرورگر بررسی کنید تا مشخص شود مرورگر دقیقاً چه Certificateای دریافت کرده است.
آموزش فعالسازی SSL/TLS در Cloudflare
بعد از آماده شدن دامنه، DNS و Universal SSL، میتوانید سراغ تنظیمات اصلی SSL/TLS بروید.
ورود به داشبورد Cloudflare
وارد حساب Cloudflare شوید و دامنه موردنظر را از فهرست سایتها انتخاب کنید. دقت کنید تنظیمات SSL برای هر دامنه یا Zone جداگانه مدیریت میشود؛ بنابراین ابتدا باید سایت صحیح را انتخاب کنید.
انتخاب دامنه
بعد از ورود به صفحه دامنه، بخشهای مختلف مدیریت DNS، امنیت، SSL/TLS و تنظیمات شبکه را مشاهده خواهید کرد.
ورود به SSL/TLS
از منوی Cloudflare وارد بخش SSL/TLS شوید. در صفحه Overview، تنظیم مربوط به Encryption Mode قرار دارد و از همین بخش میتوانید روش رمزنگاری ارتباط Cloudflare با سرور را مشخص کنید.
بررسی وضعیت SSL
پیش از تغییر Mode، ابتدا وضعیت Certificate را بررسی کنید. اگر Universal SSL هنوز در حال Provision شدن است، تغییر دادن تنظیمات مختلف لزوماً باعث سریعتر شدن فرایند نمیشود.
انتخاب Encryption Mode
Cloudflare در حال حاضر علاوه بر حالتهای دستی، گزینه Automatic SSL/TLS را نیز ارائه میکند. در حالت دستی میتوانید بین حالتهایی مانند Flexible، Full و Full (strict) انتخاب کنید. Cloudflare در مستندات خود استفاده از Full (strict) را در صورت امکان بهترین گزینه از نظر امنیت معرفی میکند.
حالتهای SSL/TLS در Cloudflare چیست؟
برای انتخاب Mode مناسب، ابتدا باید بدانید هر حالت دقیقاً چه اتفاقی در مسیر ارتباط ایجاد میکند.
| حالت | کاربر تا Cloudflare | Cloudflare تا سرور | بررسی Certificate سرور | پیشنهاد |
|---|---|---|---|---|
| Off | بدون رمزنگاری | بدون رمزنگاری | ندارد | استفاده نشود |
| Flexible | HTTPS | HTTP | ندارد | فقط شرایط موقت |
| Full | HTTPS | HTTPS در درخواست HTTPS | اعتبارسنجی سختگیرانه ندارد | شرایط خاص |
| Full (strict) | HTTPS | HTTPS | اعتبارسنجی میشود | انتخاب پیشنهادی |
| Automatic SSL/TLS | بر اساس تنظیم Cloudflare | بر اساس تنظیم انتخابشده | بر اساس Mode | مناسب برای مدیریت خودکار |
Cloudflare در مستندات فعلی خود Full (strict) را برای بهترین امنیت پیشنهاد میکند، مشروط بر اینکه سرور اصلی بتواند یک Certificate معتبر ارائه دهد.
Flexible، Full یا Full (strict)؛ کدام را انتخاب کنیم؟
اگر فقط یک بخش از این مقاله را بخواهید دقیق یاد بگیرید، همین قسمت اهمیت بیشتری دارد. بسیاری از مشکلات SSL در Cloudflare از انتخاب اشتباه Mode ناشی میشوند.
Flexible SSL چیست؟
در حالت Flexible، کاربر با HTTPS به Cloudflare متصل میشود، اما Cloudflare برای ارتباط با سرور اصلی از HTTP استفاده میکند. بنابراین روی سرور اصلی سایت نیازی به SSL نیست.
مسیر ارتباط به این شکل است:
کاربر ← HTTPS → Cloudflare ← HTTP → سرور
این حالت ممکن است برای سروری که هنوز SSL روی آن نصب نشده است مفید باشد، اما به معنی رمزنگاری کامل مسیر نیست.
مشکلات Flexible SSL
مشکل اصلی Flexible این است که ارتباط میان Cloudflare و سرور رمزنگاری نشده باقی میماند. بنابراین اگر سایت شما اطلاعات ورود، اطلاعات شخصی یا دادههای حساس دریافت میکند، استفاده از این حالت مناسب نیست.
مشکل دیگر احتمال ایجاد Redirect Loop است. برای مثال، ممکن است سرور شما هر درخواست HTTP را به HTTPS Redirect کند، در حالی که Cloudflare در حالت Flexible همچنان درخواستها را با HTTP به سرور ارسال میکند. در این شرایط، Cloudflare و سرور میتوانند دائماً درخواست را بین HTTP و HTTPS جابهجا کنند.
به همین دلیل Flexible را بهتر است راهحل موقت بدانیم، نه تنظیم نهایی سایت.
Full SSL چیست؟
در حالت Full، Cloudflare میتواند برای درخواست HTTPS، با HTTPS به سرور اصلی متصل شود. در این حالت سرور باید SSL داشته باشد، اما Certificate آن الزاماً نباید توسط یک CA عمومی معتبر صادر شده باشد. برای مثال، Certificate خودامضا یا Cloudflare Origin CA نیز میتواند در این حالت استفاده شود.
مسیر ارتباط در حالت Full چنین است:
کاربر ← HTTPS → Cloudflare ← HTTPS → سرور
بنابراین برخلاف Flexible، ارتباط تا سرور نیز رمزنگاری میشود.
محدودیت Full SSL
مشکل Full این است که Cloudflare Certificate سرور را با سختگیری Full (strict) اعتبارسنجی نمیکند. بنابراین ممکن است سرور Certificate خودامضا، منقضی یا از نظر اعتماد عمومی نامعتبر داشته باشد و Cloudflare همچنان بتواند با آن ارتباط برقرار کند.
این حالت در بعضی شرایط خاص مفید است، اما اگر امکان نصب Certificate معتبر روی سرور را دارید، بهتر است بهجای Full از Full (strict) استفاده کنید.
Full (strict) چیست؟
Full (strict) کاملترین حالت معمول برای اغلب سایتهاست. در این حالت هم ارتباط کاربر با Cloudflare و هم ارتباط Cloudflare با سرور اصلی با HTTPS انجام میشود و علاوه بر آن، Cloudflare Certificate سرور را نیز اعتبارسنجی میکند.
برای استفاده از Full (strict)، Certificate نصبشده روی سرور باید:
- منقضی نشده باشد.
- توسط یک CA عمومی معتبر یا Cloudflare Origin CA صادر شده باشد.
- نام دامنه موردنظر را در Common Name یا SAN پوشش دهد.
چرا Full (strict) معمولاً انتخاب بهتر است؟
چون در این حالت صرفاً به رمزنگاری ارتباط اکتفا نمیشود. Cloudflare علاوه بر اینکه ارتباط را با HTTPS برقرار میکند، Certificate سرور را نیز بررسی میکند.
اگر سایت شما روی یک هاست معمولی قرار دارد و شرکت هاستینگ یک Certificate معتبر مانند Let's Encrypt روی آن نصب کرده است، معمولاً میتوانید بدون پیچیدگی خاصی Cloudflare را روی Full (strict) قرار دهید.
اگر روی سرور خودتان Certificate ندارید، میتوانید ابتدا یک Certificate نصب کنید و سپس Full (strict) را فعال کنید.
جدول انتخاب بهترین Mode بر اساس نوع سایت
| نوع سایت | انتخاب پیشنهادی |
|---|---|
| سایت شرکتی یا ساده | Full (strict) |
| وردپرس | Full (strict) |
| فروشگاه اینترنتی | Full (strict) |
| سایت دارای Login | Full (strict) |
| سایت دارای فرم و اطلاعات شخصی | Full (strict) |
| سرور دارای Let's Encrypt | Full (strict) |
| سرور دارای Cloudflare Origin CA | Full (strict) |
| سرور دارای SSL خریداریشده | Full (strict) |
| سرور بدون SSL | ابتدا SSL روی سرور نصب شود |
| سرور قدیمی با Certificate مشکلدار | Full بهصورت موقت، سپس Full (strict) |
| سروری که فعلاً HTTPS ندارد | Flexible فقط بهعنوان راهحل موقت |
آیا برای استفاده از Cloudflare باید SSL بخریم؟
یکی از سوالهای رایج این است که اگر قرار است Cloudflare خودش SSL ارائه کند، آیا باز هم باید برای سایت SSL خریداری کنیم؟
پاسخ کوتاه این است: نه، در بسیاری از سایتها نیازی به خرید SSL ندارید. اما باید بین SSL سمت Cloudflare و SSL روی سرور تفاوت قائل شوید.
آیا Universal SSL کلودفلر رایگان است؟
بله. Universal SSL برای دامنههای فعال Cloudflare رایگان است و Cloudflare صدور و تمدید آن را مدیریت میکند.
بنابراین برای HTTPS سمت بازدیدکننده، خرید SSL از یک شرکت دیگر الزام نیست.
آیا برای Origin هم SSL لازم داریم؟
اگر از Flexible استفاده کنید، نه. چون Cloudflare در این حالت با HTTP به سرور شما متصل میشود.
اما اگر میخواهید Full یا Full (strict) داشته باشید، باید سرور شما HTTPS را پشتیبانی کند و Certificate داشته باشد.
چه زمانی Cloudflare Origin CA کافی است؟
اگر تمام بازدیدکنندگان از طریق Cloudflare به سایت شما متصل میشوند و رکوردهای سایت Proxied هستند، Cloudflare Origin CA میتواند برای امن کردن ارتباط Cloudflare با سرور کافی باشد.
Cloudflare نیز Origin CA را دقیقاً برای رمزنگاری ارتباط میان Cloudflare و Origin معرفی میکند و Certificateهای آن با Full (strict) سازگار هستند.
چه زمانی بهتر است از SSL صادرشده توسط CA عمومی استفاده کنیم؟
اگر قرار است کاربران بتوانند مستقیماً به سرور شما متصل شوند، یا ممکن است در آینده رکورد را روی DNS only قرار دهید، استفاده از Certificate عمومی مانند Let's Encrypt انتخاب مناسبتری است.
دلیل این موضوع ساده است: Certificate عمومی توسط مرورگرها و سیستمعاملها شناخته میشود، در حالی که Cloudflare Origin CA برای اتصال Cloudflare به سرور طراحی شده است.
تفاوت SSL رایگان و SSL خریداریشده برای Origin
رایگان بودن Certificate به معنی ضعیف بودن آن نیست. یک Certificate رایگان مانند Let's Encrypt میتواند برای بسیاری از سایتها کاملاً مناسب باشد.
تفاوت Certificateهای پولی و رایگان بیشتر به نوع اعتبارسنجی، امکانات مدیریتی، پشتیبانی و ویژگیهای تجاری مربوط میشود. از نظر اصل رمزنگاری HTTPS، صرفاً خرید SSL به معنی امنتر بودن آن نیست.
ساخت Cloudflare Origin Certificate
اگر روی سرور خودتان SSL ندارید و سایت فقط از طریق Cloudflare در دسترس است، میتوانید از Cloudflare Origin CA استفاده کنید.
Origin Certificate چیست؟
Origin Certificate یک گواهینامه SSL است که روی سرور اصلی سایت نصب میشود تا ارتباط میان Cloudflare و سرور شما با HTTPS برقرار شود.
بنابراین برخلاف Universal SSL، هدف آن نمایش Certificate به بازدیدکننده نیست. هدف آن امن کردن بخش دوم مسیر ارتباط است:
Cloudflare ← HTTPS → سرور اصلی
Cloudflare Origin CA برای همین کاربرد طراحی شده است.
چه زمانی از Origin CA استفاده کنیم؟
Origin CA زمانی گزینه خوبی است که سرور شما فقط از طریق Cloudflare قابل دسترسی باشد. Cloudflare نیز استفاده از Origin CA را برای Originهایی که فقط از رکوردهای Proxied ترافیک دریافت میکنند پیشنهاد میکند.
اگر سرور را مستقیماً در اختیار کاربران قرار میدهید، بهتر است از Certificate عمومی استفاده کنید.
ساخت Origin Certificate
در داشبورد Cloudflare وارد بخش مربوط به Origin Server یا Origin CA شوید و گزینه ساخت Certificate جدید را انتخاب کنید.
در این مرحله Cloudflare از شما میخواهد hostnameهایی را که Certificate باید پوشش دهد مشخص کنید.
انتخاب Hostname
Hostname همان آدرس دامنه یا سابدامینی است که سایت با آن در دسترس قرار میگیرد. اگر سایت با example.com و www.example.com در دسترس است، باید مطمئن شوید Certificate این hostnameها را پوشش میدهد.
برای سایتهایی که سابدامینهای دیگری مانند api.example.com دارند نیز باید hostname موردنیاز را در Certificate در نظر بگیرید.
انتخاب Private Key
Cloudflare هنگام ساخت Origin Certificate یک Private Key نیز در اختیار شما قرار میدهد.
Private Key بسیار حساس است و نباید در اختیار افراد غیرضروری قرار بگیرد. همچنین نباید آن را در GitHub، فایلهای عمومی، تیکتهای عمومی یا هر محل دیگری که افراد غیرمجاز بتوانند به آن دسترسی پیدا کنند قرار دهید.
انتخاب مدت اعتبار
Cloudflare Origin CA امکان انتخاب مدت اعتبار Certificate را ارائه میکند. هنگام انتخاب مدت اعتبار، به فرایند نگهداری سرور نیز توجه کنید.
نکته مهم این است که Certificateهای Origin نیز ممکن است منقضی شوند و Cloudflare برای Origin CA در حال حاضر اعلان انقضای خودکار ارائه نمیکند؛ بنابراین باید فرایند تمدید آن را خودتان مدیریت کنید.
دریافت Certificate و Private Key
پس از ساخت Certificate، Cloudflare اطلاعات Certificate و Private Key را نمایش میدهد. Private Key را در محیط امن نگهداری کنید، زیرا در صورت از دست دادن یا افشای آن باید اقدامات امنیتی لازم برای تعویض Certificate انجام شود.
نصب Origin Certificate روی سرور
بعد از دریافت Certificate باید آن را روی وبسرور نصب کنید. اگر سایت روی cPanel یا DirectAdmin قرار دارد، نصب معمولاً از طریق پنل انجام میشود. اگر سرور مجازی یا اختصاصی دارید، باید Certificate را در تنظیمات Nginx، Apache یا وبسرور مورد استفاده قرار دهید.
همچنین پورت 443 باید باز باشد و وبسرور باید بتواند درخواستهای HTTPS را دریافت کند. Cloudflare نیز در راهنمای Origin CA بر فعال بودن SSL و پورت 443 روی Origin تأکید میکند.
آیا Origin Certificate برای کاربران عمومی معتبر است؟
خیر.
این نکته را باید کاملاً جدی بگیرید. Cloudflare Origin CA برای ارتباط Cloudflare با سرور طراحی شده است و نباید انتظار داشته باشید مرورگر کاربر مستقیماً به آن اعتماد کند.
اگر Proxy Cloudflare را خاموش کنید و کاربر مستقیماً به سرور متصل شود، ممکن است مرورگر Certificate مربوط به Origin CA را عمومی و معتبر تشخیص ندهد. بنابراین Origin CA جای Universal SSL را نمیگیرد؛ این دو Certificate برای دو بخش متفاوت از ارتباط استفاده میشوند.
آموزش نصب SSL Cloudflare روی سرور
بعد از ساخت Origin Certificate باید آن را روی سرور نصب کنید. روش انجام این کار به نوع سرویس میزبانی شما بستگی دارد.
نصب در cPanel
اگر سایت شما روی cPanel قرار دارد، ابتدا وارد حساب cPanel شوید و بخش SSL/TLS را باز کنید. بسته به تنظیمات سرور ممکن است مدیریت SSL از طریق SSL/TLS Manager یا ابزار مشابه انجام شود.
Certificate و Private Key مربوط به Origin را وارد کنید و آن را برای دامنه موردنظر نصب کنید. اگر هاستینگ شما اجازه نصب دستی SSL را نمیدهد، میتوانید اطلاعات Certificate را برای پشتیبانی ارسال کنید تا آن را روی سرور نصب کنند.
بعد از نصب، دامنه را با HTTPS بررسی کنید و مطمئن شوید Certificate صحیح برای همان دامنه ارائه میشود.
نصب در DirectAdmin
در DirectAdmin نیز مدیریت SSL از بخش مربوط به SSL دامنه انجام میشود. دامنه موردنظر را انتخاب کرده و Certificate و Private Key را در بخش مربوطه وارد کنید.
اگر از Origin CA استفاده میکنید، ممکن است بسته به نوع وبسرور و تنظیمات DirectAdmin به Certificate Chain نیز نیاز داشته باشید. در صورت مشاهده خطاهای مربوط به Chain، تنظیمات وبسرور و مستندات Certificate را بررسی کنید.
نصب در Nginx
در Nginx باید Certificate و Private Key در مسیرهای مناسب قرار بگیرند و Server Block مربوط به دامنه از آنها استفاده کند.
برای مثال، ساختار کلی تنظیمات میتواند به شکل زیر باشد:
ssl_certificate /etc/ssl/example/certificate.pem ssl_certificate_key /etc/ssl/example/private.key
مسیرها صرفاً نمونه هستند و باید با محل واقعی فایلهای Certificate روی سرور جایگزین شوند.
بعد از تغییر تنظیمات، ابتدا Configuration را بررسی کنید:
nginx -t
اگر تست بدون خطا انجام شد، Nginx را Reload کنید:
systemctl reload nginx
نصب در Apache
در Apache نیز باید Virtual Host مربوط به HTTPS به Certificate و Private Key صحیح اشاره کند. بسته به سیستمعامل و نوع نصب Apache، مسیر فایلهای Certificate متفاوت است.
پس از اعمال تنظیمات، Configuration را بررسی کنید و سپس سرویس Apache را Reload کنید.
اگر Certificate مربوط به Cloudflare Origin CA باشد، ممکن است لازم باشد Certificate Chain یا Root Certificate مربوط به Cloudflare را نیز در تنظیمات سرور قرار دهید. Cloudflare در مستندات خود برای بعضی پیکربندیها، از جمله Apache/cPanel، به این نیاز اشاره کرده است.
نکات امنیتی Private Key
Private Key را مثل یک رمز عبور بسیار حساس در نظر بگیرید. آن را در فایلهای عمومی، Repositoryهای Git، پیامرسانها یا تیکتهای عمومی قرار ندهید.
اگر احتمال میدهید Private Key در اختیار فرد دیگری قرار گرفته است، بهتر است Certificate جدیدی ایجاد کنید و کلید قبلی را کنار بگذارید.
فعال کردن HTTPS در Cloudflare
بعد از آماده شدن Certificate سمت Cloudflare و Certificate روی سرور، باید کاری کنید که بازدیدکنندگان همیشه نسخه HTTPS سایت را ببینند.
Always Use HTTPS چیست؟
گزینه Always Use HTTPS تمام درخواستهای HTTP را به نسخه HTTPS همان URL Redirect میکند. برای مثال:
http://example.com/about
به:
https://example.com/about
منتقل میشود.
Cloudflare این قابلیت را در بخش Edge Certificates ارائه میکند و برای سایتی که تمام بخشهای آن HTTPS را پشتیبانی میکنند، استفاده از آن منطقی است.
چگونه Always Use HTTPS را فعال کنیم؟
در داشبورد Cloudflare وارد بخش SSL/TLS شوید و سپس به Edge Certificates بروید. گزینه Always Use HTTPS را پیدا کرده و فعال کنید. Cloudflare اعلام میکند این قابلیت در پلنهای Free، Pro، Business و Enterprise در دسترس است.
قبل از فعال کردن آن مطمئن شوید نسخه HTTPS سایت بدون خطا باز میشود.
Automatic HTTPS Rewrites چیست؟
گاهی خود صفحه با HTTPS باز میشود اما داخل کد سایت هنوز لینکهایی با HTTP وجود دارد. برای مثال ممکن است فایل CSS، تصویر یا JavaScript با آدرس HTTP فراخوانی شود.
Automatic HTTPS Rewrites در بعضی از این موارد میتواند URLهای HTTP را به HTTPS تغییر دهد؛ البته فقط زمانی که منبع موردنظر واقعاً از HTTPS نیز در دسترس باشد.
تفاوت Always Use HTTPS و Automatic HTTPS Rewrites
این دو گزینه وظیفه یکسانی ندارند.
Always Use HTTPS بازدیدکنندهای را که با HTTP وارد شده به HTTPS منتقل میکند.
Automatic HTTPS Rewrites بعضی URLهای HTTP داخل محتوای سایت را به HTTPS تغییر میدهد.
بنابراین اولی مربوط به Redirect درخواست است و دومی مربوط به منابع و لینکهای داخل صفحه.
چرا فعال کردن هر دو، مشکل Redirect را حل نمیکند؟
اگر سرور شما نیز بهصورت جداگانه Redirect انجام دهد، ممکن است Cloudflare و سرور وارد یک چرخه شوند.
برای مثال، فرض کنید Cloudflare با Flexible به سرور متصل میشود. Cloudflare درخواست HTTPS کاربر را با HTTP به سرور میفرستد. سرور HTTP را میبیند و آن را به HTTPS Redirect میکند. Cloudflare دوباره درخواست را دریافت میکند و این چرخه تکرار میشود.
به همین دلیل Cloudflare توصیه میکند Redirectهای غیرضروری را روی Origin انجام ندهید و Redirect اصلی را در Cloudflare مدیریت کنید. همچنین Always Use HTTPS بهتنهایی Mixed Content را برطرف نمیکند.
تنظیمات امنیتی مهم SSL/TLS در Cloudflare
بعد از فعال کردن HTTPS، چند تنظیم امنیتی دیگر نیز وجود دارد که میتوانند امنیت ارتباطات سایت را بهتر کنند. با این حال، بهتر است همه گزینهها را بدون شناخت تغییر ندهید.
Minimum TLS Version
این گزینه مشخص میکند قدیمیترین نسخه TLS که Cloudflare از سمت بازدیدکننده قبول میکند چه باشد.
برای سایتهای مدرن، TLS 1.2 حداقل منطقیتری نسبت به نسخههای بسیار قدیمی TLS است. با افزایش Minimum TLS Version، مرورگرها و سیستمهای بسیار قدیمی ممکن است دیگر نتوانند به سایت متصل شوند؛ بنابراین این تنظیم باید با توجه به مخاطبان سایت انجام شود.
TLS 1.3
TLS 1.3 نسخه جدیدتر TLS است و در مقایسه با نسلهای قدیمیتر، بهبودهای امنیتی و عملکردی دارد. برای یک سایت امروزی، فعال بودن TLS 1.3 انتخاب مناسبی است.
در حالت عادی نیازی نیست وارد تنظیمات پیچیده Cipherها شوید، مگر اینکه دلیل فنی مشخصی برای انجام این کار داشته باشید.
HSTS
HSTS یا HTTP Strict Transport Security به مرورگر میگوید سایت باید فقط از HTTPS استفاده کند.
این قابلیت میتواند امنیت سایت را بیشتر کند، اما نباید در اولین مرحله فعال شود. ابتدا باید مطمئن شوید HTTPS سایت کاملاً پایدار است، تمام سابدامینهای موردنیاز Certificate معتبر دارند و قرار نیست بهزودی سایت را به HTTP یا سرور دیگری منتقل کنید.
فعال کردن HSTS بدون بررسی قبلی میتواند در صورت بروز مشکل SSL، دسترسی کاربران را سختتر کند.
Certificate Transparency
Certificate Transparency یا CT به شما کمک میکند صدور Certificateهای مربوط به دامنه را بهتر زیر نظر داشته باشید. این قابلیت برای سایتهایی که میخواهند صدور گواهینامههای غیرمنتظره برای دامنه را سریعتر شناسایی کنند، مفید است.
برای سایتهای معمولی، فعال کردن این قابلیت ضروری نیست؛ اما برای دامنههای حساس و کسبوکارهای بزرگ میتواند یک لایه نظارتی مفید باشد.
Authenticated Origin Pulls
Authenticated Origin Pulls یا AOP برای زمانی است که میخواهید Origin فقط درخواستهایی را بپذیرد که از Cloudflare آمدهاند.
در حالت معمول، اگر فردی IP واقعی سرور را پیدا کند و پورتهای آن از اینترنت قابل دسترسی باشند، ممکن است بتواند Cloudflare را دور بزند و مستقیماً به سرور درخواست ارسال کند. AOP میتواند به Origin کمک کند درخواستهای دارای Certificate کلاینت Cloudflare را شناسایی کند.
این قابلیت بیشتر برای سایتهای حساس و زیرساختهایی مناسب است که امنیت Origin اهمیت بالایی دارد.
چه تنظیماتی را فعال کنیم و چه تنظیماتی را دستکاری نکنیم؟
برای یک سایت معمولی، بهتر است تنظیمات را ساده نگه دارید. Universal SSL باید فعال باشد، Origin باید SSL داشته باشد، Encryption Mode روی Full (strict) قرار گیرد و Always Use HTTPS نیز پس از اطمینان از عملکرد صحیح HTTPS فعال شود.
TLS 1.3 نیز بهتر است فعال باشد. HSTS را بعد از تست کامل سایت فعال کنید و گزینههای پیچیده TLS را بدون دلیل فنی تغییر ندهید.
خطاهای SSL در Cloudflare و روش رفع آنها
بیشتر مشکلات جدی SSL در Cloudflare زمانی دیده میشوند که ارتباط Cloudflare با سرور اصلی درست تنظیم نشده باشد. به همین دلیل هنگام مشاهده خطا، نباید فقط Certificate مرورگر را بررسی کنید؛ باید بخش Cloudflare تا سرور را نیز بررسی کنید.
خطای 525 چیست؟
خطای 525 SSL handshake failed به این معنی است که Cloudflare نتوانسته با سرور اصلی شما یک TLS Handshake موفق ایجاد کند. این خطا معمولاً زمانی رخ میدهد که Mode روی Full یا Full (strict) قرار دارد اما Cloudflare هنگام برقراری HTTPS با سرور با مشکل مواجه میشود.
مهمترین علتهای 525 عبارتاند از:
SSL روی سرور فعال نیست: اگر Full (strict) را انتخاب کردهاید اما سرور HTTPS ارائه نمیکند، Cloudflare نمیتواند اتصال را برقرار کند.
پورت 443 بسته است: فایروال سرور، فایروال دیتاسنتر یا تنظیمات شبکه ممکن است اتصال به پورت 443 را مسدود کرده باشد.
SNI پشتیبانی نمیشود: اگر چند سایت روی یک IP قرار دارند، سرور باید بتواند بر اساس نام دامنه، Certificate و Virtual Host مناسب را انتخاب کند.
Cipherها سازگار نیستند: اگر Cipherهای مورد استفاده Cloudflare با Cipherهای قابل پشتیبانی سرور هماهنگ نباشند، TLS Handshake شکست میخورد.
تنظیم Certificate اشتباه است: Certificate ممکن است ناقص نصب شده باشد یا وبسرور برای دامنه موردنظر Certificate اشتباهی ارائه کند.
Cloudflare نیز همین موارد را از دلایل اصلی خطای 525 معرفی میکند.
خطای 526 چیست؟
خطای 526 Invalid SSL Certificate با 525 تفاوت مهمی دارد. در 526، Cloudflare توانسته با سرور شما ارتباط TLS برقرار کند، اما Certificate ارائهشده توسط سرور را معتبر تشخیص نداده است. این خطا معمولاً زمانی رخ میدهد که Full (strict) فعال باشد.
برای مثال، ممکن است Certificate سرور منقضی شده باشد، نام دامنه را پوشش ندهد یا از CA مورد اعتماد Cloudflare صادر نشده باشد.
برای رفع مشکل، Certificate سرور را بررسی کنید. اگر از Cloudflare Origin CA استفاده کنید یا یک Certificate عمومی معتبر مانند Let's Encrypt روی سرور نصب کنید، میتوانید Full (strict) را بدون این مشکل استفاده کنید.
ERR_TOO_MANY_REDIRECTS
این خطا معمولاً به دلیل Redirectهای متناقض بین Cloudflare و سرور ایجاد میشود.
یک مثال ساده، Flexible است. Cloudflare با کاربر HTTPS دارد اما با سرور HTTP صحبت میکند. سرور نیز HTTP را به HTTPS Redirect میکند. نتیجه میتواند یک چرخه بینهایت باشد.
اگر با این خطا مواجه شدید، ابتدا Encryption Mode را بررسی کنید و Redirectهای موجود در Cloudflare و سرور را کنار هم قرار دهید. در بسیاری از سایتها، انتقال به Full (strict) و حذف Redirect اضافی از Origin مشکل را برطرف میکند.
Mixed Content
Mixed Content زمانی رخ میدهد که خود صفحه با HTTPS باز شده باشد اما بعضی منابع آن هنوز با HTTP بارگذاری شوند.
برای مثال، سایت با این آدرس باز شده است:
https://example.com
اما فایل CSS با این آدرس درخواست میشود:
http://example.com/style.css
در چنین شرایطی مرورگر ممکن است منبع را مسدود کند یا هشدار امنیتی نمایش دهد.
Always Use HTTPS این مشکل را حل نمیکند، زیرا این گزینه فقط درخواستهای HTTP را به HTTPS Redirect میکند. Automatic HTTPS Rewrites میتواند بعضی منابع را اصلاح کند، اما اگر URLهای HTTP در کد سایت، دیتابیس یا تنظیمات CMS وجود داشته باشند، بهتر است آنها را بهصورت اصولی اصلاح کنید.
ERR_CERT_AUTHORITY_INVALID
این خطا یعنی مرورگر Certificate ارائهشده را از یک مرجع صدور قابل اعتماد تشخیص نداده است.
اگر کاربر مستقیماً به سروری متصل شود که روی آن Cloudflare Origin CA نصب شده است، چنین خطایی میتواند طبیعی باشد؛ زیرا Origin CA برای اعتماد مستقیم مرورگر طراحی نشده است.
در این شرایط اگر قرار است کاربران مستقیماً به سرور متصل شوند، استفاده از Certificate عمومی مانند Let's Encrypt گزینه مناسبتری است.
SSL Certificate Expired
Certificate منقضیشده یکی از سادهترین دلایل خطاهای SSL است.
Universal SSL توسط Cloudflare مدیریت و تمدید میشود، اما Certificate نصبشده روی سرور باید جداگانه مدیریت شود. اگر Certificate Origin منقضی شده باشد، در حالت Full (strict) Cloudflare آن را معتبر نمیداند و ممکن است خطای 526 نمایش دهد.
Certificate Name Mismatch
این خطا زمانی رخ میدهد که نام دامنهای که کاربر یا Cloudflare درخواست کرده، با نام موجود در Certificate مطابقت نداشته باشد.
برای مثال، اگر کاربر www.example.com را باز کند اما Certificate فقط example.com را پوشش دهد، ممکن است اعتبارسنجی Certificate شکست بخورد.
در Full (strict)، Cloudflare نیز تطابق hostname با Common Name یا SAN Certificate را بررسی میکند.
چگونه مطمئن شویم SSL Cloudflare درست فعال شده است؟
بعد از انجام تمام تنظیمات، بهتر است فقط به علامت قفل مرورگر اکتفا نکنید. چند مرحله ساده میتواند مشخص کند کل زنجیره SSL درست کار میکند.
بررسی HTTPS در مرورگر
ابتدا نسخه HTTPS سایت را باز کنید:
https://example.com
مطمئن شوید مرورگر هیچ هشدار امنیتی نمایش نمیدهد. سپس چند صفحه داخلی سایت را نیز باز کنید، زیرا ممکن است مشکل فقط در یک صفحه خاص وجود داشته باشد.
بررسی Certificate
روی اطلاعات Certificate مرورگر کلیک کنید و نام دامنه، صادرکننده و تاریخ اعتبار را بررسی کنید.
اگر سایت Proxied باشد، Certificateای که مرورگر مشاهده میکند مربوط به Cloudflare است. بنابراین این Certificate لزوماً همان Certificate نصبشده روی سرور شما نیست.
بررسی Origin
اگر Full یا Full (strict) فعال است، سرور اصلی نیز باید HTTPS را درست ارائه کند. اگر به سرور دسترسی دارید، تنظیمات وبسرور، Certificate و پورت 443 را بررسی کنید.
در هاست اشتراکی میتوانید از پشتیبانی سرویس میزبانی بخواهید وضعیت SSL روی Origin را بررسی کند.
بررسی Redirect
آدرس HTTP سایت را باز کنید و مطمئن شوید به HTTPS منتقل میشود:
http://example.com
باید در نهایت به:
https://example.com
برسد.
همچنین بهتر است بررسی کنید چند Redirect پشت سر هم اتفاق نمیافتد.
بررسی Mixed Content
Developer Tools مرورگر را باز کنید و بخش Console و Network را بررسی کنید. اگر منابعی با HTTP بارگذاری شوند، معمولاً هشدار Mixed Content مشاهده خواهید کرد.
بررسی SSL/TLS Mode
به Cloudflare برگردید و Mode را بررسی کنید. اگر Certificate معتبر روی سرور نصب است، برای بیشتر سایتها Full (strict) انتخاب مناسبی است.
بررسی با ابزارهای تست SSL
ابزارهای تست SSL میتوانند اطلاعات بیشتری درباره Certificate، Chain، TLS و تنظیمات امنیتی ارائه کنند.
فقط توجه داشته باشید که اگر از Cloudflare Origin CA استفاده میکنید، بررسی مستقیم Origin با ابزارهای عمومی ممکن است Certificate را عمومی و قابل اعتماد تشخیص ندهد. این موضوع به معنی خراب بودن Origin CA نیست؛ چون این Certificate اساساً برای ارتباط Cloudflare با سرور طراحی شده است.
تأثیر SSL و HTTPS روی سئو سایت
فعال کردن HTTPS علاوه بر امنیت، بخشی از استاندارد فنی سایت نیز محسوب میشود. با این حال، مهاجرت از HTTP به HTTPS را نباید فقط به فعال کردن SSL محدود کرد.
آیا HTTPS فاکتور رتبهبندی است؟
بله. Google سالهاست HTTPS را بهعنوان یکی از سیگنالهای رتبهبندی در نظر میگیرد، هرچند اهمیت آن در مقایسه با کیفیت محتوا، ارتباط محتوا با جستوجو و بسیاری از عوامل دیگر محدود است.
بنابراین نباید انتظار داشته باشید فعال کردن SSL بهتنهایی رتبه سایت را بهطور چشمگیری افزایش دهد. ارزش اصلی HTTPS در امنیت، اعتماد کاربر و استاندارد بودن زیرساخت سایت است.
Redirect HTTP به HTTPS
بعد از مهاجرت باید نسخه HTTP به نسخه HTTPS همان صفحه Redirect شود.
برای مثال:
http://example.com/article
باید به:
https://example.com/article
منتقل شود.
برای مهاجرت دائمی، Redirect مناسب معمولاً 301 است. نکته مهم این است که URL قدیمی مستقیماً به URL نهایی منتقل شود و Redirectهای زنجیرهای ایجاد نشوند.
Canonical
Canonical صفحات باید نسخه HTTPS را معرفی کند. اگر صفحه با HTTPS باز میشود اما Canonical همچنان به نسخه HTTP اشاره میکند، سیگنالهای متناقض ایجاد میشود.
بنابراین بعد از فعال کردن SSL، Canonicalهای سایت را بررسی کنید و مطمئن شوید نسخه نهایی HTTPS را معرفی میکنند.
Sitemap
Sitemap نیز باید URLهای HTTPS را در خود داشته باشد. اگر سایت قبلاً روی HTTP بوده است، URLهای Sitemap را بررسی کنید و نسخه HTTPS را جایگزین نسخه قبلی کنید.
Internal Links
لینکهای داخلی سایت نیز باید به HTTPS منتقل شوند. وجود هزاران لینک HTTP در سایت باعث ایجاد Redirectهای غیرضروری میشود و ساختار سایت را از حالت ایدهآل خارج میکند.
در WordPress ممکن است این URLها در دیتابیس، تنظیمات قالب، افزونهها و محتوای قدیمی وجود داشته باشند.
Mixed Content و تجربه کاربر
اگر بعضی منابع سایت هنوز با HTTP بارگذاری شوند، ممکن است مرورگر آنها را مسدود کند. نتیجه میتواند خراب شدن ظاهر سایت، بارگذاری نشدن فایلهای JavaScript یا نمایش هشدار امنیتی باشد.
بنابراین رفع Mixed Content بخشی از فرایند مهاجرت به HTTPS است، نه یک مرحله اختیاری.
اشتباهات رایج هنگام مهاجرت HTTP به HTTPS
یکی از رایجترین اشتباهات این است که کاربر SSL را فعال میکند، اما لینکهای داخلی، Canonical و Sitemap را تغییر نمیدهد.
اشتباه دیگر ایجاد چند Redirect پشت سر هم است. برای مثال بهتر است مسیر به این شکل نباشد:
HTTP → www → HTTPS → URL نهایی
بلکه درخواست قدیمی مستقیماً به URL نهایی منتقل شود.
بهترین تنظیم SSL Cloudflare برای سایتهای مختلف
اگر بخواهیم تمام آموزش را به یک تصمیم ساده تبدیل کنیم، برای اغلب سایتها بهترین ساختار این است که Cloudflare در سمت بازدیدکننده Universal SSL ارائه کند و سرور اصلی نیز یک Certificate معتبر داشته باشد. سپس Encryption Mode روی Full (strict) قرار گیرد.
| نوع سایت | پیشنهاد |
|---|---|
| سایت ساده | Full (strict) |
| سایت شرکتی | Full (strict) |
| وردپرس | Full (strict) |
| فروشگاه اینترنتی | Full (strict) |
| سایت دارای Login | Full (strict) |
| سایت دارای فرم و اطلاعات شخصی | Full (strict) |
| Origin با Let's Encrypt | Full (strict) |
| Origin با Cloudflare Origin CA | Full (strict) |
| Origin با SSL خریداریشده | Full (strict) |
| Origin بدون SSL | ابتدا SSL روی Origin |
| Origin دارای Certificate نامعتبر | ابتدا Certificate اصلاح شود |
| سروری که فعلاً HTTPS ندارد | Flexible فقط بهعنوان راهحل موقت |
در واقع برای بیشتر کاربران یک نسخه ساده وجود دارد:
SSL سمت Cloudflare + SSL روی سرور + Full (strict) + HTTPS Redirect
این ترکیب معمولاً از Flexible بسیار بهتر است و باعث میشود هر دو بخش ارتباط رمزنگاری شوند. Cloudflare نیز Full (strict) را در صورت امکان بهترین انتخاب از نظر امنیت معرفی میکند.
چکلیست فعالسازی SSL در Cloudflare
- دامنه به Cloudflare اضافه شده است.
- Nameserverهای دامنه روی Cloudflare قرار گرفتهاند.
- وضعیت دامنه در Cloudflare Active است.
- رکوردهای DNS به سرور صحیح اشاره میکنند.
- رکوردهای موردنیاز سایت روی حالت Proxied قرار دارند.
- Universal SSL صادر و فعال شده است.
- دامنه و سابدامینهای موردنیاز تحت پوشش Certificate هستند.
- SSL روی سرور اصلی بررسی شده است.
- پورت 443 روی سرور باز است.
- Certificate سرور منقضی نشده است.
- Certificate سرور نام دامنه صحیح را پوشش میدهد.
- Full (strict) انتخاب شده است.
- سایت با HTTPS بدون هشدار باز میشود.
- HTTP به HTTPS Redirect میشود.
- Redirect Loop وجود ندارد.
- Mixed Content بررسی و برطرف شده است.
- لینکهای داخلی به HTTPS منتقل شدهاند.
- Canonical صفحات روی HTTPS قرار دارد.
- Sitemap شامل URLهای HTTPS است.
- خطای 525 بررسی شده است.
- خطای 526 بررسی شده است.
- TLS 1.3 فعال است.
- Minimum TLS Version متناسب با نیاز سایت تنظیم شده است.
- HSTS فقط بعد از اطمینان از پایداری HTTPS فعال شده است.
- در سایتهای حساس، امکان استفاده از Authenticated Origin Pulls بررسی شده است.
جمعبندی؛ بهترین روش فعال سازی SSL در Cloudflare چیست؟
فعال سازی SSL در Cloudflare در سادهترین حالت میتواند فقط چند دقیقه زمان ببرد، اما برای اینکه سایت واقعاً با یک پیکربندی استاندارد HTTPS کار کند، باید تفاوت میان SSL سمت Cloudflare و SSL روی سرور را بدانید.
Cloudflare در مسیر ارتباطی سایت بین بازدیدکننده و سرور اصلی قرار میگیرد. سرور اصلی یا Origin همان هاست یا سروری است که سایت شما روی آن قرار دارد. Cloudflare میتواند برای ارتباط بازدیدکننده با خودش یک Certificate رایگان Universal SSL ارائه کند، اما این Certificate روی هاست یا سرور شما نصب نمیشود.
اگر از Flexible استفاده کنید، ارتباط بازدیدکننده با Cloudflare با HTTPS انجام میشود اما ارتباط Cloudflare با سرور با HTTP باقی میماند. این حالت ممکن است زمانی مفید باشد که سرور شما هنوز SSL ندارد، اما برای سایتهای دارای Login یا اطلاعات حساس انتخاب مناسبی نیست.
در پیکربندی استاندارد، بهتر است روی سرور نیز SSL نصب شود. این Certificate میتواند رایگان باشد؛ برای مثال میتوانید از Let's Encrypt یا Cloudflare Origin CA استفاده کنید. بعد از نصب SSL روی سرور، حالت Cloudflare را روی Full (strict) قرار دهید. در این حالت هم ارتباط کاربر با Cloudflare و هم ارتباط Cloudflare با سرور رمزنگاری میشود و Cloudflare Certificate سرور را نیز اعتبارسنجی میکند.
پس اگر یک سایت معمولی، وردپرس، فروشگاه یا سایت شرکتی دارید، لازم نیست درگیر پیچیدگیهای غیرضروری شوید. ساختار پیشنهادی شما میتواند این باشد:
کاربر ← HTTPS → Cloudflare ← HTTPS → سرور سایت
در سمت Cloudflare، Universal SSL وظیفه ارتباط با بازدیدکننده را بر عهده دارد و در سمت سرور، Certificate نصبشده روی Origin ارتباط Cloudflare با هاست یا سرور شما را امن میکند.
بعد از آن Always Use HTTPS را برای انتقال بازدیدکنندگان از HTTP به HTTPS فعال کنید و Mixed Content را بررسی کنید. اگر سایت هنوز فایلهایی با HTTP بارگذاری میکند، Automatic HTTPS Rewrites میتواند در بعضی موارد کمک کند، اما بهتر است URLهای قدیمی HTTP در خود سایت نیز اصلاح شوند.
اگر هنگام فعال کردن Full (strict) با خطای 526 مواجه شدید، به سراغ Certificate سرور بروید؛ زیرا این خطا معمولاً به این معنی است که Cloudflare Certificate Origin را معتبر تشخیص نداده است. اگر خطای 525 مشاهده کردید، بیشتر روی خود اتصال Cloudflare به سرور، پورت 443، SNI، Cipherها و پیکربندی SSL وبسرور تمرکز کنید.
در نهایت، فعال کردن SSL زمانی واقعاً کامل شده است که نهتنها قفل HTTPS در مرورگر نمایش داده شود، بلکه ارتباط Cloudflare با سرور نیز رمزنگاری و اعتبارسنجی شود، HTTP به HTTPS منتقل شود، Mixed Content نداشته باشید و تنظیمات فنی سایت مانند Canonical، Sitemap و لینکهای داخلی نیز با نسخه HTTPS هماهنگ باشند.
برای بیشتر وبسایتها، اگر این چند اصل را رعایت کنید، نیازی به تنظیمات پیچیده ندارید: Universal SSL در Cloudflare، SSL روی سرور، Full (strict)، HTTPS اجباری و بررسی کامل Mixed Content و Redirectها. این ترکیب یک نقطه شروع استاندارد و امن برای استفاده از Cloudflare بهعنوان لایه محافظ و مدیریتکننده SSL/TLS سایت است.
سوالات متداول
بله، Cloudflare برای بسیاری از سایتها Universal SSL را بدون نیاز به خرید Certificate جداگانه ارائه میکند. با این حال، فعال شدن SSL در Cloudflare به این معنی نیست که ارتباط Cloudflare با سرور اصلی نیز حتماً با SSL ایمن شده است.
بسته به حالت SSL/TLS انتخابشده متفاوت است. در حالت Flexible نیازی به SSL روی سرور نیست، اما برای پیکربندی امنتر، استفاده از Full (strict) توصیه میشود و در این حالت سرور اصلی نیز باید یک Certificate معتبر داشته باشد.
در بیشتر سایتها، Full (strict) بهترین انتخاب است؛ زیرا هم ارتباط کاربر با Cloudflare و هم ارتباط Cloudflare با سرور اصلی با HTTPS انجام میشود و Certificate سمت سرور نیز اعتبارسنجی میشود.
در Flexible ارتباط کاربر با Cloudflare رمزنگاری میشود، اما ارتباط Cloudflare با سرور اصلی میتواند HTTP باشد. در Full، ارتباط هر دو طرف با HTTPS انجام میشود، اما Certificate سرور اصلی بهصورت سختگیرانه اعتبارسنجی نمیشود. در Full (strict)، Certificate سمت سرور نیز باید معتبر و منطبق با دامنه باشد.
خیر. Cloudflare Origin Certificate برای ارتباط Cloudflare با سرور اصلی طراحی شده است و توسط مرورگرهای عمومی بهعنوان یک Certificate قابل اعتماد شناخته نمیشود. بنابراین نباید آن را جایگزین Certificate عمومی برای اتصال مستقیم کاربران به سرور در نظر گرفت.
خطای 525 نشان میدهد Cloudflare نتوانسته با سرور اصلی یک SSL Handshake موفق برقرار کند. فعال نبودن SSL روی سرور، بسته بودن پورت 443، مشکلات SNI یا تنظیمات Certificate و Cipher از دلایل رایج این خطا هستند.
این خطا معمولاً زمانی رخ میدهد که تنظیمات HTTPS در Cloudflare و سرور اصلی با یکدیگر هماهنگ نباشند؛ برای مثال، Cloudflare روی Flexible باشد اما سرور نیز درخواستهای HTTP را به HTTPS Redirect کند. استفاده از Full (strict) و تنظیم صحیح Redirectها معمولاً راهکار مناسبتری است.




























شما میتوانید دیدگاه خود را در مورد این مطلب با ما با اشتراک بگذارید.