امنیت ارتباطات در دنیای وب امروز اهمیت بسیار بالایی دارد. برای رمزنگاری داده‌ها و ایجاد یک کانال امن بین کاربر و سرور، استفاده از گواهی‌های SSL/TLS ضروری است. اما همیشه نیازی به خرید گواهی معتبر از مراجع صدور (CA) وجود ندارد. در بسیاری از مواقع مانند توسعه محلی (Local Development)، محیط‌های آزمایشی (Staging) و شبکه‌های داخلی، می‌توان از گواهی‌های Self-Signed استفاده کرد. این گواهی‌ها بدون نیاز به پرداخت هزینه صادر می‌شوند و برای اهداف آموزشی یا تستی بهترین گزینه محسوب می‌گردند. در این مقاله از بلاگ وب‌داده قصد داریم به صورت گام‌به‌گام و عملی آموزش ایجاد گواهی Self-Signed SSL با ابزار OpenSSL را ارائه دهیم. همچنین نحوه نصب آن روی وب‌سرورها، رفع مشکلات امنیتی و مدیریت گواهی‌ها را بررسی خواهیم کرد.

💡 پیش‌نیازهای لازم برای ایجاد گواهی Self-Signed:

  • دسترسی به یک سرور لینوکس یا ویندوز
  • نصب بودن ابزار OpenSSL یا ابزار مشابه
  • دسترسی مدیر (Root یا Administrator)
  • آشنایی اولیه با خط فرمان (CLI)
  • داشتن نام دامنه یا IP برای تست

آنچه در این مقاله می‌خوانید:

💡 گواهی Self-Signed چیست؟

یک گواهی 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 دستور زیر را اجرا کنید که مخصوص همین کار است.
sudo apt update
sudo apt install openssl -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 بیت استانداردی پذیرفته‌شده در بیشتر سرورها و مرورگرها است و برای محیط‌های تستی و عملیاتی امنیت کافی را فراهم می‌کند

openssl genrsa -out server.key 2048

ایجاد کلید ECDSA

کلید ECDSA برای استفاده از الگوریتم بیضوی (Elliptic Curve Digital Signature Algorithm) ایجاد می‌شود. این نوع کلید نسبت به RSA با طول کمتر امنیت بالاتری فراهم می‌کند و در عین حال سرعت بیشتری در پردازش دارد. به همین دلیل در سال‌های اخیر استفاده از آن به‌خصوص در محیط‌هایی که کارایی مهم است (مثل سرورهای با ترافیک بالا یا دستگاه‌های کم‌قدرت) توصیه می‌شود. ایجاد این کلید نیز مشابه RSA است و با دستور زیر انجام می‌گیرد:
openssl ecparam -genkey -name secp384r1 -out server.key
📌 نکته امنیتی: کلید خصوصی باید به‌طور امن ذخیره شود و دسترسی فقط برای مدیر سرور امکان‌پذیر باشد.

ایجاد درخواست امضای گواهی (CSR) و تنظیم SAN

CSR یا همان Certificate Signing Request یک فایل متنی است که هنگام ایجاد گواهی ساخته می‌شود و شامل اطلاعات مهمی درباره سازمان یا دامنه شما است. در این فایل مشخصات کلیدی مانند نام دامنه (Common Name)، کشور، استان یا شهر، نام سازمان و همچنین کلید عمومی قرار دارد. مرورگرها و مراجع صدور گواهی (CA) از این اطلاعات برای شناسایی و صدور گواهی استفاده می‌کنند. حتی در گواهی‌های Self-Signed نیز CSR نقش حیاتی دارد زیرا ساختار گواهی نهایی را تعریف می‌کند و تعیین می‌کند این گواهی به چه دامنه یا سروری تعلق دارد.

ایجاد فایل CSR

ایجاد فایل CSR مرحله‌ای کلیدی در فرآیند ساخت گواهی SSL است. این فایل در واقع درخواست رسمی شما برای صدور یا ایجاد گواهی محسوب می‌شود و تمام اطلاعات هویتی سرور را در خود دارد. با ساخت CSR، شما مشخص می‌کنید گواهی به کدام دامنه یا آدرس IP تعلق دارد و چه مشخصاتی باید روی آن درج شود. در گواهی‌های Self-Signed نیز این مرحله اهمیت زیادی دارد، زیرا ساختار نهایی گواهی بر اساس همین درخواست شکل می‌گیرد و مرورگرها و سیستم‌ها با استفاده از اطلاعات موجود در آن، گواهی را تحلیل می‌کنند.
openssl req -new -key server.key -out server.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 بدون پرسش‌های تعاملی

می‌توانید این مقادیر را به‌جای وارد کردن دستی، مستقیماً داخل همان دستور قرار دهید تا بدون پرسش تعاملی ساخته شوند، مانند دستور زیر:
openssl req -new -key server.key -out server.csr \
  -subj "/C=IR/ST=Tehran/L=Tehran/O=companyname/CN=example.local" \
  -addext "subjectAltName=DNS:example.local,DNS:api.example.local,IP:127.0.0.1,IP:::1"
نکته: -addext در نسخه‌های جدید OpenSSL در دسترس است. در نسخه‌های قدیمی‌تر، از فایل کانفیگ استفاده کنید.

روش فایل کانفیگ برای SAN (سازگار با همه نسخه‌ها)

یک فایل به نام openssl.cnf بسازید و بخش‌های زیر را اضافه کنید. این کار باید در محیطی انجام شود که به خط فرمان و دسترسی روت یا ادمین دارید، معمولاً روی سرور لینوکس یا ماشین توسعه محلی. در هاست‌های اشتراکی امکان انجام این کار محدود است و توصیه می‌شود در VPS یا سرور اختصاصی و یا حتی روی سیستم شخصی برای تست انجام شود:
[ req ]
distinguished_name = dn
req_extensions     = v3_req
prompt             = no

[ dn ]
C  = IR
ST = Isfahan
L  = Isfahan
O  = Webdade
CN = example.local

[ v3_req ]
subjectAltName = @alt_names

[ alt_names ]
DNS.1 = example.local
DNS.2 = api.example.local
IP.1  = 127.0.0.1
IP.2  = ::1
سپس دستور را با اشاره به فایل کانفیگ اجرا کنید:
openssl req -new -key server.key -out server.csr \
  -config openssl.cnf -extensions v3_req
👈 جمع‌بندی کاربردی:
اگر سرعت کار مدنظر است و OpenSSL شما جدید است، از -subj و -addext استفاده کنید.
اگر می‌خواهید سازگار و قابل تکرار باشد، از فایل openssl.cnf بهره ببرید.
SAN را بر اساس تمام نام‌ها/IPهایی که واقعاً استفاده می‌کنید تنظیم کنید تا خطای اعتماد/عدم تطابق رخ ندهد.

ایجاد گواهی Self-Signed با OpenSSL

برای ایجاد گواهی 365 روزه:
openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
برای گواهی با مدت اعتبار بیشتر:
openssl x509 -req -days 825 -in server.csr -signkey server.key -out server.crt

نصب گواهی Self-Signed روی وب‌سرورها

برای اینکه گواهی Self-Signed شما کاربردی شود، باید آن را روی وب‌سرور پیکربندی کنید تا ارتباطات HTTPS فعال گردد. این مرحله شامل معرفی مسیر فایل گواهی (.crt) و کلید خصوصی (.key) به تنظیمات سرور است. بسته به نوع وب‌سرور (مثل Apache یا Nginx) شیوه نصب متفاوت خواهد بود، اما در همه موارد باید دسترسی مدیریتی به سرور داشته باشید و پس از تغییرات، سرویس وب‌سرور را ری‌لود یا ری‌استارت کنید.

نصب Self-Signed در Apache

<VirtualHost *:443>
    ServerName example.com
    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/server.crt
    SSLCertificateKeyFile /etc/ssl/private/server.key
</VirtualHost>
فعال‌سازی ماژول SSL:
a2enmod ssl
systemctl reload apache2

نصب Self-Signed در Nginx

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate /etc/ssl/certs/server.crt;
    ssl_certificate_key /etc/ssl/private/server.key;
}
ری‌لود سرویس:
nginx -s reload

اضافه کردن گواهی به Trusted Root Store

برای اینکه مرورگرها و سیستم‌عامل‌ها بتوانند به گواهی Self-Signed شما اعتماد کنند، باید آن را به بخش Trusted Root Store اضافه کنید. این کار باعث می‌شود خطاهای امنیتی مثل “Your connection is not private” نمایش داده نشود و ارتباط HTTPS در محیط تست یا شبکه داخلی بدون مشکل برقرار گردد.

ویندوز

  • اجرای mmc
  • افزودن Snap-in Certificates
  • Import کردن گواهی در بخش Trusted Root Certification Authorities

لینوکس

sudo cp server.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates

macOS

  • باز کردن Keychain Access
  • Import کردن گواهی به System Roots

مرورگرها

  • در Chrome/Firefox امکان Import دستی وجود دارد.

مدیریت و تمدید گواهی Self-Signed

برای اینکه گواهی‌های Self-Signed همیشه قابل استفاده بمانند، باید به‌صورت منظم تاریخ انقضای آن‌ها را بررسی و در صورت نیاز تمدید کنید. این بخش توضیح می‌دهد چگونه وضعیت گواهی را کنترل کنید، قبل از انقضا نسخه جدید ایجاد نمایید و جایگزین گواهی‌های قدیمی کنید. همچنین نکات امنیتی برای نگهداری کلیدها و جلوگیری از مشکلات احتمالی مرورگر یا کاربران در زمان استفاده از گواهی‌های تمدیدشده بیان می‌شود.

بررسی تاریخ انقضا Self-Signed

openssl x509 -enddate -noout -in server.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: مخصوص محیط توسعه
گواهی Self-Signed
ایجاد دستی گواهی SSL

نتیجه‌گیری:‌ایجاد دستی گواهی SSL

گواهی‌های Self-Signed راهکاری سریع و بدون هزینه برای ایجاد ارتباط امن در محیط‌های تستی، آزمایشگاهی و توسعه داخلی هستند. با استفاده از ابزار OpenSSL می‌توان در چند دقیقه کلید خصوصی، CSR و گواهی SSL را تولید و روی وب‌سرورهای محبوب مانند Apache و Nginx نصب کرد. هرچند این گواهی‌ها توسط مرورگرها به‌طور پیش‌فرض معتبر شناخته نمی‌شوند، اما با افزودن آن‌ها به Trusted Root Store سیستم یا مرورگر می‌توان این مشکل را برطرف کرد. باید توجه داشت که استفاده از گواهی Self-Signed در محیط‌های عملیاتی یا وب‌سایت‌های عمومی توصیه نمی‌شود و بهترین انتخاب در این شرایط، استفاده از گواهی‌های رایگان و معتبر مانند Let’s Encrypt است. در نهایت، این آموزش از بلاگ وب‌داده به شما کمک می‌کند تا درک بهتری از زیرساخت SSL داشته باشید و امنیت اولیه سرورهای داخلی خود را تامین کنید.

سوالات متداول از ایجاد دستی گواهی مشترک سرور self-signed

1- آیا می‌توان از گواهی Self-Signed برای وب‌سایت عمومی استفاده کرد؟

خیر، مرورگرها به آن اعتماد نمی‌کنند و همیشه هشدار امنیتی نشان می‌دهند. برای وب‌سایت عمومی باید از گواهی‌های معتبر CA استفاده شود.

نرسی مزداب
نرسی مزداب

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

مقاله‌ها: 57
پاسخی بگذارید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *