امنیت ارتباطات در دنیای وب امروز اهمیت بسیار بالایی دارد. برای رمزنگاری دادهها و ایجاد یک کانال امن بین کاربر و سرور، استفاده از گواهیهای SSL/TLS ضروری است. اما همیشه نیازی به خرید گواهی معتبر از مراجع صدور (CA) وجود ندارد. در بسیاری از مواقع مانند توسعه محلی (Local Development)، محیطهای آزمایشی (Staging) و شبکههای داخلی، میتوان از گواهیهای Self-Signed استفاده کرد. این گواهیها بدون نیاز به پرداخت هزینه صادر میشوند و برای اهداف آموزشی یا تستی بهترین گزینه محسوب میگردند. در این مقاله از بلاگ وبداده قصد داریم به صورت گامبهگام و عملی آموزش ایجاد گواهی Self-Signed SSL با ابزار OpenSSL را ارائه دهیم. همچنین نحوه نصب آن روی وبسرورها، رفع مشکلات امنیتی و مدیریت گواهیها را بررسی خواهیم کرد.
یک گواهی Self-Signed در واقع توسط خودِ سرور ساخته و امضا میشود، نه یک مرکز معتبر صدور گواهی (CA). به زبان ساده یعنی سرور خودش میگوید «من معتبرم» و هیچ مرجع بیرونی آن را تأیید نمیکند. برای همین وقتی چنین گواهی روی سایتی استفاده شود، مرورگرها معمولاً هشدار میدهند که اتصال امن نیست. این موضوع برای کاربران عادی به این معناست که صفحه وب همچنان رمزنگاری شده اما مرورگر نمیتواند صحت هویت سایت را تضمین کند. بنابراین Self-Signed بیشتر برای تست و استفاده داخلی مناسب است و برای وبسایتهای عمومی پیشنهاد نمیشود.
گواهی Self-Signed چیست و چه کاربردی دارد؟
این بخش توضیح میدهد که گواهی Self-Signed چگونه کار میکند و چرا برای برخی کاربردها مفید است. گواهیهای Self-Signed به مدیران سرور اجازه میدهند بدون نیاز به خرید از مراجع معتبر، ارتباطات را رمزنگاری کنند. این گواهیها در محیطهای تست، شبکههای داخلی و توسعه محلی کاربرد دارند و میتوانند امنیت پایهای را فراهم سازند. با وجود هشدار مرورگرها، استفاده از آنها برای پروژههای غیرعمومی یا آزمایشی بسیار متداول است. در ادامه تفاوتها، مزایا و معایب این نوع گواهی را بررسی میکنیم.
تفاوت گواهی Self-Signed با گواهیهای صادرشده توسط CA
گواهیهای Self-Signed همانطور که از نامشان پیداست توسط خود سرور ساخته میشوند و هیچ نهاد بیرونی آنها را تأیید نمیکند. در مقابل، گواهیهای CA توسط مراجع معتبر بینالمللی صادر میشوند و مرورگرها به صورت پیشفرض آنها را قابل اعتماد میدانند. این تفاوت باعث میشود Self-Signed بیشتر برای تست و محیط داخلی مناسب باشد، در حالی که گواهیهای CA انتخابی الزامی برای وبسایتهای عمومی و سرویسهای اینترنتی هستند.
گواهی Self-Signed: رایگان، سریع و برای تست.
گواهی CA: معتبر، قابل اعتماد در مرورگرها و مناسب محیط عملیاتی.
مزایای استفاده از گواهی Self-Signed
بدون هزینه
نصب سریع
مناسب برای محیطهای توسعه و آزمایش
معایب رمزنگاری داخلی با Self-Signed
عدم اعتماد مرورگرها
نمایش هشدار امنیتی
مناسب نبودن برای وبسایتهای عمومی
پیشنیازها برای ایجاد دستی گواهی SSL
قبل از شروع مراحل، باید ابزار OpenSSL روی سیستم شما نصب باشد. این ابزار معمولاً به صورت پیشفرض روی بسیاری از توزیعهای لینوکسی وجود دارد، اما در سرورهای ویندوزی ممکن است لازم باشد آن را جداگانه نصب کنید. کاربران میتوانند OpenSSL را از وبسایت رسمی دانلود کنند یا از طریق مخزن بستههای سیستمعامل خود تهیه نمایند. توجه داشته باشید که اجرای دستورات ساخت گواهی نیازمند سطح دسترسی مدیر سیستم (Root در لینوکس یا Administrator در ویندوز) است و کاربران عادی در هاستهای اشتراکی معمولاً چنین سطح دسترسیای ندارند. بنابراین این آموزش بیشتر برای مدیران سرور و کسانی که دسترسی کامل به سرور دارند کاربردی خواهد بود.
نصب OpenSSL در لینوکس
برای نصب و استفاده از OpenSSL در لینوکس باید ابتدا بررسی کنید که آیا این ابزار روی سیستم شما نصب است یا خیر. در اکثر توزیعهای لینوکسی مانند Ubuntu و Debian به صورت پیشفرض وجود دارد، اما اگر نصب نبود میتوانید بهسادگی آن را اضافه کنید. کافی است با دسترسی Root دستور زیر را اجرا کنید که مخصوص همین کار است.
Copy
sudoaptupdatesudoaptinstallopenssl-y
نصب OpenSSL در ویندوز
دانلود از وبسایت رسمی OpenSSL
افزودن مسیر باینری به Environment Variables (برای این کار باید پوشهای که فایلهای اجرایی OpenSSL در آن قرار دارد، مثلاً C:\OpenSSL-Win64\bin، به مسیر سیستم اضافه شود. در ویندوز میتوانید با رفتن به Control Panel > System > Advanced system settings > Environment Variables، گزینه Path را ویرایش کرده و مسیر مذکور را اضافه کنید تا بتوانید دستور openssl را از هر مسیر خط فرمان اجرا کنید.)
ابزار جایگزین برای ایجاد گواهی در سال 2025
🛠 mkcert: یک ابزار متنباز و بسیار ساده است که مخصوص توسعهدهندگان طراحی شده تا بتوانند در محیط محلی (Localhost) گواهیهای SSL معتبر ایجاد کنند. این ابزار بهطور خودکار یک مرجع صدور محلی (Local CA) روی سیستم شما نصب میکند و سپس هر بار که نیاز داشته باشید گواهی معتبر برای دامنهها یا آیپیهای محلی تولید مینماید. نتیجه این است که مرورگرها بدون نمایش هشدار امنیتی، اتصال HTTPS را برای پروژههای توسعهای شما معتبر میشناسند.
ایجاد کلید خصوصی (Private Key)
کلید خصوصی، پایه اصلی امنیت SSL است و در واقع همان فایل رمزنگاریشدهای است که تمام گواهی بر اساس آن ساخته میشود. این کلید برای رمزگذاری و رمزگشایی اطلاعات بین سرور و کاربر بهکار میرود و بدون آن گواهی SSL عملاً هیچ اعتباری ندارد. زمانی که شما یک کلید خصوصی تولید میکنید، باید آن را در مسیر امنی نگهداری کنید و اجازه دسترسی فقط به مدیر سرور داده شود. اگر این کلید به دست فرد دیگری بیفتد، امنیت ارتباطات بهطور کامل از بین خواهد رفت. بنابراین اهمیت دارد که سطح دسترسی آن محدود به Root یا Administrator باشد و کاربران عادی به هیچ عنوان به این فایل دسترسی نداشته باشند.
ایجاد کلید RSA 2048 بیت
در این مرحله کلیدی با طول 2048 بیت ساخته میشود زیرا این اندازه تعادل مناسبی بین امنیت و کارایی دارد. کلیدهای کوتاهتر (مانند 1024 بیت) در سالهای اخیر ناامن محسوب میشوند و کلیدهای بزرگتر (مانند 4096 بیت) اگرچه امنیت بیشتری دارند اما میتوانند سرعت پردازش را کاهش دهند. به همین دلیل RSA 2048 بیت استانداردی پذیرفتهشده در بیشتر سرورها و مرورگرها است و برای محیطهای تستی و عملیاتی امنیت کافی را فراهم میکند
Copy
opensslgenrsa-outserver.key2048
ایجاد کلید ECDSA
کلید ECDSA برای استفاده از الگوریتم بیضوی (Elliptic Curve Digital Signature Algorithm) ایجاد میشود. این نوع کلید نسبت به RSA با طول کمتر امنیت بالاتری فراهم میکند و در عین حال سرعت بیشتری در پردازش دارد. به همین دلیل در سالهای اخیر استفاده از آن بهخصوص در محیطهایی که کارایی مهم است (مثل سرورهای با ترافیک بالا یا دستگاههای کمقدرت) توصیه میشود. ایجاد این کلید نیز مشابه RSA است و با دستور زیر انجام میگیرد:
Copy
opensslecparam-genkey-namesecp384r1-outserver.key
📌 نکته امنیتی: کلید خصوصی باید بهطور امن ذخیره شود و دسترسی فقط برای مدیر سرور امکانپذیر باشد.
ایجاد درخواست امضای گواهی (CSR) و تنظیم SAN
CSR یا همان Certificate Signing Request یک فایل متنی است که هنگام ایجاد گواهی ساخته میشود و شامل اطلاعات مهمی درباره سازمان یا دامنه شما است. در این فایل مشخصات کلیدی مانند نام دامنه (Common Name)، کشور، استان یا شهر، نام سازمان و همچنین کلید عمومی قرار دارد. مرورگرها و مراجع صدور گواهی (CA) از این اطلاعات برای شناسایی و صدور گواهی استفاده میکنند. حتی در گواهیهای Self-Signed نیز CSR نقش حیاتی دارد زیرا ساختار گواهی نهایی را تعریف میکند و تعیین میکند این گواهی به چه دامنه یا سروری تعلق دارد.
ایجاد فایل CSR
ایجاد فایل CSR مرحلهای کلیدی در فرآیند ساخت گواهی SSL است. این فایل در واقع درخواست رسمی شما برای صدور یا ایجاد گواهی محسوب میشود و تمام اطلاعات هویتی سرور را در خود دارد. با ساخت CSR، شما مشخص میکنید گواهی به کدام دامنه یا آدرس IP تعلق دارد و چه مشخصاتی باید روی آن درج شود. در گواهیهای Self-Signed نیز این مرحله اهمیت زیادی دارد، زیرا ساختار نهایی گواهی بر اساس همین درخواست شکل میگیرد و مرورگرها و سیستمها با استفاده از اطلاعات موجود در آن، گواهی را تحلیل میکنند.
Copy
opensslreq-new-keyserver.key-outserver.csr
وارد کردن اطلاعات مهم
وقتی دستور بالا را اجرا میکنید، این فیلدها از شما پرسیده میشوند. میتوانید آنها را حین اجرا بهصورت تعاملی وارد کنید یا با پارامترهای خط فرمان/فایل کانفیگ از قبل تعیینشان کنید.
Country Name (کد کشور): کد دوحرفی (مثل IR، US).
State/Province و Locality: استان/شهر بهصورت متنی.
Common Name (CN): نام اصلی هاست (Domain یا FQDN). برای تست میتواند localhost یا دامنه داخلی باشد.
Subject Alternative Name (SAN): مهمترین بخش در مرورگرهای مدرن؛ باید تمام دامنهها و IPهایی که قرار است به این گواهی وصل شوند را پوشش دهد (مثلاً example.local، api.example.local، 127.0.0.1، ::1). اگر SAN ناقص باشد، خطای SAN mismatch میگیرید.
💡 SAN دقیقاً چیست و از کجا تهیه کنیم؟ SAN لیستی از نامها و آدرسهایی است که گواهی برای آنها معتبر است. این لیست را از نقاط دسترسی واقعی کلاینتها استخراج کنید: همه دامنههایی که روی سرور مپ شدهاند، آدرسهای IP داخلی که تیمتان استفاده میکند، و موارد رایج توسعه مانند localhost/127.0.0.1/::1. هر آنچه کلاینت به آن متصل میشود، باید در SAN باشد.
ایجاد فایل CSR بدون پرسشهای تعاملی
میتوانید این مقادیر را بهجای وارد کردن دستی، مستقیماً داخل همان دستور قرار دهید تا بدون پرسش تعاملی ساخته شوند، مانند دستور زیر:
نکته: -addext در نسخههای جدید OpenSSL در دسترس است. در نسخههای قدیمیتر، از فایل کانفیگ استفاده کنید.
روش فایل کانفیگ برای SAN (سازگار با همه نسخهها)
یک فایل به نام openssl.cnf بسازید و بخشهای زیر را اضافه کنید. این کار باید در محیطی انجام شود که به خط فرمان و دسترسی روت یا ادمین دارید، معمولاً روی سرور لینوکس یا ماشین توسعه محلی. در هاستهای اشتراکی امکان انجام این کار محدود است و توصیه میشود در VPS یا سرور اختصاصی و یا حتی روی سیستم شخصی برای تست انجام شود:
👈 جمعبندی کاربردی: اگر سرعت کار مدنظر است و OpenSSL شما جدید است، از -subj و -addext استفاده کنید. اگر میخواهید سازگار و قابل تکرار باشد، از فایل openssl.cnf بهره ببرید. SAN را بر اساس تمام نامها/IPهایی که واقعاً استفاده میکنید تنظیم کنید تا خطای اعتماد/عدم تطابق رخ ندهد.
برای اینکه گواهی Self-Signed شما کاربردی شود، باید آن را روی وبسرور پیکربندی کنید تا ارتباطات HTTPS فعال گردد. این مرحله شامل معرفی مسیر فایل گواهی (.crt) و کلید خصوصی (.key) به تنظیمات سرور است. بسته به نوع وبسرور (مثل Apache یا Nginx) شیوه نصب متفاوت خواهد بود، اما در همه موارد باید دسترسی مدیریتی به سرور داشته باشید و پس از تغییرات، سرویس وبسرور را ریلود یا ریاستارت کنید.
برای اینکه مرورگرها و سیستمعاملها بتوانند به گواهی Self-Signed شما اعتماد کنند، باید آن را به بخش Trusted Root Store اضافه کنید. این کار باعث میشود خطاهای امنیتی مثل “Your connection is not private” نمایش داده نشود و ارتباط HTTPS در محیط تست یا شبکه داخلی بدون مشکل برقرار گردد.
ویندوز
اجرای mmc
افزودن Snap-in Certificates
Import کردن گواهی در بخش Trusted Root Certification Authorities
برای اینکه گواهیهای Self-Signed همیشه قابل استفاده بمانند، باید بهصورت منظم تاریخ انقضای آنها را بررسی و در صورت نیاز تمدید کنید. این بخش توضیح میدهد چگونه وضعیت گواهی را کنترل کنید، قبل از انقضا نسخه جدید ایجاد نمایید و جایگزین گواهیهای قدیمی کنید. همچنین نکات امنیتی برای نگهداری کلیدها و جلوگیری از مشکلات احتمالی مرورگر یا کاربران در زمان استفاده از گواهیهای تمدیدشده بیان میشود.
بررسی تاریخ انقضا Self-Signed
Copy
opensslx509-enddate-noout-inserver.crt
تمدید گواهی Self-Signed
تولید مجدد گواهی با همان کلید خصوصی
جایگزین کردن فایلهای قدیمی
📌 تولید مجدد گواهی با همان کلید خصوصی. 📌 جایگزین کردن فایلهای قدیمی.
خطاهای رایج و رفع مشکلات در گواهیهای Self-Signed
در هنگام ایجاد یا استفاده از گواهیهای Self-Signed معمولاً با خطاهای مختلفی روبهرو میشوید. این خطاها بیشتر به دلیل اعتماد نکردن مرورگرها، عدم پیکربندی صحیح SAN، یا مسیرهای اشتباه فایلها اتفاق میافتند. دانستن علت این خطاها و روشهای رفع آنها کمک میکند تا در محیط تستی یا داخلی بدون دردسر از HTTPS استفاده کنید و مشکلات امنیتی یا هشدارهای آزاردهنده مرورگرها را برطرف نمایید.
خطای “Your connection is not private”
علت: اعتماد نکردن مرورگر
راهحل: اضافه کردن گواهی به Root Store
خطای SAN mismatch
علت: عدم تعریف SAN
راهحل: افزودن SAN به CSR
خطای مسیر فایلها
علت: تنظیم اشتباه مسیر در Apache/Nginx
راهحل: بررسی مسیر و مجوز فایلها
جایگزینهای Self-Signed در 2025
Let’s Encrypt: صدور رایگان و معتبر
ZeroSSL: جایگزین رایگان با قابلیت تمدید خودکار
mkcert: مخصوص محیط توسعه
نتیجهگیری:ایجاد دستی گواهی SSL
گواهیهای Self-Signed راهکاری سریع و بدون هزینه برای ایجاد ارتباط امن در محیطهای تستی، آزمایشگاهی و توسعه داخلی هستند. با استفاده از ابزار OpenSSL میتوان در چند دقیقه کلید خصوصی، CSR و گواهی SSL را تولید و روی وبسرورهای محبوب مانند Apache و Nginx نصب کرد. هرچند این گواهیها توسط مرورگرها بهطور پیشفرض معتبر شناخته نمیشوند، اما با افزودن آنها به Trusted Root Store سیستم یا مرورگر میتوان این مشکل را برطرف کرد. باید توجه داشت که استفاده از گواهی Self-Signed در محیطهای عملیاتی یا وبسایتهای عمومی توصیه نمیشود و بهترین انتخاب در این شرایط، استفاده از گواهیهای رایگان و معتبر مانند Let’s Encrypt است. در نهایت، این آموزش از بلاگ وبداده به شما کمک میکند تا درک بهتری از زیرساخت SSL داشته باشید و امنیت اولیه سرورهای داخلی خود را تامین کنید.
سوالات متداول از ایجاد دستی گواهی مشترک سرور self-signed
1- آیا میتوان از گواهی Self-Signed برای وبسایت عمومی استفاده کرد؟
خیر، مرورگرها به آن اعتماد نمیکنند و همیشه هشدار امنیتی نشان میدهند. برای وبسایت عمومی باید از گواهیهای معتبر CA استفاده شود.
2- چگونه میتوان خطای “Your connection is not private” را رفع کرد؟
با افزودن گواهی Self-Signed به Trusted Root Store سیستمعامل یا مرورگر.
3- مدت اعتبار پیشفرض یک گواهی Self-Signed چقدر است؟
معمولاً 365 روز، اما میتوان هنگام ساخت آن را افزایش داد (مثلاً 825 روز).
4- اگر کلید خصوصی لو برود چه اتفاقی میافتد؟
امنیت ارتباطات از بین میرود و باید سریعاً کلید و گواهی جدید تولید کنید.
5- چه جایگزینهای رایگانی برای Self-Signed وجود دارد؟
Let’s Encrypt و ZeroSSL که توسط مرورگرها معتبر شناخته میشوند و قابلیت تمدید خودکار دارند.
من نویسنده و تولیدکننده محتوای تخصصی در حوزه هاستینگ هستم که با تمرکز بر کپیرایتینگ و ارائه آموزشهای کاربردی، به ارتقای دانش و مهارت کاربران کمک میکنم. سالهاست که در زمینه هاستینگ و شبکه فعالیت میکنم و همواره تلاش دارم با بهروزرسانی اطلاعات خود، بهترین و مفیدترین مطالب را برای مخاطبان ارائه دهم.