نصب گواهی SSL از یک مرجع صدور گواهی تجاری

کیانا4 روز پیش

0 13 خواندن این مطلب 16 دقیقه زمان میبرد

مقدمه

برای نصب گواهی تجاری SSL/TLS، ابتدا یک CSR و کلید خصوصی تولید می‌کنید، سپس CSR را به یک مرجع صدور گواهی (CA) مورد اعتماد ارسال می‌کنید، مالکیت دامنه را تأیید می‌کنید و در نهایت گواهی صادرشده و زنجیره گواهی‌های میانی (Intermediate) را روی وب‌سرور خود نصب می‌کنید. نتیجه، HTTPS با اعتماد مرورگرهاست و در گزینه‌های OV/EV، تأیید سازمانی اضافی توسط CA (که برای سیاست‌های داخلی، تأمین‌کالا یا الزامات انطباق مفید است) نیز شامل می‌شود.

قبل از میانه دهه ۲۰۱۰، بسیاری از وب‌سایت‌های کوچک‌تر همیشه از SSL یا HTTPS استفاده نمی‌کردند. از آن زمان به بعد، انتظارات امنیتی افزایش یافته و پروژه Let’s Encrypt برای ارائه گواهی‌های SSL رایگان و مورد اعتماد در مقیاس بزرگ ایجاد شد؛ که به تقریباً همه اجازه می‌دهد در صورت نیاز از HTTPS استفاده کنند.

اما گواهی‌های Let’s Encrypt محدودیت‌هایی دارند. آن‌ها هر ۹۰ روز منقضی می‌شوند؛ که معمولاً نیازمند یک فرایند خودکارِ درست‌کار برای تمدید است. استفاده از Let’s Encrypt در محیط‌هایی که خودکارسازی محدود شده یا اعتبارسنجی خروجی (مانند به‌روزرسانی‌های DNS برای گواهی‌های وایلدکارت) امکان‌پذیر نیست هم می‌تواند سخت‌تر باشد. علاوه بر این، CAهای تجاری ممکن است قابلیت‌های مدیریت گواهی، شرایط ضمانت/بیمه یا بررسی سازمانی‌ای را ارائه دهند که برخی کسب‌وکارها و برنامه‌های انطباق ترجیح می‌دهند.

این آموزش شما را در انتخاب CA، تولید CSR و کلید خصوصی، دریافت گواهی و نصب آن روی Nginx یا Apache در اوبونتو همراهی می‌کند. همچنین می‌بینید چطور نصب را تأیید کنید، مشکلات رایج زنجیره گواهی را رفع کنید و تمدید را مدیریت کنید.

نکات کلیدی

SSL تجاری برای نیازهای خاص مناسب است: اعتبار طولانی‌تر بدون خودکارسازی مکرر تمدید، OV/EV برای نیازهای تأیید سازمانی، یا قابلیت‌های فروشنده (SLA پشتیبانی، صدور مجدد مدیریت‌شده، شرایط ضمانت/قرارداد).
CSR و کلید خصوصی روی سرور شما می‌مانند: فقط CSR را به CA می‌فرستید؛ کلید خصوصی هرگز از ماشین خارج نمی‌شود.
زنجیره گواهی باید کامل باشد: گواهی سایت خودتان به‌همراه گواهی(های) میانی CA را سرو کنید؛ نبودِ گواهی‌های میانی باعث خطاهای اعتماد مرورگر می‌شود.
Nginx به یک فایل زنجیره‌شده نیاز دارد: گواهی خود و گواهی(های) میانی را در یک فایل ترکیب کنید؛ Apache می‌تواند فایل گواهی میانی را جداگانه ارجاع دهد.
همیشه بعد از نصب تأیید کنید: با openssl s_client یا یک مرورگر، زنجیره و کارکرد HTTPS و ریدایرکت HTTP-به-HTTPS را بررسی کنید.
یادآور تمدید تنظیم کنید: گواهی‌های تجاری معمولاً طی ۱ تا ۲ سال منقضی می‌شوند؛ فراموش کردن تمدید باعث قطعی می‌شود.

پیش‌نیازها

برای تلاش در دریافت گواهی SSL از یک CA تجاری، چند پیش‌نیاز وجود دارد:

یک نام دامنه ثبت‌شده. این آموزش در سراسر متن از example.com استفاده می‌کند. می‌توانید نام دامنه را از یک ثبت‌کننده دامنه (Registrar) مانند Namecheap یا هر ارائه‌دهنده دلخواه خودتان بخرید. برخی ارائه‌دهندگان هاستینگ، بسته به موجودی، دامنه را همراه پلن‌های هاستینگ ارائه می‌کنند.
دسترسی به یکی از آدرس‌های ایمیل موجود در رکورد WHOIS دامنه‌تان یا یک آدرس ایمیل از نوع «مدیر» (admin) در خود دامنه. مراجع صدور گواهی SSL معمولاً کنترل دامنه را با ارسال ایمیل تأیید به یکی از آدرس‌های رکورد WHOIS دامنه یا به یک آدرس ایمیل عمومی مدیر در خود دامنه اعتبارسنجی می‌کنند. برای صدور گواهی اعتبارسنجی گسترده (EV)، همچنین لازم است مدارکی برای اثبات هویت قانونی مالک وب‌سایت و موارد دیگر به CA ارائه دهید.
رکوردهای DNS تنظیم‌شده برای سرورتان. اگر از پارمین کلود استفاده می‌کنید، لطفاً برای جزئیات نحوه افزودن آن‌ها مستندات DNS پارمین کلود را ببینید.
این آموزش از یک سرور اوبونتو (سازگار با اوبونتو 22.04 و 24.04) استفاده می‌کند که با پیروی از راهنمای راه‌اندازی اولیه سرور با اوبونتو در پارمین کلود آماده شده؛ شامل کاربر غیر root دارای sudo و یک فایروال.
همچنین باید Nginx یا Apache نصب داشته باشید؛ طبق راهنماهای «نحوه نصب Nginx روی اوبونتو» یا «نحوه نصب وب‌سرور Apache روی اوبونتو» در پارمین کلود. مطمئن شوید یک بلاک سرور (یا هاست مجازی Apache) برای دامنه‌تان دارید.

گام ۱ — انتخاب مرجع صدور گواهی (CA)

از CAای استفاده کنید که عضو برنامه‌های ریشه (Root Program) اصلی باشد (تا مرورگرها به آن اعتماد کنند) و نوع گواهی مورد نیازتان را ارائه دهد. در ادامه مهم‌ترین عوامل بررسی آمده‌اند.

عضویت در برنامه‌های گواهی ریشه

مهم‌ترین نکته این است که CA انتخابی شما، عضو برنامه‌های گواهی ریشه رایج‌ترین سیستم‌عامل‌ها و مرورگرهای وب باشد؛ یعنی یک CA «مورد اعتماد» باشد و گواهی ریشه‌اش توسط مرورگرهای رایج و سایر نرم‌افزارها مورد اعتماد باشد. اگر گواهی SSL وب‌سایت شما توسط یک CA مورد اعتماد امضا شده باشد، هویتش توسط نرم‌افزاری که به آن CA اعتماد دارد، معتبر تلقی می‌شود.

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

انواع گواهی

مطمئن شوید CAای را انتخاب می‌کنید که نوع گواهی مورد نیازتان را ارائه می‌دهد. بسیاری از CAها تنوع‌هایی از این انواع گواهی را با نام‌ها و ساختارهای قیمتی مختلف عرضه می‌کنند. توضیح کوتاهی از هر نوع:

تک‌دامنه (Single Domain): برای یک دامنه منفرد استفاده می‌شود؛ مثلاً example.com. توجه کنید که زیردامنه‌های اضافی مانند www.example.com شامل نمی‌شوند.
وایلدکارت (Wildcard): برای یک دامنه و هر کدام از زیردامنه‌هایش استفاده می‌شود. مثلاً گواهی وایلدکارت برای *.example.com می‌تواند برای www.example.com و store.example.com هم استفاده شود.
چنددامنه‌ای (Multiple Domain): که به نام گواهی SAN یا UC شناخته می‌شود؛ با چندین دامنه و زیردامنه که به فیلد Subject Alternative Name اضافه می‌شوند استفاده می‌گردد. مثلاً یک گواهی چنددامنه‌ای منفرد می‌تواند برای example.com، www.example.com و example.net استفاده شود.

علاوه بر انواع گواهی فوق، سطوح مختلفی از اعتبارسنجی هم CAها ارائه می‌دهند:

اعتبارسنجی دامنه (DV): گواهی‌های DV بعد از اینکه CA تأیید کند درخواست‌دهنده مالک یا کنترل‌کننده دامنه موردنظر است، صادر می‌شوند.
اعتبارسنجی سازمان (OV): گواهی‌های OV فقط بعد از اینکه CA صادرکننده، هویت قانونی درخواست‌دهنده را تأیید کند صادر می‌شوند.
اعتبارسنجی گسترده (EV): گواهی‌های EV فقط بعد از اینکه CA صادرکننده طبق مجموعه‌ای سخت‌گیرانه از دستورالعمل‌ها، هویت قانونی و موارد دیگر درخواست‌دهنده را تأیید کند صادر می‌شوند. هدف این نوع گواهی، ارائه اطمینان اضافی است که سازمانِ پشت سایت توسط CA تأیید شده؛ که برای سیاست‌های داخلی، تأمین‌کالا یا الزامات انطباق مفید olabilir است. گواهی‌های EV می‌توانند تک‌دامنه یا چنددامنه باشند، اما وایلدکارت نه.

راهنمای سریع انتخاب گواهی

از جدول زیر برای انتخاب نوع درست گواهی بر اساس نیازهای رایج دنیای واقعی استفاده کنید:

نیاز	نوع گواهی پیشنهادی
وب‌سایت عمومی با HTTPS پایه	اعتبارسنجی دامنه (DV)
هویت شرکت قابل‌مشاهده برای کاربران	اعتبارسنجی سازمان (OV) یا گسترده (EV)
زیردامنه‌های زیاد (مثلاً `*.example.com`)	گواهی وایلدکارت
چند دامنه نامرتبط	گواهی چنددامنه‌ای (SAN)
تمدید خودکار مجاز نیست	گواهی تجاری DV/OV
الزامات قانونی یا انطباقی	گواهی OV یا EV

اگر فقط به رمزنگاری و اعتماد مرورگر نیاز دارید، گواهی‌های DV کافی‌اند. وقتی تأیید هویت قانونی یا نشانگرهای اعتماد برند نیاز است، OV یا EV را انتخاب کنید.

قابلیت‌های اضافی

بسیاری از CAها مجموعه متنوعی از قابلیت‌های «جایزه» برای متمایز شدن از بقیه فروشندگان صدور گواهی SSL ارائه می‌دهند. برخی از این قابلیت‌ها می‌توانند در نهایت برایتان پول حافظ کنند؛ پس مهم است که قبل از خرید، نیازهایتان را با پیشنهادها بسنجید. نمونه‌هایی از قابلیت‌هایی که باید دنبالشان بگردید شامل صدور مجدد رایگان گواهی یا گواهی با قیمت تک‌دامنه که هم برای www. و هم نام پایه دامنه کار کند؛ مثلاً www.example.com همراه با SAN مثال example.com.

گام ۲ — تولید CSR و کلید خصوصی

بعد از مرتب کردن پیش‌نیازها و دانستن نوع گواهی مورد نیاز، زمان تولید درخواست امضای گواهی (CSR) و کلید خصوصی است.

اگر قصد استفاده از Apache HTTP یا Nginx به‌عنوان وب‌سرور را دارید، می‌توانید از دستور openssl برای تولید کلید خصوصی و CSR روی وب‌سرورتان استفاده کنید. در این آموزش می‌توانید همه فایل‌های مربوطه را در دایرکتوری خانه نگه دارید؛ اما راحت باشید آن‌ها را در هر مکان امنی روی سرورتان ذخیره کنید.

برای تولید کلید خصوصی و CSR (مثال example.com را با دامنه خودتان جایگزین کنید)، این را اجرا کنید:

openssl req -newkey rsa:2048 -nodes -keyout example.com.key -out example.com.csr

برای امنیت قوی‌تر می‌توانید از RSA با ۴۰۹۶ بیت استفاده کنید: rsa:2048 را با rsa:4096 جایگزین کنید. اندازه کلید اندکی روی کارایی هندشیک TLS اثر می‌گذارد؛ ۲۰۴۸ به‌طور گسترده پذیرفته شده و ۴۰۹۶ جایی توصیه می‌شود که انطباق یا سیاست آن را الزامی کند.

در این نقطه، از شما چند خط اطلاعات که در درخواست گواهی گنجانده می‌شوند پرسیده می‌شود. مهم‌ترین بخش، فیلد Common Name است که باید با نامی که می‌خواهید گواهی را با آن استفاده کنید مطابقت داشته باشد؛ مثلاً example.com، www.example.com یا (برای درخواست گواهی وایلدکارت) *.example.com. اگر قصد دریافت گواهی OV یا EV را دارید، مطمئن شوید همه فیلدهای دیگر دقیقاً جزئیات سازمان یا کسب‌وکار شما را منعکس می‌کنند. ارائه «رمز چالش» (Challenge Password) ضروری نیست.

مثلاً:

Output
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:New York
Locality Name (eg, city) []:New York
Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Company
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:example.com
Email Address []:sammy@example.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

این دستور یک فایل .key و یک فایل .csr تولید می‌کند. فایل .key کلید خصوصی شماست و باید امن نگه داشته شود. فایل .csr چیزی است که به CA می‌فرستید تا گواهی SSL خود را درخواست کنید.

ls example.com*

Output
example.com.csr  example.com.key

هنگام ارسال درخواست گواهی به CA، لازم است CSR را کپی و پیست کنید. برای چاپ محتوای CSR، از cat استفاده کنید:

cat example.com.csr

حالا آماده خرید گواهی از یک CA هستید.

گام ۳ — خرید و دریافت گواهی

ارائه‌دهندگان CA تجاری زیادی وجود دارند و می‌توانید مناسب‌ترین گزینه‌ها را برای راه‌اندازی خودتان مقایسه کنید. مثلاً Namecheap به‌عنوان یک فروشنده مجدد گواهی SSL عمل می‌کند و در گذشته CAهای بالادستی خود را برای ارائه بهترین ارزش تغییر داده است. بسیاری از فروشندگان مجدد (مثل Namecheap) گواهی‌هایی از CAهای مورد اعتماد مانند Sectigo/Comodo ارائه می‌دهند.

بعد از انتخاب، باید CSR تولیدشده در گام قبل را آپلود کنید. ارائه‌دهنده CA شما احتمالاً مرحله «تأییدکننده» (Approver) هم دارد؛ که یک ایمیل درخواست اعتبارسنجی به آدرسی در رکورد WHOIS دامنه‌تان یا به آدرسی از نوع مدیرِ دامنه‌ای که برایش گواهی می‌گیرید می‌فرستد.

بعد از تأیید گواهی، آن به مدیر نام‌برده ایمیل می‌شود. آن را کپی و در همان مکانی که کلید خصوصی و CSR را تولید کردید روی سرورتان ذخیره کنید. گواهی را با نام دامنه و پسوند .crt نام‌گذاری کنید؛ مثلاً example.com.crt و گواهی میانی را intermediate.crt بنامید.

گواهی حالا آماده نصب روی وب‌سرور است؛ اما اول ممکن است لازم باشد تغییری در فایروالتان بدهید.

گام ۴ — به‌روزرسانی فایروال برای اجازه HTTPS

اگر فایروال ufw را طبق توصیه راهنمای راه‌اندازی اوبونتوی پارمین کلود فعال کرده باشید، باید تنظیمات را برای اجازه عبور ترافیک HTTPS تنظیم کنید. Nginx و Apache هر دو هنگام نصب، چند پروفایل با ufw ثبت می‌کنند.

می‌توانید تنظیم فعلی را با تایپ این ببینید:

sudo ufw status

اگر خروجی فقط شامل Nginx HTTP یا Apache باشد، فقط ترافیک HTTP به وب‌سرور مجاز است:

Output
Status: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere                  
Nginx HTTP                 ALLOW       Anywhere                  
OpenSSH (v6)               ALLOW       Anywhere (v6)             
Nginx HTTP (v6)            ALLOW       Anywhere (v6)

برای اجازه ترافیک HTTPS، پروفایل Nginx Full یا Apache Full را فعال و پروفایل فقط-HTTP را حذف کنید:

sudo ufw allow 'Nginx Full'
sudo ufw delete allow 'Nginx HTTP'

برای Apache، از Apache Full استفاده کنید و اگر فقط HTTP مجاز بود، Apache را حذف کنید:

sudo ufw allow 'Apache Full'
sudo ufw delete allow 'Apache'

سپس نتیجه را تأیید کنید:

sudo ufw status

Output
Status: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere
Nginx Full                 ALLOW       Anywhere
OpenSSH (v6)               ALLOW       Anywhere (v6)
Nginx Full (v6)            ALLOW       Anywhere (v6)

در گام نهایی، گواهی را نصب می‌کنید.

گام ۵ — نصب گواهی روی سرور

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

این آموزش Nginx و Apache را روی اوبونتو پوشش می‌دهد (سازگار با اوبونتو 22.04 و جدیدتر)؛ بیشتر توزیع‌های مدرن لینوکس مشابه کار می‌کنند. این آموزش همچنین این فرض‌ها را دارد:

کلید خصوصی example.com.key نام دارد
گواهی SSL example.com.crt نام دارد
گواهی(های) میانی CA که ارائه‌دهنده‌تان برگردانده در فایلی به نام intermediate.crt است

نکته: در محیط پروداکشن، این فایل‌ها باید جایی ذخیره شوند که فقط پروسه وب‌سرور (معمولاً root) به آن‌ها دسترسی داشته باشد و کلید خصوصی باید امن نگه داشته شود. مثلاً Let’s Encrypt گواهی‌هایی که تولید می‌کند را در /etc/letsencrypt ذخیره می‌کند. مثال‌های پروداکشن به‌دلیل پیچیدگی پیکربندی‌های چندسروری متفاوت خواهند بود.

Nginx

این مراحل نصب دستی گواهی SSL روی Nginx است.

مرورگرها برای اعتماد به سایت شما به زنجیره کامل (گواهی شما به‌همراه گواهی(های) میانی CA) نیاز دارند. اگر CA شما فقط یک گواهی میانی (یا چندین گواهی میانی) برگردانده، باید یک فایل زنجیره‌شده منفرد بسازید که شامل گواهی شما و به‌دنبالش گواهی(های) میانی باشد. Nginx برای ssl_certificate یک فایل انتظار دارد؛ Apache می‌تواند فایل میانی جداگانه استفاده کند (بخش Apache را در پایین ببینید).

در محیط‌های پروداکشن، گواهی‌ها را در مکان‌های سیستم به‌جای دایرکتوری‌های خانه ذخیره کنید. مسیرهای رایج شامل /etc/ssl/certs برای فایل‌های گواهی و /etc/ssl/private برای کلیدهای خصوصی است. مجوزهای کلید خصوصی را فقط به root محدود کنید:

sudo chmod 600 /etc/ssl/private/example.com.key
sudo chown root:root /etc/ssl/private/example.com.key

با فرض اینکه فایل گواهی شما example.com.crt و گواهی میانی intermediate.crt است، فایل زنجیره‌شده را بسازید:

cat example.com.crt intermediate.crt > example.com.chained.crt

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

با nano یا ویرایشگر مورد علاقه‌تان، فایل بلاک سرور پیش‌فرض Nginx را برای ویرایش باز کنید:

sudo nano /etc/nginx/sites-enabled/default

دایرکتیو listen را پیدا و به listen 443 ssl تغییر دهید:

/etc/nginx/sites-enabled/default
…
server {
    listen 443 ssl;
…

سپس، دایرکتیو server_name را در همان بلاک سرور پیدا کنید و مطمئن شوید مقدارش با Common Name گواهی‌تان مطابقت دارد. همچنین دایرکتیوهای ssl_certificate و ssl_certificate_key را برای مشخص کردن مسیر فایل‌های گواهی و کلید خصوصی اضافه کنید:

/etc/nginx/sites-enabled/default
…
    server_name example.com;
    ssl_certificate /home/sammy/example.com.chained.crt;
    ssl_certificate_key /home/sammy/example.com.key;
…

اگر فایل‌های گواهی و کلید را به /etc/ssl/certs و /etc/ssl/private منتقل کرده‌اید، این مسیرها را متناسب به‌روز کنید.

برای اجازه فقط امن‌ترین پروتکل‌ها و رمزنگاری‌های SSL، این خطوط را به فایل اضافه کنید:

/etc/nginx/sites-enabled/default
…
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
…

در نهایت، برای ریدایرکت پیش‌فرض درخواست‌های HTTP به HTTPS، می‌توانید یک بلاک سرور اضافی در بالای فایل اضافه کنید:

/etc/nginx/sites-enabled/default
server {
    listen 80;
    server_name example.com;
    return 301 https://$server_name$request_uri;
}
…

فایل را ذخیره و ببندید. اگر از nano استفاده می‌کنید، Ctrl+X و بعد هنگام درخواست، Y و سپس Enter را بزنید.

قبل از ری‌استارت Nginx، می‌توانید پیکربندی‌تان را با nginx -t اعتبارسنجی کنید:

sudo nginx -t

اگر مشکلی نبود، Nginx را برای اعمال پیکربندی SSL ریلود کنید (یا اگر راه‌اندازی شما از ریلود پشتیبانی نمی‌کند از sudo systemctl restart nginx استفاده کنید):

sudo systemctl reload nginx

با باز کردن سایت روی HTTPS (مثلاً https://example.com) و روی HTTP (مثلاً http://example.com) تست بگیرید تا از کارکرد ریدایرکت مطمئن شوید.

Apache

این مراحل نصب دستی گواهی SSL روی Apache است.

با nano یا ویرایشگر مورد علاقه‌تان، فایل هاست مجازی پیش‌فرض Apache را برای ویرایش باز کنید:

نکته: روی اوبونتو، رویکرد توصیه‌شده استفاده از فایل از پیش پیکربندی‌شده default-ssl.conf به‌جای ویرایش مستقیم 000-default.conf است. می‌توانید بعد از به‌روزرسانی مسیرهای گواهی، آن را با sudo a2ensite default-ssl فعال کنید. روش نمایش‌داده‌شده در پایین کار می‌کند؛ اما استفاده از default-ssl.conf با چیدمان‌های استاندارد SSL آپاچی سازگارتر است.

sudo nano /etc/apache2/sites-available/000-default.conf

ورودی <VirtualHost *:80> را پیدا و طوری تغییر دهید که وب‌سرورتان روی پورت ۴۴۳ گوش دهد:

/etc/apache2/sites-available/000-default.conf
…
<VirtualHost *:443>
…

سپس، دایرکتیو ServerName را اضافه کنید (اگر از قبل وجود ندارد):

/etc/apache2/sites-available/000-default.conf
…
ServerName example.com
…

سپس خطوط زیر را برای مشخص کردن مسیرهای گواهی و کلید اضافه کنید:

/etc/apache2/sites-available/000-default.conf
…
SSLEngine on
SSLCertificateFile /home/sammy/example.com.crt
SSLCertificateKeyFile /home/sammy/example.com.key
SSLCACertificateFile /home/sammy/intermediate.crt
…

در دیپلوی‌های پروداکشن، فایل‌های گواهی را به /etc/ssl/certs و کلیدهای خصوصی را به /etc/ssl/private منتقل کنید و مطمئن شوید کلید خصوصی فقط توسط root قابل خواندن است. این کار از افشای تصادفی جلوگیری می‌کند و از قراردادهای امنیتی استاندارد لینوکس پیروی می‌کند.

در این نقطه، سرورتان برای گوش دادن فقط روی HTTPS (پورت ۴۴۳) پیکربندی شده؛ پس درخواست‌های HTTP (پورت ۸۰) سرو نمی‌شوند. برای ریدایرکت درخواست‌های HTTP به HTTPS، این را به بالای فایل اضافه کنید (نام را در هر دو جایگزین کنید):

/etc/apache2/sites-available/000-default.conf
<VirtualHost *:80>
   ServerName example.com
   Redirect permanent / https://example.com/
</VirtualHost>
…

فایل را ذخیره و ببندید. اگر از nano استفاده می‌کنید، Ctrl+X و بعد هنگام درخواست، Y و سپس Enter را بزنید.

ماژول SSL آپاچی را با اجرای این دستور فعال کنید:

sudo a2enmod ssl

حالا آپاچی را ری‌استارت کنید تا پیکربندی جدید بارگذاری و TLS/SSL روی HTTPS فعال شود:

sudo systemctl restart apache2

با بازدید از سایت روی HTTPS و HTTP تأیید کنید که گواهی و ریدایرکت درست کار می‌کنند.

تأیید نصب SSL

بعد از نصب گواهی، تأیید کنید که زنجیره کامل است و سرور گواهی مورد اعتماد ارائه می‌دهد.

از خط فرمان، برای اتصال و بررسی زنجیره از OpenSSL استفاده کنید (مثال example.com را با دامنه خودتان جایگزین کنید):

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates -subject -issuer

باید Subject گواهی‌تان (CN=example.com یا مشابه)، صادرکننده (Issuer) (CA) و تاریخ‌های اعتبار را ببینید. برای دیدن کل زنجیره و خطاهای احتمالی اعتبارسنجی:

openssl s_client -connect example.com:443 -servername example.com

در انتها به دنبال Verify return code: 0 (ok) بگردید. هر کد بازگشتی دیگر معمولاً یعنی گواهی میانی مفقود یا اشتباه است.

در مرورگر، https://example.com را باز کنید، روی آیکن قفل کلیک کنید و گواهی را ببینید. زنجیره باید نشان دهد: گواهی سایت شما، سپس گواهی(های) میانی، سپس ریشه. اگر زنجیره شکسته باشد، قفل ممکن است هشدار یا «Certificate not trusted» نشان دهد.

عیب‌یابی خطاهای رایج نصب SSL

مرورگر «Your connection is not private» یا «Certificate not trusted» نشان می‌دهد

علت: مرورگر نمی‌تواند زنجیره کامل به یک ریشه مورد اعتماد بسازد. معمولاً گواهی(های) میانی مفقود یا با ترتیب اشتباه هستند.

راه‌حل برای Nginx: مطمئن شوید از فایل زنجیره‌شده (گواهی شما + گواهی(های) میانی) استفاده می‌کنید، نه فقط example.com.crt. ترتیب باید این باشد: اول گواهی سایت، بعد گواهی(های) میانی. در صورت نیاز فایل زنجیره‌شده را دوباره بسازید:

cat example.com.crt intermediate.crt > example.com.chained.crt

ssl_certificate را به example.com.chained.crt اشاره دهید و Nginx را ریلود کنید.

راه‌حل برای Apache: SSLCertificateFile را روی گواهی سایت و SSLCACertificateFile را روی فایل میانی تنظیم کنید. برخی راه‌اندازی‌ها از SSLCertificateChainFile (منسوخ‌شده در آپاچی‌های جدیدتر) استفاده می‌کنند یا گواهی‌های میانی را در یک فایل منفرد می‌گنجانند؛ به دستورالعمل CA خود عمل کنید.

خطای «SSL: wrong version number» یا «rx record too long»

علت: کلاینت به پورت اشتباه می‌خورد (مثلاً HTTP روی ۴۴۳) یا سرور روی ۴۴۳ TLS صحبت نمی‌کند.

راه‌حل: تأیید کنید وب‌سرور روی ۴۴۳ گوش می‌دهد و listen 443 ssl (برای Nginx) یا <VirtualHost *:443> همراه با SSLEngine on (برای Apache) در هاست مجازی درست قرار دارد.

عدم تطابق کلید خصوصی و گواهی

علت: گواهی برای کلیدی غیر از کلید موجود در ssl_certificate_key یا SSLCertificateKeyFile صادر شده. سرورها راه‌اندازی نمی‌شوند یا هندشیک‌های TLS شکست می‌خورند.

راه‌حل: بررسی کنید که Modulus کلید و گواهی مطابقت دارند:

openssl x509 -noout -modulus -in example.com.crt | openssl sha256
openssl rsa -noout -modulus -in example.com.key | openssl sha256

دو هش باید یکسان باشند. اگر نیستند، از کلیدی استفاده کنید که برای تولید CSR ارسالی به CA به کار رفته بود.

Nginx یا Apache بعد از تغییر پیکربندی راه‌اندازی نمی‌شود

علت: خطای سینتکس، مسیر اشتباه به گواهی/کلید، یا فایل میانی مفقود.

راه‌حل: sudo nginx -t (برای Nginx) یا sudo apachectl configtest (برای Apache) را اجرا و خطاهای گزارش‌شده را رفع کنید. مطمئن شوید مسیرهای فایل درست‌اند و کاربر وب‌سرور می‌تواند فایل‌های گواهی و کلید را بخواند (و اینکه کلید برای همه قابل خواندن نیست).

تمدید و مدیریت گواهی‌های تجاری

گواهی‌های تجاری معمولاً اعتبار ۱ یا ۲ ساله دارند. قبل از انقضا برای تمدید برنامه‌ریزی کنید تا از قطعی جلوگیری شود.

یک یادآور تنظیم کنید (مثلاً ۳۰ تا ۶۰ روز قبل از انقضا). بسیاری از CAها یادآورهای ایمیلی می‌فرستند؛ به آن‌ها به‌تنهایی تکیه نکنید.
یک CSR جدید (و ترجیحاً یک کلید خصوصی جدید) با همان مراحل صدور اولیه تولید کنید. برخی CAها اجازه استفاده مجدد از کلید موجود را می‌دهند؛ اما چرخش کلید هنگام تمدید، یک بهترین روش رایج است و ریسک را در صورتی که کلیدی هرگز افشا شده باشد کاهش می‌دهد.
CSR را به CA بفرستید، اعتبارسنجی را کامل کنید و گواهی جدید و گواهی(های) میانی را دریافت کنید.
گواهی جدید (و زنجیره) را روی سرور نصب و Nginx یا Apache را ریلود کنید. گواهی قدیمی را تا تأیید کارکرد گواهی جدید در دسترس نگه دارید.
با openssl s_client یا مرورگر طبق بالا تأیید کنید.
کلیدهای خصوصی و گواهی‌ها را در مکانی امن و محدود ذخیره کنید (مثلاً /etc/ssl/private با خواندن فقط برای root). برای راه‌اندازی‌های متوازن‌بار یا چندسروری، همان گواهی و کلید را روی هر نود دیپلوی کنید یا از یک مخزن اسرار مرکزی استفاده کنید.

سوالات متداول

گواهی SSL تجاری چیست؟

گواهی تجاری SSL/TLS گواهی‌ای است که از یک مرجع صدور گواهی (CA) یا فروشنده مجدد مورد اعتماد می‌خرید. توسط ریشه یا گواهی میانیِ CA امضا شده؛ پس مرورگرها و سیستم‌عامل‌هایی که به آن CA اعتماد دارند، به سایت شما اعتماد می‌کنند. گواهی‌های تجاری اغلب اعتبار طولانی‌تری (۱ تا ۲ سال) دارند و ممکن است شامل قابلیت‌های فروشنده مانند SLA پشتیبانی، صدور مجدد مدیریت‌شده، شرایط ضمانت/قرارداد یا بررسی سازمانی باشند.

چه زمانی باید به‌جای Let’s Encrypt از گواهی SSL پولی استفاده کنم؟

وقتی از گواهی تجاری استفاده کنید که به اعتبار طولانی‌تر بدون خودکارسازی مکرر تمدید نیاز دارید، تأیید سازمانی برای دلایل سیاست داخلی/انطباقی لازم دارید یا به قابلیت‌های CA/فروشنده مانند صدور مجدد مدیریت‌شده، SLA پشتیبانی یا شرایط خاص ضمانت/قرارداد نیاز دارید. Let’s Encrypt هم گواهی چنددامنه‌ای و هم وایلدکارت را پشتیبانی می‌کند (معمولاً از طریق اعتبارسنجی DNS)؛ پس تصمیم معمولاً درباره محدودیت‌های تمدید/خودکارسازی، الزامات انطباق یا قابلیت‌های فروشنده است، نه توانایی فنی.

چه اطلاعاتی برای تولید CSR لازم است؟

نیاز دارید به: Common Name (CN)، دامنه دقیق (مثلاً example.com، www.example.com یا *.example.com برای وایلدکارت). برای OV/EV، CA از فیلدهای Organization، Locality، State، Country در CSR برای اعتبارسنجی سازمان‌تان هم استفاده می‌کند. اختیاری: ایمیل، واحد سازمانی. رمز چالش لازم نیست.

تفاوت کلید خصوصی و گواهی چیست؟

کلید خصوصی، رازی است که تولید و روی سرور نگه می‌دارید؛ برای رمزگشایی ترافیک و اثبات مالکیت گواهی استفاده می‌شود. گواهی، سند عمومیِ امضاشده توسط CA است که دامنه شما (و در صورت تمایل سازمان) را به آن کلید عمومی متصل می‌کند. شما یک CSR (که شامل کلید عمومی است، نه کلید خصوصی) به CA می‌فرستید؛ آن‌ها گواهی را برمی‌گردانند. هرگز کلید خصوصی را به اشتراک نگذارید یا آپلود نکنید.

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

گواهی‌های میانی، گواهی‌های صادرشده توسط CA هستند که گواهی سایت شما را به یک CA ریشه مورد اعتماد مرورگرها متصل می‌کنند. مرورگرها فقط ریشه‌ها را ذخیره می‌کنند؛ آن‌ها به گواهی(های) میانی نیاز دارند تا زنجیره‌ای از گواهی شما به یک ریشه مورد اعتماد بسازند. اگر گواهی‌های میانی را سرو نکنید، زنجیره ناقص است و مرورگرها ممکن است «Certificate not trusted» نشان بدهند.

چطور گواهی SSL را روی Nginx نصب کنم؟

فایل زنجیره‌شده بسازید: cat example.com.crt intermediate.crt > example.com.chained.crt. در بلاک سرور Nginx برای پورت ۴۴۳، ssl_certificate را به فایل زنجیره‌شده و ssl_certificate_key را به کلید خصوصی تنظیم کنید. از ssl_protocols TLSv1.2 TLSv1.3; و رمزنگاری‌های قوی استفاده کنید، سپس Nginx را ریلود کنید. برای جزئیات کامل، گام ۵ بالا را ببینید.

چطور گواهی SSL را روی Apache نصب کنم؟

ماژول SSL را فعال کنید (sudo a2enmod ssl)، سپس در بلاک <VirtualHost *:443> مقدار SSLEngine on را تنظیم کنید، SSLCertificateFile را به گواهی سایت، SSLCertificateKeyFile را به کلید و SSLCACertificateFile را به گواهی میانی تنظیم کنید. آپاچی را ری‌استارت کنید. برای جزئیات کامل، گام ۵ بالا را ببینید.

چطور تأیید کنم گواهی SSL من درست نصب شده؟

از openssl s_client -connect example.com:443 -servername example.com استفاده کنید و Verify return code: 0 (ok) را بررسی کنید. در مرورگر، https://example.com را باز کنید، روی قفل کلیک کنید و تأیید کنید زنجیره گواهی کامل است و دوره اعتبار درست است.

چه چیزی باعث خطاهای اعتماد گواهی SSL در مرورگرها می‌شود؟

علل رایج: گواهی‌های میانی مفقود یا با ترتیب اشتباه؛ گواهی منقضی یا هنوز معتبر نشده؛ عدم تطابق نام هاست (مثلاً گواهی برای www.example.com است ولی شما example.com را باز کرده‌اید)؛ یا گواهی برای کلیدی غیر از کلید پیکربندی‌شده صادر شده. با سرو کردن کل زنجیره، اصلاح جفت کلید/گواهی و اطمینان از تطابق Common Name یا SAN گواهی با هاستی که بازدید می‌کنید، رفع کنید.

نتیجه‌گیری

حالا می‌دانید چگونه یک CA تجاری انتخاب کنید، CSR و کلید خصوصی تولید کنید، گواهی SSL/TLS را روی Nginx یا Apache دریافت و نصب کنید، نصب را تأیید کنید و مشکلات رایج زنجیره و کلید را عیب‌یابی کنید. نگه‌داشتن کامل زنجیره گواهی و امن نگه‌داشتن کلید خصوصی، برای اعتماد مرورگر و قابلیت اطمینان پروداکشن ضروری است.