با خرید SSL میتوانید ارتباط میان کاربران و وبسایت خود را رمزنگاری کنید و سایت را از طریق HTTPS در دسترس قرار دهید. گواهی SSL برای سایتهای شرکتی، فروشگاههای اینترنتی، پنلهای کاربری و هر وبسایتی که اطلاعات کاربران را دریافت میکند، یکی از پایههای اصلی امنیت و اعتماد است.
سرور های ابری وان پلتفرم از تمام دیتاسنتر ها و لوکیشن ها قابل ارایه هستند
با خرید گواهینامه SSL برتینا، اعتبار سایت و امنیت کاربران را افزایش دهید.
گواهیهای SSL را بر اساس نوع اعتبارسنجی، تعداد دامنهها، پوشش Wildcard، مدت اعتبار و برند صادرکننده مقایسه کنید و گزینه مناسب وبسایت یا زیرساخت خود را انتخاب نمایید.
گواهی اقتصادی برای وبسایتها، وبلاگها و صفحات شرکتی
محافظت از دامنه اصلی و تمام زیردامنههای آن با یک گواهی
امنیت بیشتر برای وبسایتهایی که اعتبار برند برایشان مهم است
امنیت گسترده دامنه اصلی و زیردامنهها با سطح اعتماد بیشتر
گواهی حرفهای برای سازمانها و کسبوکارهای حساس
مدیریت امنیت چند دامنه مستقل با استفاده از یک گواهی SSL
محافظت همزمان از چند دامنه و زیردامنههای مرتبط با آنها
SSL یکی از مهمترین اجزای امنیت پایه هر وبسایت است. زمانی که گواهی SSL روی سایت فعال باشد، اطلاعاتی که میان مرورگر کاربر و سرور منتقل میشوند به صورت رمزنگاریشده ارسال خواهند شد.
این موضوع برای فرم ورود، ثبتنام، پرداخت آنلاین، پنل کاربران و هر صفحهای که اطلاعات حساس دریافت میکند اهمیت زیادی دارد.
پس از نصب گواهی، آدرس سایت به جای http:// با https:// باز میشود و مرورگر اتصال امن را تشخیص میدهد.
با خرید SSL از 1Platform میتوانید بر اساس ساختار سایت، تعداد دامنهها و نوع کسبوکار، گواهی مناسب خود را انتخاب و روی هاست، سرور مجازی یا سرور اختصاصی نصب کنید.
SSL مخفف Secure Sockets Layer است و در کاربرد عمومی به گواهی دیجیتالی گفته میشود که برای ایجاد ارتباط امن میان کاربر و سرور استفاده میشود.
امروزه ارتباط امن در عمل با نسخههای جدیدتر TLS انجام میشود، اما اصطلاح SSL همچنان به صورت گسترده برای گواهیهای HTTPS استفاده میشود.
گواهی SSL هویت دامنه را با یک کلید رمزنگاریشده مرتبط میکند.
مرورگر پس از بررسی اعتبار گواهی، یک ارتباط امن با وبسرور ایجاد میکند.
زمانی که کاربر وارد یک سایت HTTPS میشود، مرورگر ابتدا گواهی سرور را دریافت میکند.
گواهی شامل اطلاعاتی درباره دامنه، صادرکننده و کلید عمومی است.
مرورگر بررسی میکند که Certificate معتبر باشد، منقضی نشده باشد و نام دامنه با گواهی مطابقت داشته باشد.
پس از این مرحله یک ارتباط رمزنگاریشده میان مرورگر و سرور شکل میگیرد و اطلاعات با امنیت بیشتری منتقل میشوند.
HTTPS نسخه امن HTTP است.
در HTTP عادی اطلاعات بدون لایه رمزنگاری TLS منتقل میشوند.
در HTTPS ارتباط میان مرورگر و سرور رمزنگاری میشود و این موضوع احتمال مشاهده یا تغییر اطلاعات در مسیر ارتباط را کاهش میدهد.
امروزه استفاده از HTTPS برای تقریباً تمام وبسایتهای عمومی توصیه میشود.
تفاوت اصلی این دو پروتکل در وجود لایه رمزنگاری است.
HTTP اطلاعات را به صورت عادی منتقل میکند، اما HTTPS ارتباط را با TLS محافظت میکند.
در HTTPS همچنین مرورگر میتواند اعتبار دامنه و Certificate ارائهشده توسط سرور را بررسی کند.
به همین دلیل سایتهایی که فرم ورود، پرداخت یا اطلاعات کاربران دارند باید از HTTPS استفاده کنند.
تقریباً هر وبسایت امروزی باید از SSL استفاده کند.
حتی اگر سایت فروشگاهی نباشد، فرم تماس، Login یا سیستم مدیریت محتوا همچنان اطلاعات میان کاربر و سرور منتقل میکنند.
HTTPS علاوه بر امنیت، بخشی از استانداردهای فعلی وب محسوب میشود.
مرورگرهای جدید نیز برای سایتهای بدون HTTPS ممکن است هشدار Not Secure نمایش دهند.
سایت شرکتی معمولاً دارای فرم تماس، پنل مدیریت و گاهی حساب کاربران است.
با فعالسازی SSL اطلاعات این بخشها به صورت رمزنگاریشده منتقل میشوند.
همچنین آدرس رسمی شرکت با HTTPS در دسترس خواهد بود که ظاهر حرفهایتر و قابل اعتمادتری ایجاد میکند.
برای بسیاری از سایتهای شرکتی یک گواهی تک دامنه کافی است.
در فروشگاه اطلاعات بیشتری میان کاربر و سرور منتقل میشود.
ورود مشتری، آدرس، سبد خرید، Checkout و ارتباط با درگاه پرداخت همگی باید روی HTTPS انجام شوند.
وجود SSL برای یک فروشگاه آنلاین ضروری است.
اگر بخشی از فرآیند خرید روی HTTP باز شود، ممکن است مرورگر هشدار امنیتی نمایش دهد یا برخی سرویسهای پرداخت به درستی کار نکنند.
فروشگاههای WooCommerce روی WordPress اجرا میشوند و باید کل سایت از HTTPS استفاده کند.
صفحات Cart، Checkout، My Account و Login به امنیت ارتباط وابسته هستند.
پس از نصب SSL باید URLهای اصلی WordPress و WooCommerce نیز روی HTTPS تنظیم شوند.
وجود Mixed Content در قالب یا افزونهها نیز باید برطرف شود.
WordPress به صورت کامل از HTTPS پشتیبانی میکند.
پس از نصب Certificate باید آدرس WordPress Address و Site Address بررسی شوند.
اگر سایت قبلاً روی HTTP فعال بوده، Redirect صحیح از HTTP به HTTPS نیز اهمیت دارد.
تصاویر و فایلهای داخلی قدیمی نیز ممکن است نیاز به اصلاح URL داشته باشند.
Joomla نیز قابلیت اجرای کامل روی HTTPS را دارد.
پس از نصب گواهی میتوان Force HTTPS را در تنظیمات سیستم فعال کرد.
تمام افزونهها، قالبها و فایلهای داخلی باید با HTTPS بارگذاری شوند.
اگر یک فایل خارجی روی HTTP قرار داشته باشد، مرورگر ممکن است خطای Mixed Content نشان دهد.
در فروشگاه OpenCart باید گواهی روی Domain فعال باشد و تنظیمات URL امن به درستی انجام شوند.
صفحات Login، Checkout و Account از مهمترین بخشهایی هستند که باید تنها با HTTPS در دسترس باشند.
بعد از تغییر URLها بهتر است کل فرآیند خرید و اتصال به درگاه پرداخت آزمایش شود.
سایتهای ASP.NET روی IIS نیز میتوانند با گواهی SSL اجرا شوند.
Certificate ابتدا داخل Windows Server نصب و سپس به Binding دامنه در IIS متصل میشود.
برای چند سایت میتوان Certificateهای جداگانه یا گواهی مناسب چند دامنه استفاده کرد.
پروتکلهای قدیمی TLS نیز بهتر است در صورت عدم نیاز غیرفعال شوند.
نوع زبان برنامهنویسی تأثیری در اصل استفاده از SSL ندارد.
Laravel، PHP اختصاصی و سایر فریمورکها میتوانند روی HTTPS اجرا شوند.
Application باید URLهای امن را تشخیص دهد و Cookieهای حساس نیز بهتر است با Flagهای امنیتی مناسب تنظیم شوند.
اگر Reverse Proxy یا CDN استفاده میشود، تشخیص HTTPS در Backend نیز باید صحیح باشد.
روی VPS دسترسی بیشتری به Web Server دارید و میتوانید Certificate را مستقیماً نصب کنید.
در Linux معمولاً Nginx یا Apache مسئول ارائه HTTPS هستند.
در Windows نیز IIS گواهی را مدیریت میکند.
تمدید خودکار Certificate روی VPS اهمیت زیادی دارد، زیرا مسئولیت نگهداری سرور بر عهده مدیر آن است.
روی Dedicated Server نیز میتوانید برای تمام Domainهای میزبانیشده Certificate تعریف کنید.
اگر Control Panel نصب شده باشد، مدیریت SSL سادهتر خواهد بود.
در ساختار بدون پنل، Certificateها مستقیماً روی Nginx، Apache یا IIS نصب میشوند.
برای زیرساختهای بزرگ بهتر است تاریخ انقضای تمام گواهیها مانیتور شود.
SSLها را میتوان بر اساس نوع اعتبارسنجی و تعداد Domainهای تحت پوشش دستهبندی کرد.
DV، OV و EV از نظر سطح Validation متفاوت هستند.
Single Domain، Wildcard و Multi-Domain نیز مشخص میکنند چه تعداد Hostname با گواهی پوشش داده میشوند.
انتخاب نوع مناسب به ساختار سایت و نیاز کسبوکار بستگی دارد.
DV مخفف Domain Validation است.
در این نوع Certificate، صادرکننده بررسی میکند که درخواستکننده کنترل دامنه را در اختیار دارد.
این تأیید معمولاً از طریق DNS، Email یا فایل روی Web Server انجام میشود.
DV برای وبسایتهای شخصی، شرکتی و بسیاری از فروشگاههای آنلاین قابل استفاده است.
OV مخفف Organization Validation است.
در این مدل علاوه بر مالکیت Domain، اطلاعات سازمان یا شرکت نیز توسط صادرکننده بررسی میشود.
فرآیند صدور معمولاً از DV زمان بیشتری نیاز دارد.
OV برای سازمانها و کسبوکارهایی مناسب است که میخواهند اطلاعات هویتی شرکت در Certificate تأیید شده باشد.
EV مخفف Extended Validation است.
در این نوع گواهی فرآیند بررسی هویت سازمان گستردهتر است و مدارک بیشتری ممکن است درخواست شوند.
مرورگرهای جدید دیگر تفاوت بصری بزرگی میان EV و سایر Certificateها نمایش نمیدهند.
به همین دلیل انتخاب EV بیشتر به سیاست سازمان و سطح Validation مورد نیاز وابسته است.
در DV تنها کنترل Domain بررسی میشود.
در OV اطلاعات شرکت نیز در فرآیند صدور تأیید خواهد شد.
از نظر رمزنگاری، هر دو میتوانند ارتباط HTTPS امن ایجاد کنند.
تفاوت اصلی در سطح تأیید هویت صاحب Certificate است، نه قدرت پایه رمزنگاری اتصال.
EV فرآیند اعتبارسنجی گستردهتر و سختگیرانهتری نسبت به OV دارد.
برای شرکتهایی که نیاز رسمی یا سیاست امنیتی مشخص دارند، EV قابل بررسی است.
برای بسیاری از وبسایتهای عمومی، OV یا حتی DV از نظر ایجاد HTTPS کافی خواهد بود.
انتخاب باید بر اساس نیاز واقعی انجام شود.
گواهی Single Domain یک نام دامنه مشخص را پوشش میدهد.
برای مثال Certificate میتواند برای example.com صادر شود.
باید بررسی شود که آیا نسخه www نیز در SAN گواهی قرار دارد یا خیر.
برای سایتی که تنها یک Domain اصلی دارد این گزینه ساده و مناسب است.
Wildcard SSL برای پوشش چند Subdomain از یک Domain استفاده میشود.
برای مثال گواهی *.example.com میتواند shop.example.com، panel.example.com و بسیاری از Subdomainهای دیگر را پوشش دهد.
خود Domain اصلی example.com الزاماً تنها با Wildcard پوشش داده نمیشود و باید SANهای Certificate بررسی شوند.
این نوع گواهی برای زیرساختهای دارای Subdomain زیاد کاربرد دارد.
Multi-Domain SSL چند نام دامنه متفاوت را داخل یک Certificate پوشش میدهد.
این ساختار با استفاده از SAN یا Subject Alternative Name انجام میشود.
برای مثال میتوان چند Domain مستقل را با یک گواهی مدیریت کرد.
محدودیت تعداد SANها و قیمت به محصول صادرکننده بستگی دارد.
SAN مخفف Subject Alternative Name است.
Certificate میتواند علاوه بر نام اصلی، چند Hostname دیگر را نیز پوشش دهد.
این قابلیت برای چند دامنه، چند Subdomain یا سرویسهای سازمانی کاربرد دارد.
تمام نامهایی که قرار است روی Certificate معتبر باشند باید در SANهای آن وجود داشته باشند.
اگر چند Subdomain از یک Domain دارید، Wildcard معمولاً ساختار سادهتری دارد.
اگر چند Domain کاملاً متفاوت دارید، Multi-Domain مناسبتر است.
برای مثال api.example.com و shop.example.com میتوانند با Wildcard پوشش داده شوند، اما example.com و anotherdomain.net نیاز به SAN یا Certificate جدا خواهند داشت.
گواهیهای رایگان مانند Let’s Encrypt برای ایجاد ارتباط HTTPS امن بسیار پرکاربرد هستند.
Certificate تجاری ممکن است امکانات متفاوتی در Support، Validation یا Warranty ارائه دهد.
از نظر رمزنگاری استاندارد، یک Certificate رایگان معتبر نیز میتواند اتصال HTTPS امن ایجاد کند.
انتخاب میان رایگان و تجاری بیشتر به نیاز سازمان و نوع Validation بستگی دارد.
Let’s Encrypt یک Certificate Authority عمومی است که گواهی DV رایگان صادر میکند.
این گواهیها اعتبار کوتاهمدت دارند و معمولاً با ابزارهای خودکار تمدید میشوند.
برای سایتهای معمولی و بسیاری از سرویسهای آنلاین گزینه مناسبی هستند.
اتوماسیون Renewal بخش مهم استفاده صحیح از Let’s Encrypt است.
اگر به OV، EV، Warranty یا Support مشخصی نیاز دارید، Certificate تجاری قابل بررسی است.
بعضی سازمانها نیز بر اساس Policy داخلی از برندهای خاص Certificate Authority استفاده میکنند.
برای سایت سادهای که تنها HTTPS نیاز دارد، همیشه خرید گواهی تجاری ضرورت ندارد.
Certificate Authority یا CA شرکتی است که گواهی دیجیتال صادر میکند.
مرورگرها لیستی از Root CAهای قابل اعتماد را در سیستم خود نگهداری میکنند.
گواهی سایت باید در نهایت به یکی از این Rootهای معتبر زنجیره شود تا مرورگر آن را Trusted تشخیص دهد.
Certificate Chain مجموعه گواهیهایی است که Certificate سایت را به Root CA متصل میکند.
معمولاً علاوه بر Certificate اصلی، یک یا چند Intermediate Certificate نیز وجود دارند.
اگر Chain ناقص نصب شود، بعضی مرورگرها یا Clientها ممکن است خطای اعتماد نمایش دهند.
نصب صحیح Intermediateها اهمیت زیادی دارد.
Root Certificate بالاترین سطح اعتماد در زنجیره Certificate است.
این گواهی معمولاً از قبل داخل سیستمعامل یا Browser وجود دارد.
سرور معمولاً Root را مستقیماً به عنوان Certificate سایت استفاده نمیکند.
وبسرور باید Certificate دامنه و Intermediateهای مربوطه را ارائه دهد.
Intermediate CA میان Root و Certificate سایت قرار دارد.
Certificate Authorityها معمولاً Certificate نهایی را با Intermediate امضا میکنند.
اگر Intermediate درست روی سرور ارائه نشود، Chain ناقص خواهد بود.
در بعضی سیستمها فایل CA Bundle شامل همین Certificateها است.
CA Bundle مجموعه Certificateهای میانی مورد نیاز برای تکمیل Chain است.
بعضی صادرکنندگان آن را به صورت فایل جداگانه ارائه میدهند.
در Apache، Nginx، Plesk یا سایر سیستمها باید Certificate Chain به صورت صحیح تعریف شود.
CSR مخفف Certificate Signing Request است.
این فایل هنگام درخواست SSL تولید میشود و شامل Public Key و اطلاعات مربوط به Domain است.
CSR با Private Key مرتبط است.
Private Key باید روی سرور امن باقی بماند و برای Certificate Authority ارسال نشود.
Private Key بخشی محرمانه از ساختار SSL است.
این کلید هنگام ساخت CSR تولید میشود و برای برقراری ارتباط امن استفاده خواهد شد.
اگر Private Key گم شود، Certificate مربوط به آن قابل استفاده نخواهد بود.
اگر Key افشا شود، بهتر است Certificate Revoke و مجدداً صادر شود.
Public Key داخل CSR و Certificate قرار میگیرد و میتواند به صورت عمومی منتشر شود.
این کلید با Private Key یک جفت رمزنگاری ایجاد میکند.
Client از اطلاعات Certificate برای ایجاد ارتباط امن با Server استفاده میکند.
امنیت سیستم به محرمانه ماندن Private Key وابسته است.
CSR معمولاً روی همان Server یا Control Panelی ساخته میشود که Certificate قرار است روی آن نصب شود.
در زمان ساخت اطلاعاتی مانند Common Name و در بعضی Certificateها اطلاعات سازمان وارد میشوند.
پس از صدور باید Certificate روی همان سیستمی نصب شود که Private Key مربوطه را دارد.
Common Name یا CN نام اصلی Certificate است.
در Certificateهای جدید، Browserها بیشتر به SANها برای اعتبار نام Domain توجه میکنند.
با این حال CN همچنان در ساختار Certificate وجود دارد.
نامی که کاربران با آن وارد سایت میشوند باید توسط Certificate پوشش داده شود.
اگر سایت هم از example.com و هم www.example.com استفاده میکند، بهتر است هر دو نام توسط Certificate پوشش داده شوند.
سپس یکی از نسخهها به عنوان آدرس اصلی انتخاب و نسخه دیگر Redirect شود.
اگر Certificate تنها یکی از آنها را پوشش دهد، ورود مستقیم به نسخه دیگر ممکن است خطای SSL ایجاد کند.
هر Subdomain یک Hostname مستقل محسوب میشود.
میتوانید برای هر Subdomain Certificate جدا تهیه کنید یا از Wildcard و Multi-Domain استفاده نمایید.
برای مثال api.example.com باید توسط Certificate معتبر پوشش داده شود.
چند Domain میتوانند روی یک IP و یک Web Server Certificateهای جداگانه داشته باشند.
فناوری SNI باعث میشود Server برای هر Hostname Certificate صحیح را ارائه دهد.
مرورگرهای مدرن از SNI پشتیبانی میکنند.
در نتیجه معمولاً برای هر SSL نیاز به IPv4 جداگانه وجود ندارد.
Server Name Indication بخشی از TLS است که به Client اجازه میدهد هنگام شروع ارتباط نام Domain مورد نظر را اعلام کند.
Server بر اساس این نام Certificate مناسب را انتخاب میکند.
این قابلیت میزبانی چند سایت HTTPS روی یک IP را امکانپذیر میکند.
در cPanel میتوان Certificate، Private Key و CA Bundle را از بخش SSL/TLS نصب کرد.
اگر AutoSSL فعال باشد ممکن است گواهی به صورت خودکار صادر شود.
پس از نصب باید HTTPS و Redirect بررسی شوند.
نام بخشها میتواند بسته به نسخه پنل متفاوت باشد.
DirectAdmin نیز بخش مدیریت SSL Certificates دارد.
میتوان Certificate و Private Key را وارد کرد یا در صورت پشتیبانی از Let’s Encrypt استفاده نمود.
برای Wildcard ممکن است DNS Validation مورد نیاز باشد.
پس از نصب بهتر است Domain با ابزار بررسی SSL آزمایش شود.
در Plesk میتوان از بخش SSL/TLS Certificates گواهی جدید اضافه کرد.
Let’s Encrypt نیز معمولاً از طریق Extension یا امکانات داخلی قابل استفاده است.
Certificate باید سپس برای Hosting، Mail یا سایر سرویسهای مورد نیاز انتخاب شود.
در Nginx مسیر Certificate و Private Key داخل Server Block تعریف میشود.
معمولاً از ssl_certificate و ssl_certificate_key استفاده خواهد شد.
پس از تغییر Configuration باید Syntax بررسی و Nginx Reload شود.
Chain نیز باید در فایل Certificate به صورت صحیح قرار داشته باشد.
در Apache گواهی داخل Virtual Host مربوط به Port 443 تعریف میشود.
مسیر Certificate و Private Key باید صحیح باشند.
بسته به نسخه Apache، Chain نیز با روش مناسب تنظیم میشود.
پس از تغییرات بهتر است Configuration Test و سپس Reload انجام شود.
در Windows Server ابتدا Certificate داخل Certificate Store وارد میشود.
سپس در IIS Binding مربوط به HTTPS ایجاد و Certificate انتخاب میشود.
اگر چند سایت روی یک IP هستند میتوان از SNI استفاده کرد.
Private Key نیز باید همراه Certificate در Windows در دسترس باشد.
Tomcat میتواند TLS را مستقیماً مدیریت کند یا پشت Reverse Proxy قرار گیرد.
در بسیاری از معماریها Nginx یا Apache SSL را Terminate میکند و Tomcat روی شبکه داخلی پاسخ میدهد.
اگر TLS مستقیماً روی Java اجرا شود، ممکن است نیاز به KeyStore داشته باشید.
Node.js میتواند HTTPS را مستقیماً اجرا کند، اما در Production معمولاً SSL روی Reverse Proxy مانند Nginx مدیریت میشود.
این روش Renewal و مدیریت چند Domain را سادهتر میکند.
Application سپس روی Port داخلی و بدون دسترسی عمومی اجرا میشود.
Laravel به صورت مستقیم Certificate را مدیریت نمیکند و این وظیفه معمولاً بر عهده Web Server است.
پس از فعالسازی HTTPS باید APP_URL و تنظیمات Proxy در صورت نیاز بررسی شوند.
Cookieها و Sessionهای حساس نیز بهتر است Secure باشند.
Django، Flask و FastAPI معمولاً پشت Nginx، Caddy یا Load Balancer اجرا میشوند.
TLS در همین لایه Terminate میشود.
Application Server مانند Gunicorn یا Uvicorn میتواند روی Localhost یا Private Network باقی بماند.
اگر CDN استفاده میکنید، معمولاً دو ارتباط وجود دارد.
یکی ارتباط کاربر با CDN و دیگری ارتباط CDN با Origin Server است.
بهتر است هر دو بخش از HTTPS استفاده کنند.
حالتهایی که ارتباط CDN تا Origin بدون SSL است امنیت End-to-End کمتری ایجاد میکنند.
در سرویسهایی مانند Cloudflare حالتهای مختلف SSL میان Edge و Origin وجود دارند.
برای ساختار امن بهتر است Origin نیز Certificate معتبر داشته باشد.
استفاده از حالتهایی که تنها سمت کاربر HTTPS است اما Origin با HTTP کار میکند برای پروژه حساس مناسب نیست.
تنظیم دقیق باید بر اساس معماری سرویس انجام شود.
در زیرساخت چندسروری میتوان Certificate را روی Load Balancer نصب کرد.
در این حالت Client تا Load Balancer با HTTPS ارتباط دارد و سپس ترافیک به Backendها منتقل میشود.
ارتباط داخلی نیز میتواند TLS داشته باشد.
این روش مدیریت Certificate را در معماری چند Node سادهتر میکند.
TLS Termination به نقطهای گفته میشود که ارتباط رمزنگاریشده Client باز میشود.
این نقطه میتواند Web Server، CDN یا Load Balancer باشد.
بعد از Termination ترافیک میتواند دوباره رمزنگاری یا روی شبکه خصوصی منتقل شود.
انتخاب معماری باید با سطح امنیت مورد نیاز هماهنگ باشد.
HTTPS یکی از استانداردهای وب و یکی از سیگنالهای مورد استفاده موتورهای جستجو است.
با این حال نصب SSL به تنهایی باعث جهش بزرگ در رتبه سایت نمیشود.
کیفیت محتوا، لینکها، Performance و ساختار فنی عوامل مهمتری هستند.
استفاده صحیح از HTTPS از نظر امنیت، اعتماد و سلامت فنی سایت ضروری است.
بعد از نصب Certificate باید تمام URLهای سایت به HTTPS منتقل شوند.
Redirect دائمی از HTTP به HTTPS باید فعال باشد.
Sitemap، Canonical، لینکهای داخلی و تنظیمات ابزارهای تحلیل نیز بهتر است روی نسخه HTTPS تنظیم شوند.
این مهاجرت باید به شکلی انجام شود که دو نسخه جدا از سایت در دسترس باقی نمانند.
هر درخواست HTTP بهتر است به نسخه HTTPS همان URL هدایت شود.
برای سایت دائمی معمولاً Redirect 301 استفاده میشود.
این Redirect میتواند در Web Server، CDN یا Control Panel تنظیم شود.
وجود چند Redirect پشت سر هم بهتر است کاهش داده شود.
Mixed Content زمانی رخ میدهد که صفحه HTTPS بعضی فایلها را از HTTP بارگذاری کند.
برای مثال ممکن است تصویر، CSS یا JavaScript قدیمی هنوز آدرس http:// داشته باشد.
مرورگر ممکن است این فایلها را Block کند یا هشدار نمایش دهد.
تمام منابع صفحه بهتر است از HTTPS بارگذاری شوند.
ابتدا URLهای HTTP داخل HTML، CSS و Database بررسی میشوند.
در WordPress ممکن است لینکهای قدیمی داخل دیتابیس نیاز به اصلاح داشته باشند.
فایلهای خارجی نیز باید نسخه HTTPS داشته باشند.
استفاده از Replace بدون Backup دیتابیس توصیه نمیشود.
HTTP Strict Transport Security به مرورگر اعلام میکند که Domain باید تنها از طریق HTTPS باز شود.
پس از دریافت این Header، Browser برای مدت مشخص دیگر نسخه HTTP را امتحان نمیکند.
HSTS امنیت را افزایش میدهد اما باید با دقت فعال شود.
اگر HTTPS خراب شود، کاربران تا پایان مدت Policy ممکن است امکان عبور به HTTP را نداشته باشند.
برخی Domainها میتوانند در فهرست HSTS Preload مرورگرها قرار گیرند.
در این حالت حتی اولین درخواست نیز مستقیم با HTTPS انجام میشود.
ورود به این فهرست تصمیم مهمی است و باید تمام Subdomainهای مورد نیاز برای HTTPS آماده باشند.
حذف از Preload نیز فوری نیست.
TLS مخفف Transport Layer Security است و نسخه مدرن پروتکل رمزنگاری ارتباط اینترنتی محسوب میشود.
اصطلاح SSL هنوز در بازار استفاده میشود، اما وبسرورهای امروزی باید از نسخههای امن TLS استفاده کنند.
TLS 1.2 و TLS 1.3 از نسخههای رایج در زیرساختهای جدید هستند.
TLS 1.2 همچنان توسط طیف گستردهای از Clientها پشتیبانی میشود.
بسیاری از زیرساختها آن را در کنار TLS 1.3 فعال نگه میدارند.
Cipherهای ضعیف باید غیرفعال شوند.
تنظیم دقیق باید با سازگاری کاربران و سیاست امنیتی هماهنگ باشد.
TLS 1.3 نسخه جدیدتری است که فرآیند Handshake سادهتر و مجموعه الگوریتمهای مدرنتری دارد.
Browserهای جدید از آن پشتیبانی میکنند.
معمولاً TLS 1.3 در کنار TLS 1.2 فعال میشود تا Clientهای قدیمیتر نیز بتوانند متصل شوند.
پروتکلهای قدیمی مانند SSLv2، SSLv3، TLS 1.0 و TLS 1.1 برای محیط مدرن مناسب نیستند.
در Serverهای جدید بهتر است این نسخهها در صورت نبود نیاز Legacy غیرفعال شوند.
پشتیبانی از یک Client بسیار قدیمی نباید بدون بررسی باعث فعال نگه داشتن پروتکلهای ناامن شود.
Cipher Suite مجموعه الگوریتمهایی است که برای رمزنگاری ارتباط استفاده میشوند.
در نسخههای مختلف TLS نحوه تعریف Cipherها متفاوت است.
وبسرور باید Cipherهای امن و سازگار با Clientهای مورد نیاز را ارائه دهد.
تنظیم بسیار قدیمی میتواند امنیت را کاهش دهد و تنظیم بیش از حد محدود نیز ممکن است Clientهای لازم را قطع کند.
Handshake مرحله اولیه ایجاد ارتباط TLS است.
در این مرحله Client و Server درباره نسخه TLS و پارامترهای ارتباط توافق میکنند.
Certificate نیز در همین فرآیند توسط Server ارائه میشود.
بعد از تکمیل Handshake، اطلاعات Application به صورت رمزنگاریشده منتقل میشوند.
SSL Error زمانی رخ میدهد که Browser نتواند Certificate یا ارتباط TLS را معتبر تشخیص دهد.
علت میتواند انقضای Certificate، نام اشتباه Domain، Chain ناقص یا تنظیم نادرست Server باشد.
پیام دقیق Browser معمولاً اطلاعات مهمی درباره علت ارائه میدهد.
Certificate دارای تاریخ شروع و پایان اعتبار است.
اگر گواهی تا تاریخ انقضا تمدید یا جایگزین نشود، Browser هشدار امنیتی نمایش میدهد.
این مشکل برای سایتهای تجاری میتواند باعث کاهش اعتماد و توقف فرآیند خرید شود.
به همین دلیل مانیتورینگ Expiration اهمیت زیادی دارد.
اگر Certificate برای example.com صادر شده باشد اما کاربر وارد Hostname دیگری شود که داخل SAN نیست، مرورگر خطای نام نمایش میدهد.
این مشکل معمولاً در Subdomain یا نسخه www رخ میدهد.
تمام Hostnameهای مورد استفاده باید توسط Certificate پوشش داده شوند.
Self-Signed Certificate توسط خود Server امضا میشود و به CA عمومی متصل نیست.
برای محیط آزمایشی یا شبکه داخلی میتواند کاربرد داشته باشد.
مرورگرهای عمومی به صورت پیشفرض به آن اعتماد ندارند و هشدار نمایش خواهند داد.
برای سایت عمومی بهتر است از Certificate معتبر عمومی استفاده شود.
گواهی معمولاً برای Domain صادر میشود.
صدور Certificate عمومی برای IP شرایط خاصتری دارد و همه CAها یا محصولات آن را پشتیبانی نمیکنند.
برای بیشتر وبسایتها بهتر است از Domain استفاده شود.
برای محیط Development میتوان از Certificateهای Local یا Self-Signed استفاده کرد.
مرورگر تنها زمانی بدون هشدار اعتماد میکند که CA محلی به سیستم اضافه شده باشد.
Certificate عمومی معمولاً برای localhost صادر نمیشود.
گواهیها مدت اعتبار مشخصی دارند.
امروزه Certificateهای عمومی معمولاً با دورههای کوتاهتر صادر و سپس تمدید میشوند.
مدت دقیق به نوع Certificate و CA بستگی دارد.
بهتر است Renewal به شکل خودکار یا با Reminder مطمئن مدیریت شود.
SSL باید قبل از Expiration تمدید یا Reissue شود.
در گواهیهای خودکار این کار توسط Agent روی Server انجام میشود.
برای Certificateهای تجاری ممکن است نیاز باشد فرآیند تمدید از پنل انجام شود.
پس از تمدید باید Certificate جدید روی Server نصب شود.
تمدید خودکار یکی از بهترین روشهای جلوگیری از انقضای ناگهانی است.
ابزار باید بتواند Validation را انجام داده و Certificate جدید را نصب یا Reload کند.
صرف فعال بودن Job کافی نیست و بهتر است نتیجه Renewal مانیتور شود.
Reissue زمانی استفاده میشود که نیاز دارید Certificate با CSR جدید یا مشخصات جدید دوباره صادر شود.
برای مثال ممکن است Private Key قبلی گم یا افشا شده باشد.
شرایط Reissue به CA و نوع محصول بستگی دارد.
Revocation به معنی لغو اعتبار Certificate قبل از تاریخ انقضا است.
اگر Private Key افشا شده باشد یا Certificate اشتباه صادر شده باشد، میتوان آن را Revoke کرد.
مرورگرها و سیستمها از روشهایی برای بررسی وضعیت Revocation استفاده میکنند.
Certificate Revocation List فهرستی از Certificateهای لغوشده است.
Client میتواند برای بررسی وضعیت Certificate از اطلاعات CRL استفاده کند.
این روش یکی از سازوکارهای قدیمیتر بررسی Revocation است.
Online Certificate Status Protocol برای بررسی آنلاین وضعیت Certificate استفاده میشود.
Client میتواند از CA بپرسد Certificate هنوز معتبر است یا لغو شده است.
برای کاهش وابستگی مستقیم Client به CA، OCSP Stapling قابل استفاده است.
در OCSP Stapling سرور پاسخ اعتبار Certificate را از CA دریافت و همراه Handshake به Client ارائه میکند.
این روش میتواند زمان و حریم خصوصی ارتباط را بهتر کند.
پشتیبانی و تنظیم آن به Web Server بستگی دارد.
فروشگاههایی که در فرآیند پرداخت با دادههای کارت بانکی سروکار دارند ممکن است تحت الزامات PCI DSS قرار بگیرند.
استفاده از TLS امن یکی از بخشهای امنیت ارتباط است.
اما نصب SSL به تنهایی به معنی انطباق کامل با PCI نیست.
معماری پرداخت، Server و سایر کنترلهای امنیتی نیز باید بررسی شوند.
Login Form باید روی HTTPS باشد.
ارسال Username و Password روی HTTP میتواند اطلاعات را در مسیر ارتباط در معرض مشاهده قرار دهد.
همچنین بهتر است کل Session کاربر و نه فقط صفحه Login روی HTTPS باقی بماند.
فرم تماس نیز اطلاعات شخصی مانند نام، Email و شماره تماس دریافت میکند.
این دادهها بهتر است روی ارتباط رمزنگاریشده ارسال شوند.
حتی سایتهایی که حساب کاربری ندارند نیز به همین دلیل از SSL بهره میبرند.
APIها نیز باید از HTTPS استفاده کنند.
Tokenهای Authorization، Sessionها و دادههای Application نباید روی HTTP عمومی منتقل شوند.
برای سرویسهای Server-to-Server نیز TLS اهمیت دارد.
در برخی زیرساختهای حساس Mutual TLS نیز استفاده میشود.
Mutual TLS علاوه بر تأیید Server، هویت Client را نیز با Certificate بررسی میکند.
در HTTPS معمولی تنها Server Certificate ارائه میدهد.
در mTLS هر دو طرف Certificate دارند.
این ساختار در APIهای سازمانی و ارتباط سرویسهای حساس کاربرد دارد.
WebSocket امن با wss:// اجرا میشود.
این اتصال نیز از TLS استفاده میکند.
اگر سایت اصلی HTTPS باشد، استفاده از WebSocket ناامن ممکن است توسط Browser محدود شود.
Certificate باید Hostname سرویس WebSocket را نیز پوشش دهد.
Email Serverها نیز از Certificate برای TLS استفاده میکنند.
SMTP، IMAP و POP3 میتوانند ارتباط رمزنگاریشده داشته باشند.
Certificate باید Hostname مورد استفاده Clientها مانند mail.example.com را پوشش دهد.
این SSL جدا از Certificate سایت میتواند باشد یا از همان Multi-Domain Certificate استفاده شود.
FTPS از TLS برای رمزنگاری FTP استفاده میکند.
این فناوری با SFTP متفاوت است.
SFTP روی SSH اجرا میشود و ارتباطی با SSL Certificate ندارد.
برای سرویس FTPS Certificate معتبر روی Server مورد نیاز خواهد بود.
اگر چند سرویس مانند mail.example.com، panel.example.com و api.example.com دارید، Wildcard میتواند مدیریت Certificate را سادهتر کند.
با این حال نگهداری یک Private Key مشترک روی چند Server ریسک امنیتی بیشتری ایجاد میکند.
در زیرساختهای جدا ممکن است Certificateهای مستقل انتخاب بهتری باشند.
Private Key نباید داخل Repository، Email عمومی یا Chat ذخیره شود.
Permission فایل باید محدود باشد.
در Serverهای چندکاربره تنها سرویس مورد نیاز باید به Key دسترسی داشته باشد.
در صورت افشای Key بهتر است Certificate جدید صادر شود.
بعضی Private Keyها با Passphrase محافظت میشوند.
برای Web Serverهایی که باید بعد از Restart خودکار بالا بیایند، استفاده از Key رمزدار میتواند مدیریت Startup را پیچیده کند.
امنیت فایل و دسترسی سیستم در هر دو حالت اهمیت دارد.
RSA یکی از الگوریتمهای رایج برای Certificateها است.
اندازه کلید متداول باید با استانداردهای فعلی و سازگاری Clientها هماهنگ باشد.
کلیدهای بسیار قدیمی و کوتاه مناسب نیستند.
ECDSA از رمزنگاری مبتنی بر منحنی بیضوی استفاده میکند.
این نوع Certificate میتواند کلید کوچکتر و Performance مناسبی داشته باشد.
سازگاری Clientهای بسیار قدیمی باید بررسی شود.
برخی Serverها میتوانند همزمان Certificate RSA و ECDSA ارائه دهند.
TLS مقداری پردازش برای Handshake و Encryption ایجاد میکند.
روی سختافزار مدرن این سربار برای اکثر سایتها بسیار کم است.
TLS 1.3 و Session Resumption نیز میتوانند هزینه Handshake را کاهش دهند.
نباید برای افزایش Performance سایت SSL را غیرفعال کرد.
Browserها HTTP/2 را روی وب عمومی معمولاً همراه HTTPS استفاده میکنند.
این پروتکل امکان مدیریت بهتر چند درخواست روی یک Connection را فراهم میکند.
Web Server باید HTTP/2 را پشتیبانی و فعال داشته باشد.
HTTP/3 بر پایه QUIC اجرا میشود و برای ارتباط امن از TLS 1.3 استفاده میکند.
پشتیبانی از آن در CDNها و برخی Web Serverها در حال گسترش است.
فعال بودن HTTP/3 برای داشتن SSL ضروری نیست.
TLS Session Resumption اجازه میدهد Client در اتصالهای بعدی بخشی از فرآیند Handshake را کوتاهتر کند.
این قابلیت میتواند Latency ارتباطهای تکراری را کاهش دهد.
تنظیم آن معمولاً توسط Web Server یا Load Balancer انجام میشود.
این خطا معمولاً به تاریخ Certificate یا ساعت سیستم مربوط است.
ممکن است Certificate منقضی شده باشد یا هنوز زمان اعتبار آن شروع نشده باشد.
ساعت اشتباه دستگاه Client نیز میتواند باعث این پیام شود.
این خطا معمولاً زمانی نمایش داده میشود که Hostname با نامهای داخل Certificate مطابقت ندارد.
برای مثال Certificate تنها برای Domain اصلی صادر شده اما Subdomain دیگری باز شده است.
SANها باید بررسی شوند.
اگر Intermediate Certificate نصب نشده باشد، بعضی Clientها ممکن است Certificate را Trusted تشخیص ندهند.
این مشکل با نصب Full Chain صحیح رفع میشود.
سرور باید Certificate اصلی و Intermediateهای لازم را ارائه دهد.
بعد از فعالسازی HTTPS ممکن است تنظیم اشتباه Proxy یا Application باعث Redirect Loop شود.
برای مثال CDN تصور میکند Origin روی HTTP است و Application دوباره آن را به HTTPS هدایت میکند.
Headerهای Proxy و تنظیم Scheme باید بررسی شوند.
این خطا به خود Certificate مربوط نیست.
صفحه HTTPS است اما بعضی منابع هنوز روی HTTP درخواست میشوند.
URL فایلها، قالب و دیتابیس باید بررسی شوند.
در DevTools مرورگر میتوان Resource مشکلدار را مشاهده کرد.
اگر یک Domain از طریق Load Balancer یا چند Web Server ارائه میشود، همه Nodeهایی که TLS Termination انجام میدهند باید Certificate مناسب داشته باشند.
میتوان Certificate را روی Load Balancer مرکزی نگهداری کرد یا روی Nodeها نصب نمود.
روش مناسب به معماری بستگی دارد.
در زیرساخت چند Node باید Certificate جدید به تمام نقاط لازم توزیع شود.
اتوماسیون این فرآیند اهمیت زیادی دارد.
اگر یک Node Certificate قدیمی داشته باشد ممکن است بخشی از کاربران خطای SSL دریافت کنند.
Containerها معمولاً پشت Reverse Proxy اجرا میشوند و TLS روی Proxy مدیریت میشود.
این ساختار از قرار دادن Private Key داخل هر Container جلوگیری میکند.
در Kubernetes نیز Ingress Controller یا Load Balancer میتواند Certificate را مدیریت کند.
Kubernetes Secret میتواند Certificate و Private Key را نگهداری کند.
Ingress Controller از این Secret برای HTTPS استفاده میکند.
ابزارهایی مانند cert-manager نیز میتوانند صدور و Renewal را خودکار کنند.
دسترسی به Secretها باید محدود باشد.
در Docker Compose میتوان Nginx، Traefik یا Caddy را در جلوی Containerها قرار داد.
TLS روی همان سرویس مدیریت میشود.
Volume یا Secretهای مربوط به Certificate باید به صورت امن تعریف شوند.
وقتی Reverse Proxy استفاده میشود، SSL معمولاً روی Proxy Terminate میشود.
Backend میتواند HTTP داخلی یا HTTPS داشته باشد.
اگر Proxy پشت CDN قرار دارد، چند لایه TLS ممکن است وجود داشته باشد.
هر لایه باید به درستی تنظیم شود تا Redirect Loop یا خطای Scheme ایجاد نشود.
اگر تنها یک سایت با یک Domain دارید، Single Domain SSL معمولاً کافی است.
باید بررسی شود نسخه www و بدون www هر دو تحت پوشش باشند.
اگر Subdomainهای زیادی دارید، Wildcard میتواند گزینه مناسبتری باشد.
نوع DV، OV یا EV نیز بر اساس سطح اعتبارسنجی مورد نیاز انتخاب میشود.
برای چند Domain میتوانید Certificateهای جداگانه یا Multi-Domain تهیه کنید.
Certificate جدا مدیریت مستقلتری دارد.
Multi-Domain تعداد فایلهای Certificate را کاهش میدهد، اما تغییر یکی از Domainها ممکن است نیازمند Reissue کل Certificate باشد.
Wildcard برای سازمانهایی مناسب است که Subdomainهای متعدد روی یک Domain دارند.
قبل از خرید باید مشخص شود چه سطحی از Subdomainها پوشش داده میشود.
*.example.com معمولاً یک سطح مانند api.example.com را پوشش میدهد و لزوماً v2.api.example.com را پوشش نمیدهد.
Wildcard معمولی تنها یک Label را جایگزین میکند.
بنابراین *.example.com برای shop.example.com مناسب است ولی برای test.shop.example.com معمولاً کافی نیست.
برای ساختار چندسطحی باید Certificate و SANهای مناسب انتخاب شوند.
برای شرکتهایی که به نمایش هویت تأییدشده سازمان در Certificate نیاز دارند، OV یا EV قابل بررسی هستند.
مدارک مورد نیاز به CA و کشور شرکت بستگی دارند.
فرآیند صدور میتواند از DV طولانیتر باشد.
DV معمولاً پس از تأیید کنترل Domain سریع صادر میشود.
OV و EV به دلیل بررسی اطلاعات سازمان زمان بیشتری نیاز دارند.
زمان دقیق به CA، مدارک و سرعت پاسخگویی متقاضی بستگی دارد.
برای صدور DV باید کنترل Domain اثبات شود.
روش Validation میتواند DNS Record، Email یا فایل HTTP باشد.
پس از موفقیت Validation، CA اجازه صدور Certificate را خواهد داشت.
در DNS Validation یک TXT یا CNAME خاص روی Domain ساخته میشود.
CA وجود رکورد را بررسی و کنترل Domain را تأیید میکند.
این روش برای Wildcard Certificate بسیار رایج است.
پس از صدور میتوان بر اساس روش CA درباره نگهداری یا حذف رکورد تصمیم گرفت.
در این روش یک فایل یا Token در مسیر مشخصی از سایت قرار میگیرد.
CA از طریق HTTP یا HTTPS آن را دریافت میکند.
Domain باید از اینترنت عمومی به Server صحیح Resolve شود.
Firewall یا Redirect اشتباه میتواند Validation را مختل کند.
بعضی CAها امکان تأیید از طریق Emailهای استاندارد Domain را ارائه میدهند.
پیام به آدرسی مانند [email protected] یا اطلاعات ثبت Domain ارسال میشود.
کاربر با کلیک روی لینک مالکیت را تأیید میکند.
روشهای موجود به CA بستگی دارند.
Wildcard Certificate معمولاً نیازمند DNS Validation است.
این موضوع به CA و استانداردهای صدور بستگی دارد.
اگر DNS Provider API داشته باشد میتوان Renewal Wildcard را نیز خودکار کرد.
انتقال Registrar به تنهایی Certificate نصبشده روی Server را تغییر نمیدهد.
تا زمانی که Domain همان نام باقی بماند و DNS به Server فعلی اشاره کند، SSL میتواند به کار خود ادامه دهد.
برای Renewal آینده باید همچنان امکان انجام Domain Validation وجود داشته باشد.
در انتقال سایت به هاست جدید، Certificate نیز باید روی Server مقصد فعال باشد.
اگر Let’s Encrypt استفاده میشود میتوان روی Hosting جدید Certificate تازه صادر کرد.
قبل از تغییر DNS بهتر است HTTPS روی سرور مقصد آزمایش شود.
Certificate معمولاً به Domain وابسته است و تغییر IP آن را باطل نمیکند.
پس از انتقال DNS به IP جدید، Server جدید باید همان Domain را با Certificate معتبر ارائه دهد.
اگر نام Domain تغییر کند، Certificate قبلی برای نام جدید معتبر نیست.
باید Certificate جدید برای Domain تازه صادر شود.
هر دو Domain در دوره مهاجرت میتوانند Certificate مستقل داشته باشند.
اگر Single Domain SSL دارید، Subdomain جدید تحت پوشش قرار نمیگیرد مگر اینکه در SAN وجود داشته باشد.
میتوانید Certificate جدا صادر کنید، گواهی را Reissue با SAN جدید انجام دهید یا Wildcard استفاده کنید.
Certificateهای عمومی صادرشده معمولاً در Logهای Certificate Transparency ثبت میشوند.
این سیستم به شناسایی صدور اشتباه Certificate کمک میکند.
به همین دلیل نام Domainهای داخل Certificate عمومی قابل مشاهده هستند.
برای Hostnameهای داخلی حساس باید این موضوع در طراحی در نظر گرفته شود.
CAA Record در DNS مشخص میکند چه Certificate Authorityهایی اجازه صدور Certificate برای Domain را دارند.
اگر CAA به صورت محدود تنظیم شده باشد، CA دیگری نمیتواند Certificate صادر کند.
تنظیم اشتباه CAA میتواند فرآیند صدور SSL را متوقف کند.
CAA یک لایه کنترل اضافی برای صدور Certificate ایجاد میکند.
اما جایگزین امنیت Account Registrar و DNS نیست.
اگر مهاجم DNS را کنترل کند ممکن است تنظیمات دیگری را نیز تغییر دهد.
DNSSEC و SSL دو فناوری جداگانه هستند.
SSL ارتباط Application را رمزنگاری میکند و DNSSEC صحت پاسخ DNS را بررسی میکند.
استفاده همزمان از هر دو میتواند لایههای امنیتی متفاوتی ایجاد کند.
TLS اطلاعات را در مسیر ارتباط رمزنگاری میکند.
اما اطلاعات پس از رسیدن به Server توسط Application پردازش میشوند.
SSL از Database، فایلهای ذخیرهشده یا ضعف امنیتی Application محافظت نمیکند.
بنابراین HTTPS تنها یکی از لایههای امنیت سایت است.
خیر.
SSL از شنود و تغییر اطلاعات در مسیر ارتباط محافظت میکند، اما جلوی تمام حملات را نمیگیرد.
SQL Injection، افزونه آسیبپذیر، رمز ضعیف یا بدافزار Server همچنان میتوانند خطر ایجاد کنند.
امنیت سایت نیازمند چند لایه کنترل است.
خیر.
SSL برای رمزنگاری ارتباط است و سرویس مقابله با DDoS محسوب نمیشود.
حفاظت DDoS باید در سطح شبکه، CDN یا زیرساخت مناسب انجام شود.
در واقع حملات TLS نیز میتوانند منابع Server را درگیر کنند.
Firewall و SSL دو نقش متفاوت دارند.
Firewall مشخص میکند چه Connectionهایی اجازه ورود یا خروج دارند.
SSL اطلاعات داخل Connection مجاز را رمزنگاری میکند.
برای Server امن معمولاً هر دو مورد نیاز هستند.
Web Application Firewall درخواستهای HTTP و HTTPS را برای شناسایی رفتارهای مشکوک بررسی میکند.
برای بررسی محتوای HTTPS، TLS معمولاً در همان WAF یا Proxy Terminate میشود.
WAF جایگزین کدنویسی امن نیست، اما میتواند یک لایه دفاعی اضافی ایجاد کند.
کاربران امروزی انتظار دارند سایت با HTTPS باز شود.
نمایش هشدار Not Secure میتواند اعتماد کاربر را کاهش دهد، به خصوص در صفحه Login یا خرید.
با این حال وجود قفل HTTPS به معنی معتبر بودن خود کسبوکار نیست.
SSL تنها امنیت ارتباط و در برخی انواع Certificate هویت سازمان را تأیید میکند.
مرورگرهای جدید نحوه نمایش وضعیت HTTPS را در طول زمان تغییر دادهاند.
ممکن است قفل کلاسیک همیشه با همان شکل قدیمی نمایش داده نشود.
مهم این است که Browser اتصال را Secure تشخیص دهد و Certificate معتبر باشد.
مرورگر ممکن است برای صفحات HTTP عبارت Not Secure نمایش دهد.
این هشدار نشان میدهد ارتباط کاربر با سایت رمزنگاری نشده است.
برای رفع آن باید SSL نصب و تمام سایت به HTTPS منتقل شود.
قیمت به نوع Validation، تعداد Domainها، Wildcard بودن و برند CA وابسته است.
OV و EV معمولاً از DV گرانتر هستند.
Multi-Domain و Wildcard نیز به دلیل پوشش گستردهتر میتوانند هزینه بیشتری داشته باشند.
خدمات جانبی و سطح Warranty نیز ممکن است در قیمت مؤثر باشند.
تمام Certificateها محصول یکسانی نیستند.
نوع اعتبارسنجی، تعداد SANها، Warranty و Support میتوانند متفاوت باشند.
قیمت بالاتر الزاماً به معنی رمزنگاری بسیار قویتر برای یک سایت معمولی نیست.
قبل از خرید باید مشخص شود کدام ویژگی واقعاً برای پروژه مورد نیاز است.
برای یک وبسایت معمولی، گواهی DV اقتصادی میتواند کاملاً مناسب باشد.
اگر تنها هدف فعالسازی HTTPS است، نیازی نیست به دلیل قیمت بالاتر سراغ EV بروید.
باید برند CA، سازگاری و شرایط Renewal نیز بررسی شوند.
استارتاپها معمولاً در ابتدای کار میتوانند با DV یا Let’s Encrypt شروع کنند.
با توسعه سازمان و ایجاد نیازهای رسمیتر، OV یا ساختار PKI متفاوت قابل بررسی است.
انتخاب Certificate باید متناسب با مرحله کسبوکار باشد.
سازمانهای بزرگ ممکن است چندین Domain، Subdomain و سرویس داخلی داشته باشند.
در این شرایط مدیریت Lifecycle Certificate اهمیت بیشتری از خرید یک گواهی منفرد دارد.
Inventory، Expiration Monitoring و Automation باید بخشی از فرآیند امنیت باشند.
سرویسهای مالی به سیاستهای امنیتی گستردهتری نیاز دارند.
TLS امن، Certificate معتبر، HSTS، WAF و کنترلهای امنیت Application باید در کنار یکدیگر استفاده شوند.
نوع Certificate تنها بخشی از این معماری است.
پنلهایی مانند Plesk، DirectAdmin، Webmin یا پنل اختصاصی نیز باید HTTPS داشته باشند.
Certificate میتواند برای Hostname مدیریت مانند panel.example.com صادر شود.
پنل مدیریتی بهتر است علاوه بر SSL با Firewall و 2FA نیز محافظت شود.
Webmail اطلاعات Login و Email کاربران را منتقل میکند و باید از HTTPS استفاده کند.
Hostname سرویس مانند webmail.example.com باید Certificate معتبر داشته باشد.
برای IMAP و SMTP نیز TLS جداگانه باید به درستی تنظیم شود.
WHMCS شامل Login مشتری، سفارش، فاکتور و اطلاعات حساب است و باید کاملاً روی HTTPS اجرا شود.
URL اصلی سیستم و Callbackهای پرداخت باید با Domain امن هماهنگ باشند.
پس از تغییر SSL بهتر است فرآیند Login و Checkout آزمایش شود.
در Multisite ساختار Domainها اهمیت دارد.
اگر تمام سایتها Subdomain یک دامنه هستند، Wildcard میتواند مفید باشد.
اگر هر سایت Domain مستقل دارد، Certificateهای جدا یا Multi-Domain مورد نیاز خواهند بود.
نوع Domain Mapping باید قبل از انتخاب SSL مشخص شود.
Certificate و TLS باید با Clientهای مورد نیاز سازگار باشند.
پشتیبانی از Browser بسیار قدیمی ممکن است نیازمند فعال نگه داشتن الگوریتمهایی باشد که دیگر توصیه نمیشوند.
برای سایت عمومی مدرن بهتر است امنیت اولویت داشته باشد.
پس از نصب گواهی باید سایت از خارج Server آزمایش شود.
نام Domain، Expiration، Chain و Protocolهای فعال قابل بررسی هستند.
همچنین تمام صفحات اصلی، Login و Checkout باید با HTTPS تست شوند.
برای Certificateهای مهم بهتر است هشدار قبل از انقضا تنظیم شود.
اعتماد صرف به Email CA کافی نیست.
سیستم مانیتورینگ میتواند چند هفته قبل از Expiration هشدار ارسال کند.
این موضوع برای زیرساخت دارای دهها Certificate اهمیت بیشتری دارد.
در سازمانهای بزرگ بهتر است فهرستی از تمام Certificateها وجود داشته باشد.
Domain، CA، تاریخ انقضا، Server و مسئول هر Certificate باید مشخص باشند.
بدون Inventory ممکن است یک Certificate فراموششده باعث اختلال یک سرویس مهم شود.
ابزارهایی مانند ACME میتوانند صدور و Renewal Certificate را خودکار کنند.
Let’s Encrypt و برخی CAهای دیگر از این پروتکل استفاده میکنند.
اتوماسیون باعث کاهش خطای انسانی و انقضای ناگهانی میشود.
ACME پروتکلی برای خودکارسازی مدیریت Certificate است.
Client روی Server میتواند Domain Validation را انجام داده و Certificate جدید دریافت کند.
Certbot یکی از Clientهای شناختهشده ACME است.
Certbot برای دریافت و تمدید Certificateهای Let’s Encrypt روی بسیاری از Serverهای Linux استفاده میشود.
میتواند با Nginx و Apache ادغام شود.
پس از نصب باید Renewal Dry Run انجام شود تا از عملکرد خودکار اطمینان حاصل شود.
برای Wildcard یا زیرساختهای خاص میتوان DNS Validation را از طریق API Provider خودکار کرد.
Client به صورت موقت رکورد مورد نیاز را ایجاد و بعد از Validation حذف میکند.
API Token باید با حداقل دسترسی لازم نگهداری شود.
اگر Server پنل ندارد، تمام مراحل توسط مدیر سیستم انجام میشوند.
CSR، نصب Certificate، Chain، Redirect و Renewal باید به صورت دستی یا با Automation مدیریت شوند.
این روش کنترل بیشتری میدهد ولی مسئولیت بیشتری نیز دارد.
در هاست اشتراکی معمولاً مدیریت Certificate از طریق Control Panel انجام میشود.
در بسیاری از پلنها SSL رایگان نیز قابل فعالسازی است.
اگر Certificate تجاری دارید میتوانید در صورت پشتیبانی پنل آن را Import کنید.
ممکن است برخی سرویسهای هاست SSL رایگان داشته باشند و نیازی به خرید جداگانه نباشد.
اگر به OV، EV، Wildcard تجاری یا CA مشخصی نیاز دارید خرید مستقل مطرح میشود.
قبل از سفارش بهتر است امکانات هاست فعلی بررسی شوند.
میتوانید Certificate را مستقل از Hosting خریداری کنید.
برای صدور تنها باید کنترل Domain را داشته باشید.
بعد از صدور Certificate روی Server یا Hosting مورد نظر نصب میشود.
Registrar Domain و Hosting Provider نیز میتوانند شرکتهای متفاوتی باشند.
محل ثبت Domain محدودیتی برای خرید SSL ایجاد نمیکند.
تنها باید بتوانید Domain Validation را انجام دهید.
برای DNS Validation باید دسترسی به DNS و برای HTTP Validation دسترسی به Web Server داشته باشید.
نوع TLD معمولاً مانع استفاده از SSL نیست.
.com، .net، .org و بسیاری از پسوندهای دیگر میتوانند Certificate عمومی دریافت کنند.
نام Domain باید به صورت معتبر ثبت شده و کنترل آن قابل تأیید باشد.
دامنه .ir نیز میتواند از Certificateهای SSL عمومی استفاده کند، به شرط آنکه CA مورد نظر صدور برای این TLD و شرایط متقاضی را پشتیبانی کند.
قبل از خرید Certificate تجاری بهتر است سازگاری همان محصول بررسی شود.
Let’s Encrypt نیز بسته به سیاست فعلی سرویس باید جداگانه بررسی شود.
اگر از Let’s Encrypt استفاده میکنید میتوان برای Subdomainها نیز Certificate رایگان صادر کرد.
محدودیتها و Rate Limitهای CA باید رعایت شوند.
برای تعداد زیاد Subdomain ممکن است Wildcard مدیریت سادهتری داشته باشد.
در شبکه خصوصی معمولاً از PKI داخلی یا Self-Signed Certificateهای مدیریتشده استفاده میشود.
Certificate عمومی برای نامهای داخلی غیرقابل Resolve عمومی مناسب نیست.
سازمانهای بزرگ میتوانند Internal CA راهاندازی کنند.
Internal Certificate Authority برای صدور Certificate در شبکه سازمانی استفاده میشود.
دستگاههای شرکت باید Root CA داخلی را Trusted داشته باشند.
این ساختار برای سرویسهایی که عمومی نیستند کاربرد دارد.
امنیت Root Key داخلی بسیار مهم است.
در معماری Zero Trust ارتباطات داخلی نیز میتوانند با TLS یا mTLS محافظت شوند.
صرف قرار داشتن Server داخل Private Network به معنی اعتماد کامل نیست.
هویت سرویسها و Deviceها میتواند با Certificate بررسی شود.
در معماری Microservice تعداد ارتباطات میان سرویسها زیاد است.
میتوان از TLS یا mTLS برای ارتباط داخلی استفاده کرد.
مدیریت دستی صدها Certificate دشوار است و معمولاً Automation یا Service Mesh استفاده میشود.
Service Meshهایی مانند Istio میتوانند mTLS میان سرویسها را مدیریت کنند.
Certificateها به صورت خودکار Rotate میشوند.
این معماری برای پروژههای پیچیده مناسب است و برای سایت ساده ضرورت ندارد.
Certificate و Private Key نیز بخشی از Configuration زیرساخت هستند.
در صورت استفاده از Certificate تجاری و Key خاص بهتر است Backup امن از آن وجود داشته باشد.
Backup Private Key باید رمزنگاری و با دسترسی محدود نگهداری شود.
اگر میخواهید Certificate را روی Server جدید منتقل کنید، Private Key مربوطه نیز لازم است.
فقط داشتن فایل .crt کافی نیست.
در Windows ممکن است Export به فرمت PFX همراه با Private Key انجام شود.
فایل انتقالی باید با رمز قوی محافظت گردد.
PFX یا PKCS#12 میتواند Certificate، Private Key و Chain را داخل یک فایل نگهداری کند.
این فرمت در Windows و IIS بسیار رایج است.
فایل PFX معمولاً با Password محافظت میشود.
PEM یک فرمت متنی برای نگهداری Certificate و Key است.
Nginx و Apache معمولاً از فایلهای PEM استفاده میکنند.
محتوای فایل میان خطوطی مانند BEGIN CERTIFICATE قرار میگیرد.
پسوند .crt معمولاً برای فایل Certificate استفاده میشود.
فرمت داخلی آن میتواند PEM یا DER باشد.
تنها پسوند فایل برای تشخیص دقیق فرمت کافی نیست.
فایل .key معمولاً Private Key را نگهداری میکند.
این فایل یکی از حساسترین بخشهای SSL است.
Permission آن باید محدود باشد و نباید عمومی شود.
.cer نیز پسوند دیگری برای Certificate است.
ممکن است فایل به صورت Base64 یا Binary باشد.
Windows و ابزارهای مختلف میتوانند این فرمت را Import کنند.
ممکن است Certificate صحیح باشد اما سایت هنوز Mixed Content داشته باشد.
همچنین ممکن است Redirect کامل انجام نشده باشد و کاربر همچنان وارد نسخه HTTP شود.
Chain ناقص یا Domain mismatch نیز از دلایل دیگر هستند.
برای تشخیص باید پیام Browser و اطلاعات Certificate بررسی شوند.
ظاهر مرورگرهای جدید متفاوت شده و همیشه Icon قدیمی قفل را نمایش نمیدهند.
اگر Browser اتصال را Secure تشخیص دهد، Certificate معتبر است.
در صورت هشدار باید DevTools یا اطلاعات Security مرورگر بررسی شوند.
ممکن است Port 443 بسته باشد، Web Server Binding اشتباه باشد یا Certificate با Domain مطابقت نداشته باشد.
DNS نیز باید به همان Serverی اشاره کند که Certificate روی آن نصب شده است.
Error Log و تست اتصال میتوانند علت را مشخص کنند.
HTTPS به صورت پیشفرض از TCP Port 443 استفاده میکند.
Firewall باید این پورت را برای کاربران مجاز کند.
باز بودن Port به تنهایی کافی نیست و Web Server نیز باید روی آن Listen کند.
Port 80 معمولاً همچنان باز میماند تا درخواست HTTP را دریافت و به HTTPS Redirect کند.
بستن کامل آن ممکن است برخی فرآیندهای Validation یا ورود کاربران با URL قدیمی را مختل کند.
ساختار دقیق به معماری سایت بستگی دارد.
در معماری Proxy، Backend ممکن است Connection داخلی را HTTP ببیند.
Headerهایی مانند X-Forwarded-Proto برای اعلام Scheme اصلی استفاده میشوند.
Application باید Proxy مورد اعتماد را به درستی تشخیص دهد.
تنظیم اشتباه میتواند Redirect Loop ایجاد کند.
SSL Offloading یعنی عملیات TLS روی دستگاه یا سرویس جدا مانند Load Balancer انجام شود.
Backend منابع کمتری برای Handshake مصرف میکند و Certificateها متمرکز مدیریت میشوند.
روی Serverهای مدرن Performance تنها دلیل استفاده از این معماری نیست و مدیریت مرکزی اهمیت بیشتری دارد.
در SSL Pass-through، Load Balancer ترافیک رمزنگاریشده را بدون باز کردن TLS به Backend منتقل میکند.
Certificate روی Backend Server قرار دارد.
این روش با TLS Termination روی Load Balancer متفاوت است.
Certificate Pinning روشی است که Application یک Certificate یا Public Key مشخص را انتظار دارد.
این روش در برخی اپلیکیشنهای موبایل استفاده میشود.
مدیریت اشتباه Pin میتواند هنگام Renewal باعث قطع Application شود.
برای Web Browser عمومی معمولاً Pinning دستی کاربرد رایجی ندارد.
API مورد استفاده App باید HTTPS داشته باشد.
اگر Application Certificate Pinning دارد، فرآیند Renewal باید با دقت مدیریت شود.
استفاده از TLS قدیمی نیز ممکن است در نسخههای جدید iOS یا Android با محدودیت مواجه شود.
Webhookها معمولاً به Endpoint HTTPS ارسال میشوند.
سرویس فرستنده ممکن است Certificate نامعتبر یا Self-Signed را قبول نکند.
Domain و Chain باید معتبر باشند.
درگاههای پرداخت معمولاً Callback و Return URL را روی HTTPS ترجیح میدهند یا الزام میکنند.
Certificate منقضیشده میتواند باعث خطا در ارتباط شود.
بعد از تغییر SSL بهتر است یک تراکنش آزمایشی انجام شود.
Redirect URIهای OAuth معمولاً باید HTTPS باشند، به خصوص در محیط Production.
Domain دقیق و مسیر Callback باید در Provider ثبت شده باشند.
تغییر Domain یا Scheme بدون بهروزرسانی تنظیمات OAuth باعث خطا میشود.
Cookieهای Session بهتر است روی سایت HTTPS با Flag Secure تنظیم شوند.
در این حالت Browser آنها را روی HTTP ارسال نمیکند.
HttpOnly و SameSite نیز از تنظیمات مهم Cookie هستند.
HTTPS پایهای برای استفاده از برخی سیاستهای امنیتی Browser است.
HSTS، Content Security Policy و سایر Headerها میتوانند امنیت Application را افزایش دهند.
SSL به تنهایی جایگزین این تنظیمات نیست.
اگر یک سایت معمولی دارید و تنها HTTPS نیاز دارید، DV Single Domain معمولاً کافی است.
برای چند Subdomain میتوانید Wildcard را بررسی کنید.
برای چند Domain مختلف Multi-Domain مناسبتر است.
اگر شرکت به اعتبارسنجی سازمانی نیاز دارد، OV یا EV قابل بررسی خواهد بود.
ابتدا تعداد Domainها و Subdomainها را مشخص کنید.
سپس نوع Validation مورد نیاز را تعیین نمایید.
اگر Website معمولی است DV میتواند کافی باشد، اما شرکتهایی با Policy رسمی ممکن است OV یا EV بخواهند.
در نهایت قیمت Renewal و روش نصب و تمدید نیز باید بررسی شوند.
گواهیهای عمومی معمولاً برای دورههای محدود صادر میشوند و باید مرتب تمدید شوند.
مدل فروش Certificate تجاری ممکن است به صورت Subscription چندساله باشد، اما خود Certificate عملیاتی با دوره کوتاهتر Reissue شود.
شرایط دقیق به محصول CA بستگی دارد.
در برخی محصولات میتوانید برنامه چندساله خریداری کنید، اما استانداردهای فعلی Browserها اجازه اعتبار چندساله مستقیم برای یک Certificate واحد را نمیدهند.
در چنین طرحهایی Certificate باید طی دوره مجدداً صادر شود.
این موضوع باید هنگام خرید بررسی شود.
برخی Certificateهای تجاری Warranty ارائه میدهند.
این Warranty شرایط و محدودیتهای مشخصی دارد و بیمه عمومی سایت در برابر هک محسوب نمیشود.
مبلغ بالای Warranty نباید با سطح رمزنگاری اشتباه گرفته شود.
برخی برندهای SSL یک Site Seal برای نمایش روی سایت ارائه میکنند.
این نشان میتواند اطلاعاتی درباره Certificate یا Validation نمایش دهد.
وجود Seal برای امنیت TLS ضروری نیست.
Certificateهای تجاری توسط CAهای مختلف ارائه میشوند.
هر برند محصولات DV، OV، Wildcard یا Multi-Domain متفاوتی دارد.
قبل از انتخاب بهتر است سازگاری Browser، امکانات و شرایط Renewal مقایسه شوند.
بهتر است HTTPS از همان روز اول فعال باشد.
در این حالت نیازی به Migration بعدی URLها از HTTP به HTTPS نخواهد بود.
همچنین تمام لینکهای داخلی و Sitemap از ابتدا با نسخه امن ساخته میشوند.
سایت قدیمی نیز میتواند به HTTPS منتقل شود.
قبل از تغییر بهتر است Backup گرفته شود و URLهای داخلی بررسی شوند.
بعد از فعالسازی باید Redirect، Canonical، Sitemap و Mixed Content کنترل شوند.
تمام صفحات HTTP باید به نسخه معادل HTTPS Redirect شوند.
نباید همه URLها به صفحه اصلی هدایت شوند.
Canonical و لینکهای داخلی باید به URL امن اشاره کنند.
بعد از مهاجرت نیز Errorهای Crawl و Redirectها باید مانیتور شوند.
بعد از انتقال به HTTPS باید Property مناسب سایت در ابزارهای Search Engine بررسی شود.
Sitemap باید URLهای HTTPS داشته باشد.
اگر Domain Property استفاده میشود هر دو Protocol زیر همان Domain قابل مشاهده هستند، اما وضعیت Crawl همچنان باید کنترل شود.
در بیشتر سیستمهای Analytics نیازی به تغییر بنیادی وجود ندارد، اما URLهای اصلی و Referralها بهتر است بررسی شوند.
اگر بخشی از سایت همچنان روی HTTP باشد ممکن است دادهها پراکنده شوند.
پس از نصب SSL ممکن است Cache قدیمی HTTP باقی مانده باشد.
Cache CDN، Plugin و Browser باید در صورت نیاز پاک شوند.
همچنین Cache Key باید Host و Scheme را به درستی مدیریت کند.
اگر CDN Certificate جدید دریافت کرده باشد ممکن است مدتی برای Deployment روی Edgeها زمان نیاز داشته باشد.
Origin Certificate نیز باید مستقل بررسی شود.
پاک کردن Cache محتوا معمولاً برای تغییر Certificate ضروری نیست، مگر اینکه Configuration دیگری هم تغییر کرده باشد.
با خرید SSL از 1Platform میتوانید گواهی امنیتی مناسب وبسایت، فروشگاه، پنل کاربری یا زیرساخت سازمانی خود را انتخاب کنید و ارتباط کاربران با سرویس را از طریق HTTPS رمزنگاری نمایید.
بسته به ساختار پروژه میتوانید از گواهیهای Single Domain، Wildcard، Multi-Domain و سطوح مختلف اعتبارسنجی استفاده کنید.
پیش از سفارش، تعداد دامنهها و Subdomainها، نوع Validation، Web Server و روش تمدید را بررسی کنید تا گواهی انتخابشده با ساختار فعلی و نیازهای آینده سایت شما هماهنگ باشد.
پاسخ تمامی سوالات پرتکرار درباره خرید و نصب SSL را اینجا پیدا کنید
