مرورگر باز شده، آیکون قفل خط خورده و نوشته «Not Secure». یا بدتر: کاربر پیام «NET::ERR_CERT_DATE_INVALID» می‌بیند و صفحه را می‌بندد. اگر همین حالا روی صفحه‌ای هستید که باید بین یک گواهی رایگان DV و یک گواهی OV پول‌دار تصمیم بگیرید، این متن برای شماست. تصمیم درست به این بستگی دارد که سایت شما چه چیزی را به کاربر اثبات میکند، نه به قیمت گواهی.
سه سطح گواهی، سه سطح اثبات هویت
وقتی می‌گوییم «انواع گواهی SSL»، در واقع داریم درباره سطح اعتبارسنجی صحبت می‌کنیم، نه درباره الگوریتم رمزنگاری. هر سه سطح از رمزنگاری یکسانی استفاده می‌کنند؛ تفاوت در فرآیندی است که CA قبل از امضا طی میکند.
- DV (Domain Validation): فقط مالکیت دامنه بررسی می‌شود. معمولاً با یک رکورد DNS TXT یا فایل روی وب‌سرور. صدور در چند دقیقه.
- OV (Organization Validation): هویت حقوقی سازمان بررسی می‌شود؛ ثبت شرکت، آدرس، شماره تماس. چند روز کاری طول می‌کشد.
- EV (Extended Validation): بررسی عمیق‌تر حقوقی و عملیاتی. قبلاً نوار سبز آدرس مرورگر را فعال می‌کرد.
آن نوار سبز دیگر وجود ندارد
اگر کسی به شما گفت «EV بخرید تا نوار سبز بگیرید»، اطلاعاتش مال ۲۰۱۸ است. از Chrome 77 و Firefox 70 به بعد، مرورگرها نمایش نوار سبز را حذف کردند. الان فقط با کلیک روی قفل می‌توانید نام سازمان را ببینید. پس استدلال «اعتماد بصری بیشتر» برای EV دیگر معتبر نیست. آنچه باقی مانده، الزامات انطباق سازمانی است.
کدام سطح را برای کدام سایت انتخاب کنیم
پاسخ کوتاه: برای ۹۰٪ سایت‌ها DV کافی است. اگر سایت شما بلاگ، فروشگاه کوچک، یا SaaS است و کاربر با شما حساب بانکی باز نمی‌کند، DV بگیرید و پول اضافه را خرج پشتیبان‌گیری بکنید. OV را وقتی انتخاب کنید که مشتری سازمانی دارید و تیم حقوقی‌اش گواهی را در چک‌لیست تأمین‌کننده می‌خواهد. EV را فقط وقتی که قرارداد یا رگولاتور صریحاً الزام کرده باشد.
| معیار | DV | OV | EV |
|---|---|---|---|
| زمان صدور | دقیقه | ۱ تا ۳ روز کاری | ۳ تا ۷ روز کاری |
| بررسی هویت سازمان | خیر | بله | بله، عمیق‌تر |
| Wildcard | بله | بله | محدود |
| نوار سبز مرورگر | خیر | خیر | حذف شده |
| مناسب برای | اکثر سایت‌ها | B2B و سازمانی | الزام قراردادی |
هزینه‌ای که کسی درباره‌اش حرف نمی‌زند
OV و EV یک هزینه پنهان دارند: چرخه تمدید. هر بار باید مدارک سازمانی دوباره تأیید شود و اگر شماره تماس ثبت‌شده در WHOIS عوض شده باشد، فرآیند متوقف می‌شود. من دیده‌ام سایتی که با گواهی OV کار می‌کرد، روز تمدید به دلیل عدم پاسخگویی به ایمیل تأیید، ۴۸ ساعت با گواهی منقضی بالا ماند. برای DV این اتفاق نمی‌افتد چون تأیید خودکار است.
بررسی زنجیره گواهی روی سرور
نصب گواهی نصف کار است. نصف دیگر، درست بودن زنجیره میانی (Intermediate Chain) است. اگر زنجیره ناقص باشد، مرورگرهای دسکتاپ ممکن است بی‌خیال رد شوند ولی اپلیکیشن موبایل یا curl خطا بدهد. این را با یک دستور ساده چک کنید:
openssl s_client -connect example.com:443 -servername example.com -showcertsدر خروجی دنبال خط Verify return code: 0 (ok) بگردید. اگر عددی غیر از صفر دیدید، زنجیره مشکل دارد. برای بررسی تاریخ انقضا:
echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -datesخروجی چیزی شبیه notAfter=Mar 14 12:00:00 2026 GMT میدهد. این تاریخ را در سیستم مانیتورینگ ثبت کنید، نه در تقویم شخصی.
اینجا اشتباه می‌کنند
رایج‌ترین اشتباهی که می‌بینم: نصب گواهی روی دامنه اصلی و فراموش کردن www. کاربر www.example.com را باز میکند، گواهی برای example.com صادر شده، و مرورگر خطای NET::ERR_CERT_COMMON_NAME_INVALID میدهد. علامتش هم این است که سایت روی موبایل بعضی کاربران باز می‌شود و روی بعضی‌ها نه؛ چون بعضی‌ها با www تایپ می‌کنند و بعضی‌ها بدون آن. راه‌حل: یا گواهی Wildcard بگیرید، یا در SAN هر دو نام را اضافه کنید، یا یک ریدایرکت 301 از www به دامنه اصلی بگذارید.
خطاهای رایج و ریشه واقعی‌شان
وقتی گواهی مشکل دارد، پیام مرورگر معمولاً گمراه‌کننده است. این نقشه سریع را نگه دارید:
ERR_CERT_DATE_INVALID: ساعت سرور یا تاریخ گواهی. اولtimedatectl statusرا چک کنید.ERR_CERT_AUTHORITY_INVALID: زنجیره میانی ناقص است یا گواهی self-signed نصب شده.ERR_SSL_PROTOCOL_ERROR: معمولاً تداخل بین وب‌سرور و یک پروکسی جلویی که ترافیک را روی پورت 443 می‌گیرد.- قفل خاکستری بدون خطا: منابع Mixed Content؛ تصویر یا اسکریپتی که با
http://بارگذاری می‌شود.
برای مورد آخر، کنسول مرورگر را باز کنید و دنبال هشدارهای Mixed Content بگردید. اگر سایت وردپرسی دارید، این معمولاً از یک افزونه قدیمی می‌آید که آدرس تصاویر را hardcode کرده. راهنمای امنیت وردپرس؛ از wp-config تا افزونه‌هایی که خودشان حفره‌اند دقیقاً همین دسته مشکلات را پوشش میدهد.
اتوماسیون تمدید: کاری که باید از روز اول انجام دهید
گواهی‌های امروزی حداکثر ۳۹۸ روز اعتبار دارند و روند جهانی به سمت ۹۰ روز می‌رود. یعنی تمدید دستی دیگر گزینه نیست. اگر از Let's Encrypt استفاده می‌کنید، Certbot را با یک timer تنظیم کنید:
systemctl list-timers | grep certbot
certbot renew --dry-runدستور دوم بدون تغییر واقعی، کل فرآیند تمدید را شبیه‌سازی میکند. اگر خطا داد، همان‌جا متوقف شوید؛ چون در روز تمدید واقعی هم خطا میدهد. یک هشدار مانیتورینگ هم روی ۱۴ روز مانده به انقضا بگذارید.
وقتی از CDN یا پروکسی استفاده می‌کنید
اگر ترافیک شما از یک لایه میانی عبور میکند، دو گواهی دارید: یکی بین کاربر و لبه، یکی بین لبه و سرور مبدأ. خطای رایج این است که گواهی مبدأ منقضی می‌شود ولی کاربر چیزی نمی‌بیند، چون لبه همچنان گواهی معتبر خودش را نشان میدهد. تا روزی که لبه به مبدأ وصل می‌شود و خطای ۵۲۶ می‌گیرید. برای دیدن وضعیت لحظه‌ای سرویس‌ها و تشخیص اینکه مشکل از کجاست، وضعیت لحظه‌ای سرویس‌ها نقطه شروع خوبی است.
انتخاب CA: چیزی که واقعاً مهم است
برند CA تقریباً هیچ تفاوتی در امنیت ایجاد نمی‌کند. آنچه مهم است: پشتیبانی از ACME برای اتوماسیون، پشتیبانی از Wildcard، و سابقه پاسخگویی در پشتیبانی فنی. یک CA ارزان با اتوماسیون خوب، از یک CA گران با فرآیند دستی بهتر است. اگر تیم شما منابع محدودی دارد، این را جدی بگیرید.
نکته‌ای که کمتر گفته می‌شود: گواهی SSL فقط لایه انتقال را می‌پوشاند. اگر سرور شما در برابر حملات حجمی محافظت نشده باشد، HTTPS داشتن هیچ کمکی نمی‌کند. محافظت در برابر DDoS را جدا از بحث گواهی برنامه‌ریزی کنید. همچنین اگر تیم شما به سرورها دسترسی SSH دارد، امنیت SSH؛ از تغییر پورت تا fail2ban و کلید عمومی را موازی با کار گواهی پیش ببرید؛ این دو معمولاً با هم نادیده گرفته می‌شوند.
پرسش‌های پرتکرار
آیا گواهی DV برای فروشگاه اینترنتی امن است؟
بله، از نظر رمزنگاری هیچ تفاوتی با OV و EV ندارد. هر سه از TLS با همان قدرت استفاده می‌کنند و داده کاربر به یک شکل رمزنگاری می‌شود. تفاوت فقط در میزان بررسی هویت صادرکننده است. اگر درگاه پرداخت شما الزام قراردادی خاصی ندارد، DV کافی است.
چرا بعد از نصب گواهی، مرورگر همچنان ناامن نشان میدهد؟
در بیشتر موارد به دلیل Mixed Content است؛ یعنی صفحه اصلی با HTTPS بارگذاری می‌شود ولی بخشی از منابع (تصویر، اسکریپت، فونت) با http:// فراخوانی می‌شوند. کنسول مرورگر را باز کنید و هشدارهای Mixed Content را ببینید. اگر خطای گواهی است نه Mixed Content، زنجیره میانی را با openssl s_client بررسی کنید.
تفاوت گواهی Wildcard و Multi-Domain چیست؟
Wildcard یک دامنه و همه زیردامنههای یک سطح را پوشش میدهد، مثل *.example.com. Multi-Domain (یا SAN) چند دامنه کاملاً متفاوت را در یک گواهی جمع میکند، مثل example.com و example.ir و shop.example.net. اگر زیردامنههای زیادی دارید Wildcard بهتر است؛ اگر چند برند جدا دارید SAN مناسبتر است.
گواهی را چند وقت یک‌بار باید تمدید کنم؟
حداکثر اعتبار مجاز امروز ۳۹۸ روز است، ولی روند صنعت به سمت ۹۰ روز می‌رود. عملاً باید تمدید را کاملاً خودکار کنید و فقط مانیتورینگ انقضا داشته باشید. اگر تیم شما چندین سرویس دارد، مستندات و پایگاه دانش را برای ثبت رویه‌های تمدید و مالکیت هر گواهی به‌روز نگه دارید تا روزی که مسئولش عوض می‌شود، کسی نداند کدام گواهی مال کدام سرویس است.
اگر همین حالا یک گواهی روی سرور دارید، قبل از هر کار دیگری این دستور را اجرا کنید: echo | openssl s_client -connect yourdomain.com:443 2>/dev/null | openssl x509 -noout -dates -subject. اگر تاریخ انقضا کمتر از ۳۰ روز است یا subject با دامنه‌ای که کاربر تایپ میکند نمی‌خواند، اول آن را درست کنید. بقیه بحث‌ها بعد از این مرحله معنا پیدا می‌کنند. برای راه‌اندازی و مدیریت گواهی روی زیرساخت، خدمات امنیت سرورنت گزینه‌ای است که می‌توانید بررسی کنید.
دیدگاه‌ها ۰
هنوز دیدگاهی ثبت نشده؛ اولین نفر باشید!