گواهی SSL چیست؟ انتخاب TLS، نصب و تمدید بدون قطعی

گواهی TLS زمانی خوب انتخاب شده که کاربر هیچ‌وقت درباره آن فکر نکند: اتصال امن باشد، نام دامنه درست تطبیق بخورد، زنجیره کامل ارسال شود و تمدید پیش از انقضا خودکار انجام شود. گواهی گران اما بدون Renewal monitoring می‌تواند سایت را از دسترس خارج کند؛ گواهی رایگان و خودکار نیز اگر Private key لو برود یا Origin بدون اعتبارسنجی بماند، امنیت کامل نمی‌سازد.

در گفت‌وگوی روزمره هنوز می‌گوییم «گواهی SSL»، اما SSL پروتکل قدیمی است و وب امروز از TLS استفاده می‌کند. این راهنما به شما کمک می‌کند DV، OV، EV، Single-domain، Wildcard و SAN را بدون ادعای بازاری انتخاب کنید؛ سپس نصب، CDN/Origin، مهاجرت HTTPS، تمدید و رفع خطا را عملیاتی کنید.

گواهی SSL/TLS چیست؟

گواهی TLS یک سند دیجیتال امضاشده توسط مرجع صدور یا CA است که Public key را به یک یا چند نام دامنه پیوند می‌دهد. مرورگر هنگام Handshake بررسی می‌کند گواهی منقضی نشده، نام میزبان در SAN آن وجود دارد، زنجیره به Root مورداعتماد می‌رسد و امضای دیجیتال معتبر است. سپس Client و Server کلیدهای Session را برای رمزنگاری ارتباط می‌سازند.

TLS سه هدف مهم دارد:

• محرمانگی: محتوای ارتباط در مسیر برای شنودگر خوانا نباشد.
• یکپارچگی: تغییر داده در مسیر قابل تشخیص باشد.
• احراز Endpoint: Client بداند به دامنه‌ای متصل است که گواهی معتبر آن را کنترل می‌کند.

گواهی به‌تنهایی نمی‌گوید محتوای سایت درست، کسب‌وکار خوش‌حساب یا برنامه بدون آسیب‌پذیری است. HTTPS می‌تواند روی سایت فیشینگ هم فعال باشد. برای امنیت عملی، TLS باید کنار Update، MFA، WAF، Backup، Logging و کد امن قرار گیرد.

خلاصه انتخاب گواهی SSL

DV، OV و EV چه تفاوتی دارند؟

این سه برچسب «قدرت رمزنگاری» را رتبه‌بندی نمی‌کنند؛ سطح بررسی متقاضی توسط CA را نشان می‌دهند. Protocol و Cipher مناسب می‌تواند برای هر سه یکسان باشد.

DV یا Domain Validation

CA کنترل دامنه را از طریق Challenge تأیید می‌کند. DV سریع و قابل Automation است و انتخاب پیش‌فرض بسیاری از وب‌سایت‌ها، APIها و فروشگاه‌هاست. Let’s Encrypt گواهی DV استاندارد ارائه می‌کند و در FAQ رسمی خود می‌گوید Private key را تولید یا نگهداری نمی‌کند؛ کلید در زیرساخت Subscriber ساخته و اداره می‌شود.

DV به معنای رمزنگاری ضعیف نیست. فقط هویت حقوقی سازمان را داخل فرایند صدور بررسی نمی‌کند. فروشگاه می‌تواند با DV، TLS امن و قابل‌اعتماد داشته باشد؛ امنیت پرداخت بیشتر به معماری درگاه، Verify سمت سرور، Tokenization و Scope PCI وابسته است.

OV یا Organization Validation

CA علاوه بر کنترل دامنه، اطلاعات سازمان را طبق سیاست خود بررسی می‌کند. OV ممکن است برای Procurement سازمانی، قرارداد B2B، سیاست داخلی یا الزام Regulatory مفید باشد. پیش از خرید بپرسید:

• کدام هویت و Jurisdiction بررسی می‌شود؟
• چه مدارکی برای شرکت ایرانی قابل پذیرش است؟
• زمان صدور و Revalidation چقدر است؟
• Automation، API و پشتیبانی Renewal چگونه است؟
• نام سازمان در کدام Client واقعاً قابل مشاهده است؟

EV یا Extended Validation

EV فرایند هویت‌سنجی گسترده‌تری دارد، اما مرورگرهای مدرن دیگر آن را با «نوار سبز» برجسته نمی‌کنند. EV مانع فیشینگ مشابه‌دامنه، بدافزار یا آسیب‌پذیری برنامه نمی‌شود و رمزنگاری قوی‌تری از DV تضمین نمی‌کند. فقط وقتی انتخابش کنید که ذی‌نفع، قرارداد یا مدل ریسک به همان Verification حقوقی نیاز دارد.

چرا OV/EV الزام عمومی فروشگاه نیست؟

اصل فنی این است که کاربران به مقصد درست با TLS معتبر متصل شوند و پرداخت در معماری امن انجام شود. یک Badge یا Warranty جای تست Checkout و Incident response را نمی‌گیرد. برای چرخه سفارش، Callback و Verify از راهنمای اتصال امن درگاه پرداخت استفاده کنید.

رایگان یا پولی؛ تفاوت واقعی چیست؟

گواهی رایگان «بدون هزینه عملیاتی» نیست: باید Client، Secret، Alert، Renewal test و Rollback اداره شود. گواهی پولی نیز صرف خرید امن نمی‌ماند. بهترین گزینه، کم‌اصطکاک‌ترین چرخه صدور و تمدید متناسب با ریسک است.

Single-domain، Wildcard و Multi-domain

گواهی تک‌دامنه

یک نام دقیق مانند shop.example.com را پوشش می‌دهد. بعضی محصولات در عمل دامنه اصلی و www را با SAN مشترک می‌گیرند؛ فهرست SAN را بخوانید و از نام محصول حدس نزنید.

گواهی Wildcard

*.example.com نام‌هایی مانند shop.example.com و api.example.com را در همان سطح پوشش می‌دهد، اما:

• example.com باید جداگانه در SAN باشد.
• v2.api.example.com با Wildcard یک‌سطحی پوشش داده نمی‌شود.
• استفاده یک Private key مشترک روی سرورهای زیاد، Blast radius نشت را بالا می‌برد.
• Wildcard الزاماً ساده‌ترین انتخاب نیست؛ صدور خودکار نام‌های دقیق می‌تواند تفکیک بهتری بدهد.

Multi-domain یا SAN

چند نام متفاوت را در یک Certificate جمع می‌کند؛ مانند example.ir، example.com و api.example.net. این کار مدیریت را کم می‌کند، ولی همه نام‌ها در گواهی و Certificate Transparency قابل مشاهده‌اند و شکست Renewal روی چند سرویس اثر می‌گذارد. دامنه‌ها را بر اساس Owner، حساسیت و چرخه استقرار گروه‌بندی کنید، نه فقط برای کم‌کردن تعداد فایل‌ها.

ACME و روش‌های اثبات کنترل دامنه

ACME پروتکل Automation صدور و Renewal است. Client با CA ارتباط می‌گیرد، Challenge را انجام می‌دهد، Certificate را دریافت و در صورت پیکربندی درست Deploy می‌کند.

HTTP-01

Client یک Token را زیر مسیر /.well-known/acme-challenge/ روی Port ۸۰ در دسترس می‌گذارد. این روش ساده است، اما برای Wildcard کار نمی‌کند. Firewall، Redirect، CDN یا Rewrite نباید Challenge را مسدود کند. در چند Origin باید پاسخ هماهنگ باشد.

DNS-01

Client یک TXT record زیر _acme-challenge می‌سازد. برای Wildcard لازم است و در معماری چندسروری خوب عمل می‌کند. خطر اصلی، DNS API credential است: Token را حداقل‌اختیار، محدود به Zone و ترجیحاً بیرون Web server نگه دارید. Propagation و Cleanup رکوردهای قدیمی را نیز مانیتور کنید.

مستند رسمی Challengeهای Let’s Encrypt در بازبینی ۱۲ فوریه ۲۰۲۶ تأکید می‌کند HTTP-۰۱ فقط روی Port ۸۰ و DNS-۰۱ برای Wildcard قابل استفاده است. انتخاب را با قابلیت Automation DNS و Threat model انجام دهید.

طول عمر و زمان Renewal

در Snapshot رسمی ۶ اوت ۲۰۲۶، گواهی پیش‌فرض Let’s Encrypt ۹۰روزه است و خود سرویس Renewal حدود روز ۶۰ را توصیه می‌کند؛ گواهی کوتاه‌عمر اختیاری نیز چرخه متفاوتی دارد. این عدد را داخل Script کسب‌وکار Hard-code نکنید. Client باید بر اساس NotAfter، Policy CA و Window پیکربندی‌شده عمل کند و Alert مستقل داشته باشد.

Private key، CSR و Certificate chain

Private key

Private key باید روی مقصد مورد اعتماد ساخته شود، با Permission کمینه نگهداری و هرگز در Ticket، Email، Chat یا Repository عمومی ارسال نشود. Backup کلید فقط وقتی لازم است که طراحی Deployment ایجاب کند؛ آن را رمزنگاری، Access-control و Audit کنید. در صورت احتمال نشت، Certificate را Revoke و Key تازه بسازید.

CSR

Certificate Signing Request شامل Public key و اطلاعات درخواست است و با Private key امضا می‌شود. CSR Secret نیست، اما باید SANها و مشخصات آن بازبینی شوند. تولید CSR در پنل هاست را معادل نگهداری امن Key ندانید؛ محل واقعی Key و دسترسی‌ها را بپرسید.

زنجیره کامل

Server معمولاً باید Leaf certificate و Intermediateهای لازم را ارائه دهد. ارسال‌نکردن Full chain ممکن است روی Browser شما به‌دلیل Cache کار کند ولی روی موبایل یا Client دیگر خطای اعتماد بسازد. Root معمولاً توسط Client نگهداری می‌شود و بی‌دلیل از Server ارسال نمی‌شود.

RSA یا ECDSA و نسخه TLS

انتخاب Algorithm به Clientهای هدف، Web server و Automation بستگی دارد. ECDSA با کلید کوچک‌تر کارایی خوبی می‌دهد؛ RSA هنوز سازگاری گسترده‌ای دارد؛ بعضی Stackها می‌توانند هر دو Certificate را ارائه دهند. تصمیم را با Device matrix واقعی بگیرید، نه شعار «جدیدتر همیشه بهتر».

برای سرویس وب مدرن، TLS ۱.۲ و TLS ۱.۳ مبنای رایج‌اند و Protocolهای SSL و TLS ۱.۰/۱.۱ باید مگر در Legacy exception مستند کنار گذاشته شوند. TLS ۱.۳ در RFC 8446 استاندارد شده است. Cipher و Compatibility را با تنظیمات رسمی Web server/Load balancer مدیریت کنید؛ فهرست‌های تصادفی اینترنتی ممکن است Availability را خراب کنند.

گواهی Edge و Origin پشت CDN

سایت پشت CDN دو ارتباط جدا دارد:

1. Browser تا Edge CDN
2. Edge CDN تا Origin

گواهی عمومی Edge فقط بخش اول را امن می‌کند. بخش دوم نیز باید TLS داشته باشد و CDN باید نام و زنجیره Origin را اعتبارسنجی کند. Modeای که بدون Validation به هر Certificate در Origin اعتماد کند، دفاع ناقصی در برابر جعل مسیر داخلی است.

برای طراحی درست مسیر Edge، DNS و Origin به راهنمای انتخاب CDN در ایران و مقاله فایروال و Origin protection رجوع کنید.

Workflow نصب SSL/TLS بدون قطعی

۱. Inventory نام‌ها و مسیرها

همه Hostnameهای عمومی و داخلی لازم را فهرست کنید: Apex، www، API، پنل، Static، Webhook و Origin. از قرار دادن نام داخلی حساس در Certificate عمومی خودداری کنید. Owner، DNS provider، Web server و CDN هر نام را ثبت کنید.

۲. انتخاب Scope و Validation

Single، SAN یا Wildcard را بر اساس چرخه استقرار و Blast radius انتخاب کنید. DV را Default بدانید مگر الزام مشخصی برای OV/EV وجود داشته باشد. سیاست‌های CA و Browser در Baseline Requirements انجمن CA/Browser تغییر می‌کنند؛ روی وعده ثابت فروشنده تکیه نکنید.

۳. انتخاب ACME client و Account owner

Client رسمی/شناخته‌شده، مسیر Secret، زمان Schedule، Log و مسئول پاسخ به Failure را تعیین کنید. Renewal job باید Idempotent باشد و پس از دریافت Certificate، Reload سرویس را فقط در صورت موفقیت انجام دهد.

۴. صدور روی Staging یا سرور جدید

در مهاجرت Hosting، قبل از تغییر DNS گواهی سرور جدید را آماده کنید. DNS-۰۱ اجازه می‌دهد بدون Public بودن Origin جدید، Domain control را اثبات کنید. اگر HTTP-۰۱ به کار می‌برید، Routing چند سرور و Port ۸۰ را هماهنگ کنید.

۵. نصب Leaf و Intermediate

Certificate، Private key متناظر و Full chain را در VirtualHost/SNI درست قرار دهید. Permission فایل و User سرویس را کنترل کنید. سپس Syntax config و Reload بدون قطعی را مطابق مستند Web server انجام دهید.

۶. تست مستقیم هر Hostname

قبل از Redirect عمومی، HTTPS همه نام‌ها را مستقیم آزمایش کنید: Name match، Expiry، Chain، Protocol، Header، صفحه خطا، API و Checkout. فقط تست Browser روی Laptop مدیر کافی نیست.

۷. انتقال HTTP به HTTPS

هر URL HTTP باید با Redirect دائمی مستقیم به معادل HTTPS خودش برود. برای Apache می‌توانید Rule را در VirtualHost یا با راهنمای مدیریت امن فایل htaccess اعمال کنید. پشت CDN، Owner Redirect را یک لایه انتخاب کنید تا Loop نسازید.

۸. تکمیل Migration سئو

• Internal link، Canonical، Sitemap و hreflang را HTTPS کنید.
• Resourceهای HTTP را اصلاح کنید؛ Mixed content را با Rewrite کور پنهان نکنید.
• Propertyهای لازم Search Console را Verify و Indexing/Crawl را مانیتور کنید.
• Redirectها را مستقیم و پایدار نگه دارید.
• Robots، noindex و Assetها را روی HTTPS بررسی کنید.

Google در راهنمای رسمی مهاجرت URL انتقال HTTP به HTTPS را Site move می‌داند، ولی Change of Address لازم ندارد. هدف SEO، حفظ Mapping دقیق و سیگنال‌های یکپارچه است؛ نه ادعای جهش رتبه صرفاً با خرید Certificate.

۹. HSTS پس از تثبیت

HSTS به Browser می‌گوید فقط HTTPS استفاده کند. ابتدا همه دامنه‌ها، Subdomainهای احتمالی، Downloadها و Integrations را اصلاح کنید. includeSubDomains و Preload می‌توانند دامنه‌های فراموش‌شده را از دسترس خارج کنند؛ با Max-age کوتاه Pilot کنید و مسیر Rollback را بفهمید.

تمدید خودکار؛ جایی که بیشتر قطعی‌ها رخ می‌دهد

وجود Cron یا Timer به معنی Renewal سالم نیست. باید کل زنجیره را مانیتور کنید:

1. ACME client اجرا شده است؟
2. Challenge از چند نقطه معتبر پاسخ داده شده است؟
3. Certificate جدید واقعاً صادر شده است؟
4. فایل جدید روی تمام Nodeها Deploy شده است؟
5. Web server Reload موفق بوده است؟
6. Certificate ارائه‌شده در اینترنت همان نسخه جدید است؟
7. Edge و Origin هر دو تمدید شده‌اند؟

Alertهای پیشنهادی

• Expiry threshold در ۳۰، ۱۴ و ۷ روز؛ متناسب با چرخه CA
• شکست Renewal job یا DNS API
• اختلاف Serial/Fingerprint میان Nodeها
• Certificate ناشناخته در CT log
• Name mismatch یا Chain error در Probe خارجی
• افزایش TLS handshake error پس از Deployment

Alert باید به فرد پاسخ‌گو برسد و Runbook داشته باشد. برای طراحی Probe و On-call از مانیتورینگ Uptime و عملکرد و Observability سایت استفاده کنید.

Certificate Transparency و CAA

CT log

Certificateهای عمومی در Logهای شفافیت گواهی ثبت می‌شوند. این موضوع به کشف صدور ناخواسته کمک می‌کند، اما SANهای Certificate را نیز عمومی می‌سازد. Alert روی نام‌های برند و دامنه‌ها تنظیم کنید؛ هر صدور ناشناخته الزاماً حمله نیست، ولی باید Owner آن مشخص شود.

CAA

رکورد DNS CAA می‌تواند CAهای مجاز برای صدور را محدود کند. این کنترل مفید است، اما اشتباه در رکورد یا فراموش‌کردن CA جدید Renewal را می‌شکند. پیش از اعمال، Inventory همه Issuerها، Wildcard policy، Failover و مسیر تغییر اضطراری را ثبت کنید.

خطاهای رایج SSL و روش عیب‌یابی

چگونه گواهی زنده را تست کنیم؟

سه سطح تست داشته باشید:

• Certificate: Subject/SAN، Issuer، Serial، NotBefore/NotAfter، Algorithm و Chain.
• TLS endpoint: Protocol، Cipher، SNI، ALPN، OCSP و Errorهای Handshake.
• Application: Redirect، Cookie Secure، HSTS، Mixed content، Login، API، Checkout و Callback.

نمونه مشاهده Handshake از Shell:

openssl s_client -connect example.com:443 -servername example.com -showcerts
curl -I http://example.com/path
curl -I https://example.com/path

خروجی را کور تفسیر نکنید. تاریخ سیستم، DNS محلی، Proxy سازمانی و Cache می‌توانند نتیجه را تغییر دهند. Probe خارجی از داخل و خارج ایران کمک می‌کند تفاوت مسیر شبکه یا CDN را ببینید.

SSL در وردپرس و WooCommerce

• URLهای Home و Site URL را فقط پس از آماده‌بودن HTTPS تغییر دهید.
• Database را با ابزار آگاه از Serialized data اصلاح کنید؛ Replace خام می‌تواند داده را خراب کند.
• Cookieهای Session و Admin باید Secure باشند و Proxy scheme درست به WordPress منتقل شود.
• Cache را برای Cart، Checkout، My Account و Callback درگاه استثنا کنید.
• Webhook و REST clientها را با Chain جدید آزمایش کنید.
• Plugin «Force SSL» جای معماری صحیح CDN/Origin و Redirect server-side را نمی‌گیرد.
• Change را با Staging، Smoke test و فرایند انتشار و Rollback وردپرس انجام دهید.

مثال تصمیم برای سه کسب‌وکار ایرانی

فروشگاه WordPress روی هاست اشتراکی

یک DV خودکار شامل دامنه اصلی و www، TLS معتبر روی هاست، Redirect مستقیم و Alert Expiry معمولاً مناسب است. اگر CDN فعال شد، Certificate Edge و Origin را جدا ثبت کنید. بودجه را بیشتر صرف MFA، Update، Backup، درگاه امن و Monitoring کنید تا EV صرفاً تبلیغاتی.

SaaS با app و api و tenant

برای app.example.com و api.example.com می‌توان Certificateهای جدا با Owner مستقل داشت. اگر Tenantها به‌شکل customer.example.com ساخته می‌شوند، Wildcard با DNS-۰۱ یا صدور On-demand کنترل‌شده بررسی شود. Rate limit CA، Key isolation و حذف Tenant باید در Lifecycle باشد.

شرکت چندبرندی با .ir و .com

SAN مشترک فقط وقتی مناسب است که Owner، Release window و ریسک دامنه‌ها یکسان باشد. اگر تیم‌ها یا زیرساخت‌ها جدا هستند، Certificate جدا Blast radius را کم می‌کند. برای OV/EV ابتدا پذیرش مدارک، زمان Revalidation و Automation را با CA به‌صورت کتبی تأیید کنید.

چک‌لیست انتخاب و بهره‌برداری

• همه Hostnameها و Ownerها Inventory شده‌اند.
• DV/OV/EV بر اساس الزام واقعی انتخاب شده، نه وعده رتبه یا قفل سبز.
• Scope تک‌دامنه، Wildcard یا SAN و Blast radius مستند است.
• Private key روی مقصد امن تولید و دسترسی آن محدود است.
• ACME challenge، DNS secret و Renewal automation تست شده‌اند.
• Leaf و Intermediate کامل روی SNI درست نصب شده‌اند.
• TLS ۱.۲/۱.۳ و Client matrix بررسی شده‌اند.
• Edge و Origin هر دو رمزنگاری و Strict validation دارند.
• HTTP به HTTPS یک Hop و مقصد معادل دارد.
• Canonical، Sitemap، internal link و hreflang به HTTPS به‌روز شده‌اند.
• Mixed content، API، Login، Checkout و Callback تست شده‌اند.
• Alert Expiry، CT و Renewal failure به On-call می‌رسد.
• HSTS پس از Pilot و بدون ریسک دامنه فراموش‌شده فعال می‌شود.
• Runbook Rollback و صدور اضطراری تمرین شده است.

پرسش‌های متداول گواهی SSL

۱. آیا SSL رایگان برای فروشگاه اینترنتی امن است؟

بله، گواهی DV رایگان استاندارد می‌تواند همان TLS امن را فراهم کند. فروشگاه باید Renewal، Private key، Chain، CDN/Origin و تنظیم Protocol را درست اداره کند. امنیت پرداخت نیز به Verify، Token، Access control، Logging و Scope PCI وابسته است؛ نه قیمت Certificate.

۲. Wildcard دامنه اصلی را هم پوشش می‌دهد؟

خیر، *.example.com به‌تنهایی example.com را پوشش نمی‌دهد و سطح عمیق‌تر مانند v2.api.example.com نیز شامل نمی‌شود. نام Apex و هر Hostname لازم را در SAN بررسی کنید.

۳. OV یا EV باعث رتبه بهتر گوگل می‌شود؟

Google استفاده از HTTPS را توصیه می‌کند، اما مدرکی برای برتری رتبه OV/EV نسبت به DV معتبر وجود ندارد. سطح Validation را با نیاز هویت سازمانی انتخاب کنید و SEO را با Redirect، Canonical، Sitemap و محتوای مفید اداره کنید.

۴. چرا با وجود تمدید، سایت هنوز گواهی قدیمی نشان می‌دهد؟

ممکن است فایل جدید Deploy نشده، Web server Reload نشده، یکی از Nodeها قدیمی، CDN هنوز Certificate قبلی یا SNI روی VirtualHost اشتباه باشد. Serial/Fingerprint را در Edge، Origin و هر Node جدا مقایسه کنید.

۵. چند روز مانده به انقضا تمدید کنیم؟

به Policy CA و طول عمر Certificate بستگی دارد. به یک روز ثابت متکی نباشید؛ ACME client را طبق توصیه CA تنظیم کنید و Alertهای مستقل چندمرحله‌ای داشته باشید. برای Let’s Encrypt ۹۰روزه، مستند رسمی فعلی Renewal حدود روز ۶۰ را پیشنهاد می‌کند.

جمع‌بندی

گواهی SSL مناسب لزوماً گران‌ترین گزینه نیست. ابتدا Hostname، Owner و معماری Edge/Origin را مشخص کنید؛ سپس Validation و Scope را انتخاب، Private key را امن، ACME و Renewal را خودکار، Full chain را نصب و از چند Client تست کنید. در مهاجرت HTTPS، Redirect مستقیم، Canonical و Assetها را هماهنگ و HSTS را فقط پس از تثبیت فعال کنید.

اگر Certificateها، CDN، Origin و Renewal شما Owner مشخص ندارند یا پیش از مهاجرت HTTPS به Test plan نیاز دارید، از مشاوره فنی مایندیو برای Audit و طراحی Runbook کمک بگیرید.

بازبینی فنی منابع: ۶ اوت ۲۰۲۶. سیاست CAها، طول عمر Certificate و پشتیبانی Clientها متغیر است؛ مستند Issuer و زیرساخت خود را هنگام اجرا دوباره بررسی کنید.