تفاوت SSL رایگان و پولی دقیقاً در کدام لایه امنیتی است؟

یکی از عادت‌های بدی که سال‌ها پیش در یک پروژه داشتم این بود که SSL (Secure Sockets Layer) پولی را به‌عنوان پیش‌فرض قطعی در نظر می‌گرفتم، بدون این‌که دقیقاً بدانم چه چیزی از آن پول می‌خرم. وقتی مشتری از من پرسید تفاوت واقعی گواهی ۲۰ دلاری با گواهی رایگان Let's Encrypt در چیست و آیا امنیت لایه TLS (Transport Layer Security) واقعاً فرق می‌کند، مکث کردم. چند ماه بعد، وقتی مشغول مهاجرت یک سایت فروشگاهی به معماری خودکار ACME (Automatic Certificate Management Environment) بودم، فهمیدم آن مکث، اولین قدم به سمت درک درست این حوزه بود. این مقاله از دید کسی نوشته شده که روی ده‌ها دامنه با هر دو نوع گواهی کار کرده و یاد گرفته تفاوت واقعی، در الگوریتم رمزنگاری نیست؛ در مدل اعتماد، دامنه پشتیبانی و مکانیزم مدیریت است.

SSL رایگان و پولی، ابتدا یک تفکیک پایه

پیش از هر مقایسه‌ای، باید یک سوءتفاهم رایج را کنار بگذاریم: تفاوت SSL رایگان و پولی، تفاوت در الگوریتم رمزنگاری نیست. هر دو، از همان استاندارد TLS (Transport Layer Security) استفاده می‌کنند و از نظر ریاضی، داده‌ای که با گواهی رایگان رمزنگاری می‌شود، به‌همان اندازه داده‌ای که با گواهی گران‌قیمت رمزنگاری شده، امن است. این نکته را در پروژه‌های زیادی برای مدیران توضیح داده‌ام و همیشه شگفت‌زده می‌شوند.

پس تفاوت واقعی در چیست؟ تفاوت در سه لایه است:

1. لایه اعتبارسنجی (Validation Level): چه مقدار بررسی درباره هویت مالک دامنه انجام می‌شود؟ از Domain Validation تا Extended Validation.
2. لایه مدیریت (Management): گواهی چطور صادر، تمدید و ابطال می‌شود؟ دستی، نیمه‌خودکار یا کاملاً خودکار با پروتکل ACME.
3. لایه پشتیبانی (Support): در صورت بروز مشکل، چه پشتیبانی و چه SLA (Service Level Agreement) در دسترس است؟

این سه لایه، تفاوت‌های واقعی را می‌سازند. اگر با مفاهیم پایه SSL آشنا نیستید، مرور کلی در SSL چیست و چرا سایت به آن نیاز دارد نقطه شروع خوبی است. تفاوت HTTPS با HTTP هم در HTTPS چیست و چه تفاوتی با HTTP دارد آمده است.

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

سه سطح اعتبارسنجی: DV، OV و EV

مهم‌ترین تفاوت فنی بین SSL رایگان و پولی، در سطح اعتبارسنجی است. سه سطح اصلی وجود دارد:

DV (Domain Validation)

در این سطح، فقط تأیید می‌شود که درخواست‌کننده گواهی، کنترل روی دامنه را دارد. روش‌های تأیید: قرار دادن یک فایل مشخص در مسیر تعریف‌شده دامنه، اضافه کردن یک رکورد DNS، یا پاسخ به ایمیل مدیریت دامنه. این سطح از اعتبارسنجی، سریع‌ترین و ارزان‌ترین است و تمام گواهی‌های رایگان — از جمله Let's Encrypt — در این سطح قرار می‌گیرند.

OV (Organization Validation)

در این سطح، علاوه بر تأیید کنترل دامنه، هویت سازمان (نام قانونی، آدرس، شماره ثبت) توسط CA (Certificate Authority یا مرجع صدور گواهی) بررسی می‌شود. این بررسی، شامل استعلام از پایگاه‌های داده رسمی و گاه تماس تلفنی با سازمان است. تمام گواهی‌های OV، پولی هستند.

EV (Extended Validation)

در این سطح، بررسی‌های OV به‌علاوه بررسی‌های اضافی درباره موجودیت حقوقی سازمان انجام می‌شود. این سطح، بالاترین سطح اعتبارسنجی است. نکته‌ای که در سال‌های اخیر تغییر کرده: نمایش نام سازمان در نوار آدرس مرورگر که قبلاً مزیت اصلی EV بود، از نسخه‌های جدید مرورگرها حذف شده است. اما گواهی EV همچنان در برخی اسناد حقوقی و سازمانی به‌عنوان سیگنال اعتماد اولیه استفاده می‌شود.

تفاوت عملی در لایه اعتبارسنجی:

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

پروتکل ACME و انقلاب Let's Encrypt

در سال دو هزار و پانزده، بنیاد Let's Encrypt با پشتیبانی EFF و چند شرکت بزرگ، پروتکل ACME (Automatic Certificate Management Environment) را معرفی کرد. این پروتکل، فرآیند صدور، تمدید و ابطال گواهی را کاملاً خودکار می‌کند و به همین دلیل، صدور گواهی رایگان را در مقیاس میلیون‌ها دامنه ممکن ساخت.

مکانیزم ACME در سطح فنی:

1. یک کلاینت ACME روی سرور شما نصب می‌شود (مثل Certbot).
2. کلاینت یک کلید خصوصی ایجاد می‌کند و یک درخواست CSR (Certificate Signing Request) می‌سازد.
3. کلاینت به CA اعلام می‌کند که می‌خواهد گواهی برای دامنه مشخص صادر شود.
4. CA یک چالش (Challenge) تعریف می‌کند: قرار دادن یک فایل با محتوای مشخص در مسیر تعریف‌شده دامنه، یا اضافه کردن یک رکورد DNS خاص.
5. کلاینت چالش را انجام می‌دهد.
6. CA چالش را تأیید می‌کند و گواهی را صادر می‌کند.
7. کلاینت گواهی را روی سرور نصب می‌کند.
8. پس از حدود شصت روز، این چرخه به‌طور خودکار تکرار می‌شود.

اهمیت این پروتکل در سه نکته است: اول، صفر هزینه مالی. دوم، صفر نیروی انسانی در چرخه تمدید. سوم، سرعت صدور در حد دقیقه. همین سه ویژگی، باعث شد که Let's Encrypt در کمتر از یک دهه، سهم بزرگی از بازار را بگیرد.

نکته‌ای که در پروژه‌ها زیاد به آن برخورده‌ام: بسیاری از تیم‌ها ACME را فقط به‌عنوان راهی برای صرفه‌جویی در هزینه می‌بینند، درحالی‌که ارزش اصلی آن، از بین بردن خطای انسانی در تمدید گواهی است. گواهی منقضی‌شده، یکی از پرهزینه‌ترین حادثه‌های عملیاتی است که با خودکارسازی به‌طور کامل حذف می‌شود. این فرآیند را در چگونه SSL سایت را نصب و فعال کنیم گام‌به‌گام توضیح داده‌ام.

لایه رمزنگاری: آیا تفاوت فنی وجود دارد؟

یکی از پرسش‌هایی که در جلسات زیاد می‌شنوم: آیا SSL رایگان، امنیت رمزنگاری کمتری از SSL پولی دارد؟ پاسخ صریح: نه. هر دو گواهی، از همان الگوریتم‌های استاندارد استفاده می‌کنند:

• الگوریتم‌های کلید عمومی: RSA با طول دو هزار و چهارده یا چهار هزار و نود و شش بیت، یا ECDSA با کلیدهای کوتاه‌تر. این الگوریتم‌ها در هر دو نوع گواهی یکسانند.
• الگوریتم‌های متقارن: AES-GCM یا ChaCha20-Poly1305. این الگوریتم‌ها توسط پروتکل TLS تعیین می‌شوند، نه توسط گواهی.
• توابع هش: SHA-256 یا SHA-384. این‌ها هم توسط پروتکل تعیین می‌شوند.

یعنی، از نظر ریاضی، گواهی Let's Encrypt با کلید RSA چهار هزار و نود و شش بیتی، همان سطح امنیت را دارد که یک گواهی OV گران‌قیمت با همان طول کلید. تفاوت در طول کلید نیست، در سطح اعتبارسنجی است.

البته یک نکته ظریف وجود دارد: در سمت پیکربندی، اگر سرور شما تنظیمات قدیمی داشته باشد (مثل پشتیبانی از TLS 1.0 یا الگوریتم‌های ضعیف)، این ضعف در هر دو نوع گواهی دیده می‌شود. یعنی امنیت واقعی، تابع پیکربندی سرور است، نه نوع گواهی. راهنمای بررسی پیکربندی و اعتبار گواهی در بررسی اعتبار SSL سایت و SSL و HTTPS چه نقشی در امنیت دارند آمده است.

زنجیره اعتماد و ریشه‌های Root Store

هر گواهی SSL، بخشی از یک زنجیره اعتماد است. مرورگرها و سیستم‌عامل‌ها، فهرستی از ریشه‌های معتمد (Trusted Root Certificates) دارند. اگر CA صادرکننده گواهی شما، در این فهرست باشد، گواهی شما معتبر شناخته می‌شود؛ در غیر این صورت، مرورگر هشدار می‌دهد.

Let's Encrypt در تمام مرورگرهای مدرن و اکثر سیستم‌عامل‌ها، ریشه معتمد دارد. یعنی گواهی‌های آن، به‌طور پیش‌فرض معتبر شناخته می‌شوند. این یکی از تفاوت‌های مهم با CAهای ناشناس یا Self-Signed است که در مرورگرها هشدار ایجاد می‌کنند.

نکته‌ای که در پروژه‌های سازمانی مهم است: برخی سازمان‌ها، سیاست‌هایی دارند که فقط CAهای خاص را می‌پذیرند. مثلاً در محیط‌های بانکی یا دولتی، ممکن است فهرست CAهای معتمد به‌طور سفارشی محدود شده باشد. در چنین سناریوهایی، انتخاب CA پولی معتبر، تنها گزینه است. راهنمای کامل این موضوع در امنیت وب چیست و چه اصولی دارد آمده است.

Wildcard و Multi-Domain: پیچیدگی‌های پنهان

در بخش پشتیبانی از دامنه‌های پیچیده، تفاوت‌های عملی بین SSL رایگان و پولی برجسته می‌شود:

• Single Domain: هر دو نوع گواهی، از یک دامنه پشتیبانی می‌کنند. تفاوتی وجود ندارد.
• Wildcard: پشتیبانی از یک دامنه و همه زیردامنه‌های آن (مثل *.example.com). Let's Encrypt این نوع را پشتیبانی می‌کند، اما با محدودیت‌هایی در تعداد صدور و سطح اعتبارسنجی. گواهی‌های پولی Wildcard، انعطاف بیشتری دارند. مرور کامل در SSL Wildcard چیست و چه کاربردی دارد.
• Multi-Domain (SAN): پشتیبانی از چندین دامنه مستقل در یک گواهی. Let's Encrypt تا حدود صد دامنه در یک گواهی پشتیبانی می‌کند. گواهی‌های پولی Multi-Domain، گاه تا چند صد دامنه را پشتیبانی می‌کنند.
• Multi-Domain Wildcard: ترکیب چند دامنه Wildcard در یک گواهی. Let's Encrypt از این حالت پشتیبانی نمی‌کند. این یکی از موارد معدودی است که SSL رایگان کافی نیست و باید به سمت گواهی پولی رفت.

در پروژه‌های چند-دامنه‌ای، این تفاوت‌ها به‌سرعت به تصمیم عملی تبدیل می‌شوند. اگر شما یک سازمان با ده زیردامنه مستقل هستید، Wildcard پولی می‌تواند مدیریت را ساده‌تر کند. اما اگر ده دامنه اصلی کاملاً مستقل دارید، ترکیب چند گواهی Let's Encrypt معمولاً کافی است.

Revocation: OCSP، CRL و چالش‌های مدرن

مکانیزم ابطال گواهی (Revocation) یکی از لایه‌های مهم امنیتی است که در انتخاب بین SSL رایگان و پولی اثر دارد. وقتی یک گواهی ابطال می‌شود (مثلاً به‌خاطر افشای کلید خصوصی)، مرورگر باید بتواند این ابطال را تشخیص دهد.

دو مکانیزم اصلی:

• CRL (Certificate Revocation List): فهرست بلندی از گواهی‌های ابطال‌شده که CA منتشر می‌کند. این فهرست، به‌سرعت بزرگ می‌شود و بار شبکه‌ای بالایی دارد.
• OCSP (Online Certificate Status Protocol): پرسش مستقیم از سرور CA در لحظه اتصال. سریع‌تر از CRL، اما چالش‌های حریم خصوصی دارد.
• OCSP Stapling: راه‌حل بهبودیافته که در آن، سرور شما پاسخ OCSP را از قبل می‌گیرد و به مرورگر تحویل می‌دهد. این روش، سرعت و حریم خصوصی را بهبود می‌دهد.

تفاوت بین CAها در این لایه:

• Let's Encrypt، از ابتدا بر CRL تاکید داشت و در سال‌های اخیر، سرویس OCSP خود را به‌کلی متوقف کرده. یعنی گواهی‌های Let's Encrypt بر پایه CRL ابطال می‌شوند که به‌نوبه خود، به‌خاطر محدودیت‌های مرورگرها، در عمل اثر ابطال کاهش می‌یابد.
• CAهای پولی، معمولاً سرویس OCSP و OCSP Stapling را به‌طور کامل پشتیبانی می‌کنند و ابطال گواهی در آن‌ها سریع‌تر و مؤثرتر اعمال می‌شود.

این تفاوت، در سناریوهای بحرانی مثل افشای کلید خصوصی، تفاوت عملی دارد. اما در عمل، برای اکثر سایت‌ها، این تفاوت در سطح اثر روزمره محدود است. موضوع کامل‌تر در هدرهای امنیتی HTTP و تأثیر HTTPS بر سئو باز شده است.

Certificate Transparency و شفافیت عمومی

Certificate Transparency (CT) یک مکانیزم جدید است که در آن، هر گواهی صادرشده، در یک Log عمومی قابل‌بازرسی ثبت می‌شود. این مکانیزم، امکان کشف گواهی‌های جعلی یا صدور اشتباه را فراهم می‌کند.

هر دو نوع گواهی — رایگان و پولی — در حال حاضر از CT پشتیبانی می‌کنند. اما پیامد آن برای کسب‌وکارها متفاوت است: تمام دامنه‌هایی که برایشان گواهی صادر شده، در Log عمومی CT قابل‌مشاهده‌اند. این ویژگی، هم برای امنیت مفید است (امکان کشف سریع سوءاستفاده)، هم چالشی برای حریم خصوصی (امکان کشف زیردامنه‌های داخلی).

در پروژه‌های سازمانی، این موضوع به یک تصمیم معماری تبدیل شده: آیا استفاده از Wildcard یا محدودسازی صادر گواهی برای زیردامنه‌های داخلی، می‌تواند از افشای اطلاعات جلوگیری کند؟ پاسخ، بستگی به مدل تهدید سازمان دارد.

ضمانت‌نامه (Warranty) و ارزش واقعی آن

یکی از تفاوت‌های تبلیغاتی گواهی‌های پولی، ضمانت‌نامه مالی است. مثلاً گواهی EV ممکن است ضمانت‌نامه‌ای بین یک تا دو میلیون دلار داشته باشد. این ضمانت‌نامه در چه شرایطی اعمال می‌شود؟

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

ارزش واقعی ضمانت‌نامه، بیشتر در لایه قراردادهای B2B و انطباق سازمانی است تا در عمل روزمره. یعنی، ضمانت‌نامه بیشتر به‌عنوان یک سیگنال تعهد قراردادی عمل می‌کند تا به‌عنوان یک جبران مالی واقعی. در تصمیم‌گیری، باید این تفکیک در نظر گرفته شود.

دامنه پشتیبانی و SLA

یکی از تفاوت‌های محسوس بین SSL رایگان و پولی، در لایه پشتیبانی است:

• Let's Encrypt: پشتیبانی از طریق انجمن عمومی و مستندات. اگر مشکلی پیش بیاید، باید از منابع عمومی کمک بگیرید.
• CAهای پولی: پشتیبانی از طریق تیکت، ایمیل و گاه تماس تلفنی. SLA مشخص برای زمان پاسخ. در سناریوهای بحرانی، این پشتیبانی می‌تواند تفاوت بین یک ساعت و یک روز در حل مسئله باشد.

در تجربه من، ارزش پشتیبانی، در سه سناریو برجسته می‌شود:

1. نصب و پیکربندی اولیه: در پروژه‌های با معماری پیچیده (مثل چند زیردامنه Wildcard)، پشتیبانی CA می‌تواند در حل مشکل زمان‌بر کمک کند.
2. مشکلات ابطال: در سناریوی ابطال اضطراری، پشتیبانی سریع CA پولی ارزش دارد.
3. انطباق سازمانی: در سازمان‌هایی که نیاز به مستندات رسمی دارند، پشتیبانی CA پولی این امکان را فراهم می‌کند.

خودکارسازی در برابر مدیریت دستی

یکی از تفاوت‌های عملی که در طولانی‌مدت برجسته می‌شود، سطح خودکارسازی است. Let's Encrypt از ابتدا برای خودکارسازی طراحی شده. گواهی‌های پولی، بسته به CA، ممکن است فرآیند نیمه‌خودکار یا حتی دستی داشته باشند.

در سناریوهای چند-دامنه یا چند سرور، این تفاوت به‌سرعت به یک معضل عملیاتی تبدیل می‌شود:

• اگر بیست دامنه دارید و هر گواهی باید هر سال دستی تمدید شود، این بیست نوبت فرصت برای خطای انسانی است.
• اگر همان بیست دامنه، با ACME خودکار تمدید شوند، احتمال خطای انسانی به صفر می‌رسد.

در پروژه‌های بزرگ، ترکیب این دو رویکرد منطقی است: دامنه‌های عمومی با ACME خودکار، دامنه‌های حساس یا سازمانی با گواهی پولی و مدیریت‌شده. این معماری، در ریدایرکت HTTP به HTTPS و اشتباهات رایج در نصب SSL به‌طور مفصل بحث شده است.

سناریوهای واقعی: وردپرس، فروشگاه و سازمان

برای تصمیم عملی، سناریوهای معمول را جدا می‌کنیم:

وردپرس شخصی و وبلاگ

گواهی Let's Encrypt انتخاب بهینه است. هیچ دلیلی برای پرداخت هزینه وجود ندارد. بیشتر هاست‌های مدرن، گواهی رایگان را به‌طور خودکار روی همه دامنه‌ها اعمال می‌کنند و حتی نیازی به پیکربندی دستی نیست.

فروشگاه اینترنتی کوچک و متوسط

گواهی Let's Encrypt کافی است. تفاوت امنیتی با گواهی پولی صفر است و اعتماد کاربر نیز تحت تأثیر نیست (چون کاربر معمولی، تفاوت DV و OV را نمی‌بیند). اگر روی درگاه پرداخت ایرانی کار می‌کنید و درگاه، محدودیت خاصی ندارد، رایگان انتخاب بهینه است. نکات بیشتر در اهمیت SSL برای فروشگاه اینترنتی آمده است.

سازمان با نیاز انطباق

در سازمان‌های مالی، درمانی و دولتی که اسناد رسمی و انطباق نیاز دارند، گواهی OV یا EV معمولاً الزامی است. علت، نه تفاوت امنیتی، بلکه نیاز به مستندات رسمی و ضمانت‌نامه قراردادی است. در این سناریو، Let's Encrypt کافی نیست.

سازمان با زیرساخت چند-دامنه پیچیده

در سناریوهای با چندین زیردامنه Wildcard در چند سطح، گواهی Multi-Domain Wildcard پولی می‌تواند مدیریت را ساده‌تر کند. اما اگر معماری با ACME خودکار قابل پیکربندی است، ترکیب چند گواهی رایگان هم جواب می‌دهد.

اپلیکیشن‌های SaaS

در SaaSها که هر مشتری روی یک زیردامنه اختصاصی میزبانی می‌شود (مثل customer.example.com)، ترکیب ACME خودکار برای صدور در لحظه، معماری متعارف است. چند سال پیش، این کار فقط با SSL Wildcard گران‌قیمت ممکن بود؛ امروز با ACME و DNS-01 Challenge، رایگان ممکن است.

جدول تصمیم عملی

اشتباهات رایج در انتخاب SSL

این اشتباهات را در پروژه‌ها زیاد دیده‌ام:

• باور به امنیت بیشتر در گواهی پولی: تفاوت رمزنگاری وجود ندارد؛ تفاوت در لایه اعتبارسنجی، پشتیبانی و مدیریت است.
• خرید Wildcard گران‌قیمت بدون نیاز: در سناریوهای ساده، ترکیب چند گواهی DV رایگان ارزان‌تر و ساده‌تر است.
• انتخاب DV رایگان برای سازمان با نیاز انطباق: در صنایع حساس، فقدان اعتبارسنجی سازمانی می‌تواند در ممیزی مشکلی جدی ایجاد کند.
• فراموش کردن تمدید گواهی دستی: گواهی منقضی‌شده، حتی اگر DV رایگان بوده، منجر به هشدار مرورگر و از دست رفتن اعتماد کاربر می‌شود. راه‌حل: ACME خودکار یا Calendared Reminder.
• پیکربندی نادرست زنجیره گواهی: در نصب گواهی پولی، اگر Intermediate Certificate در سرور نصب نشود، مرورگرهای برخی سیستم‌ها هشدار می‌دهند. مسیر صحیح در اشتباهات رایج نصب SSL آمده است.
• نادیده گرفتن OCSP Stapling: این قابلیت، سرعت اتصال را بهبود می‌دهد و در گواهی‌های پولی معمولاً پشتیبانی می‌شود. فعال‌سازی آن، توصیه عملی است.

در انتخاب SSL، پرسش درست این نیست که کدام ارزان‌تر است. پرسش درست این است که در معماری شما، چه سطحی از اعتبارسنجی و چه سطحی از مدیریت لازم است.

پرسش‌های پرتکرار درباره SSL رایگان و پولی

پرسش‌هایی که در جلسات مشاوره زیاد می‌شنوم:

آیا SSL رایگان از نظر امنیتی ضعیف‌تر است؟

نه. از نظر الگوریتم رمزنگاری، گواهی رایگان Let's Encrypt با گواهی پولی با همان طول کلید، یکسان است. تفاوت در لایه اعتبارسنجی (DV در برابر OV/EV)، پشتیبانی و مدیریت است.

آیا گوگل به SSL پولی رتبه بهتری می‌دهد؟

نه. سیگنال HTTPS در سئو، فقط به وجود HTTPS توجه دارد، نه به نوع گواهی. تفاوت HTTPS با HTTP در HTTPS چیست و چه تفاوتی با HTTP دارد و اثر سئویی آن در تأثیر HTTPS بر سئو آمده است.

چه زمانی باید SSL پولی بخرم؟

سه سناریو: نیاز به اعتبارسنجی سازمانی (OV یا EV) برای انطباق، نیاز به Wildcard یا Multi-Domain پیچیده که ACME پشتیبانی نمی‌کند، و نیاز به SLA و پشتیبانی سریع در محیط‌های بحرانی.

آیا Let's Encrypt برای فروشگاه اینترنتی مناسب است؟

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

آیا گواهی رایگان در همه مرورگرها معتبر است؟

Let's Encrypt در تمام مرورگرهای مدرن و اکثر سیستم‌عامل‌ها معتبر است. تنها استثناها، سیستم‌های قدیمی (مثل اندروید ۷.۱ به قبل) و برخی تنظیمات سازمانی با فهرست محدود CA هستند.

چند وقت یک بار باید SSL تمدید شود؟

Let's Encrypt گواهی‌های نود روزه صادر می‌کند که با ACME به‌طور خودکار تمدید می‌شوند. CAهای پولی معمولاً گواهی‌های یک‌ساله صادر می‌کنند. در سال‌های اخیر، روند صنعت به سمت گواهی‌های کوتاه‌مدت‌تر حرکت کرده است.

آیا تفاوت OCSP Stapling در انتخاب SSL مهم است؟

در سرعت اتصال و برخی جنبه‌های حریم خصوصی، بله. Let's Encrypt سرویس OCSP خود را متوقف کرده و بر CRL تاکید دارد. گواهی‌های پولی معمولاً OCSP و OCSP Stapling را کامل پشتیبانی می‌کنند.

آیا می‌توان از SSL رایگان برای سازمان دولتی استفاده کرد؟

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

آیا SSL پولی امنیت بیشتری در برابر MITM دارد؟

نه. مقاومت در برابر MITM (Man-in-the-Middle) به پیکربندی TLS و پروتکل‌های پشتیبانی‌شده بستگی دارد، نه به سطح اعتبارسنجی گواهی. اگر سرور شما TLS 1.3 و HSTS را پشتیبانی کند، مقاومت در هر دو نوع گواهی یکسان است.

آیا Self-Signed Certificate جایگزین مناسبی است؟

فقط در محیط‌های داخلی و بسته (مثل APIهای داخلی بین سرویس‌ها). در محیط‌های عمومی، Self-Signed منجر به هشدار مرورگر می‌شود و اعتماد کاربر را از بین می‌برد.

تفاوت گواهی DV رایگان و DV پولی چیست؟

از نظر فنی، تفاوت چندانی ندارند. تفاوت در لایه پشتیبانی، مدت اعتبار و گاه سرعت صدور است. اگر هزینه مالی مهم نیست و پشتیبانی سریع اولویت است، DV پولی می‌تواند انتخاب شود. اما در اکثر سناریوها، DV رایگان Let's Encrypt کافی است.

انتخاب نهایی در یک جمله

تفاوت SSL رایگان و پولی، تفاوت در امنیت رمزنگاری نیست؛ تفاوت در سطح اعتبارسنجی، سطح مدیریت و سطح پشتیبانی است. Let's Encrypt با پروتکل ACME، در لایه مدیریت انقلابی ایجاد کرده و برای اکثر پروژه‌ها کافی است. اما در سناریوهای سازمانی با نیاز انطباق، در معماری‌های پیچیده چند-دامنه، و در محیط‌های بحرانی که پشتیبانی سریع حیاتی است، گواهی پولی جایگاه مشخص خودش را دارد.

سه اولویت عملی برای تصمیم: اول، سطح اعتبارسنجی موردنیاز را بر اساس نیاز انطباق تعیین کنید. دوم، سطح مدیریت را بر اساس تعداد دامنه و توان خودکارسازی انتخاب کنید. سوم، سطح پشتیبانی را بر اساس حساسیت عملیاتی پروژه بسنجید. اگر این سه تعیین شد، انتخاب بین SSL رایگان و پولی، تقریباً اجباری می‌شود.

اگر در پروژه‌ای تجربه انتخاب بین این دو نوع گواهی را داشته‌اید، برایم جالب است بدانید کدام فاکتور در تصمیم شما قاطع‌ترین بود — نیاز انطباق، پیچیدگی دامنه، سطح پشتیبانی یا صرفاً هزینه. تجربه‌تان را در دیدگاه‌ها بنویسید؛ به‌خصوص اگر سناریویی داشتید که در جدول این مقاله نگنجید و نیازمند تفکر متفاوتی بود. 🔐