كيفية إنشاء شهادة موقعة ذاتيًا باستخدام OpenSSL؟

الشهادة ذاتية التوقيع هي شهادة تصدرها لنفسك بدلاً من شرائها من هيئة إصدار شهادات. لن تثق المتصفحات بها تلقائيًا، لذا ليس لها مكان على موقع ويب عام، لكنها الطريقة الأسرع لتفعيل HTTPS على جهاز تطوير، أو خادم تجريبي، أو لوحة تحكم داخلية، أو أي خدمة لا تواجه الإنترنت العام مطلقًا.

يوضح لك هذا الدليل كيفية إنشاء شهادة ذاتية التوقيع باستخدام OpenSSL على Windows وLinux وmacOS. الأمر واحد على الثلاثة جميعًا. ستتعرف أيضًا على كيفية التحقق من أن الشهادة التي أنشأتها قابلة للاستخدام فعليًا، وكيفية جعل جهازك الخاص يثق بها لتختفي تحذيرات المتصفح.

ما هي الشهادة ذاتية التوقيع

الشهادة ذاتية التوقيع هي شهادة رقمية موقّعة بمفتاحها الخاص بدلاً من توقيعها من هيئة إصدار شهادات موثوقة (CA). من الناحية التشفيرية، فهي شهادة X.509 عادية: تُشفّر حركة البيانات تمامًا كما تفعل شهادة مشتراة. ما تفتقر إليه هو سلسلة الثقة. فلا يوجد أي شيء خارج جهازك لديه سبب للثقة بها، لذا تُظهر المتصفحات تحذيرًا حتى تخبرها بخلاف ذلك.

هذا يجعل الشهادات ذاتية التوقيع مناسبة لـ:

• التطوير المحلي، حيث تحتاج إلى HTTPS لكي تتصرف ملفات تعريف الارتباط، أو عمّال الخدمة، أو حزمة تطوير الدفع بنفس الطريقة التي ستتصرف بها في الإنتاج.
• الخدمات الداخلية مثل لوحة تحكم إنترانت، أو لوحة مراقبة، أو واجهة إدارة أجهزة على شبكة خاصة.
• الاختبار والمرحلة التجريبية، حيث تريد تجربة إعداد TLS دون إنفاق شهادة عليه.
• خوادم المصدر الخلفية وراء بروكسي يقبل شهادة غير موثوقة في الوصلة الخلفية، مثل Cloudflare في نمط Full.

وهي أداة خاطئة لأي شيء سيُحمّله زائر حقيقي. نتناول هذا التمييز بالتفصيل أدناه، تحت عنوان متى لا يجب استخدام واحدة.

قبل أن تبدأ: تحقق من OpenSSL

تحتاج إلى أداة سطر الأوامر OpenSSL. تحقق من الإصدار الذي لديك:

openssl version

• Linux: OpenSSL مثبت مسبقًا على أغلب التوزيعات. إذا لم يكن مثبتًا، راجع دليلنا حول كيفية تثبيت OpenSSL على Ubuntu.
• Windows: OpenSSL غير مضمّن. اتبع تعليماتنا حول كيفية تثبيت OpenSSL على Windows، ثم شغّل الأمر من Command Prompt أو PowerShell.
• macOS: تُقدّم Apple LibreSSL، وهو فرع من OpenSSL، كأمر openssl المدمج، لذا يُعيد هذا الأمر نتيجة مثل LibreSSL 3.3.6 بدلاً من إصدار OpenSSL.

الأمر الرئيسي في هذا الدليل يعمل على LibreSSL 3.3.6 وكذلك على OpenSSL الحالي، لذا يمكن لمستخدمي Mac استخدام الأداة المدمجة. إذا كنت تفضّل استخدام OpenSSL الحقيقي (بعض الأوامر الاختيارية أدناه تحتاجه)، ثبّته باستخدام مدير الحزم Homebrew واستدعه بمساره الكامل:

brew install openssl@3
/opt/homebrew/opt/openssl@3/bin/openssl version

على أجهزة Mac ذات معالج Intel يكون المسار /usr/local/opt/openssl@3/bin/openssl بدلاً من ذلك. لمزيد من التفاصيل حول قراءة الناتج، راجع دليلنا حول كيفية التحقق من إصدار OpenSSL.

كيفية إنشاء شهادة ذاتية التوقيع باستخدام OpenSSL

الخطوة 1: افتح موجه أوامر (terminal)

على Linux، اضغط Ctrl + Alt + T أو ابحث عن “Terminal” في قائمة التطبيقات. على macOS، افتح Applications، ثم Utilities، ثم Terminal، أو اضغط Cmd + Space واكتب “Terminal”. على Windows، اضغط Win + R، واكتب cmd، ثم اضغط Enter.

الخطوة 2: انتقل إلى المجلد الذي تريد وضع الملفات فيه

تكتب OpenSSL ناتجها في المجلد الذي تكون موجودًا فيه حاليًا، لا في المجلد الذي تم تثبيت OpenSSL فيه. أنشئ مجلدًا لهذه الشهادة وانتقل إليه لكي ينتهي المفتاح والشهادة في مكان يمكنك إيجاده:

mkdir my-cert
cd my-cert

على Windows، استخدم نفس الأمرين في Command Prompt. لا تشغّل الأوامر من داخل مجلد برنامج OpenSSL: على Windows، لا يمكن الكتابة في ذلك المجلد غالبًا لمستخدم عادي، ودمج مفاتيحك مع الملفات التنفيذية يجعلها سهلة الضياع.

الخطوة 3: شغّل أمر الشهادة

ينشئ هذا الأمر الواحد المفتاح الخاص والشهادة ذاتية التوقيع معًا. استبدل example.com وwww.example.com بالأسماء التي سيتم الوصول إلى خدمتك من خلالها فعليًا:

openssl req -x509 -newkey rsa:2048 -keyout private.key -out certificate.crt -days 365 -nodes -addext "subjectAltName=DNS:example.com,DNS:www.example.com" -addext "basicConstraints=critical,CA:FALSE" -addext "extendedKeyUsage=serverAuth"

احتفظ به على سطر واحد. تستخدم Command Prompt وواجهات Unix أحرف استمرار سطر مختلفة، والسطر الواحد يعمل في كل مكان. استخدم علامات اقتباس مزدوجة لا مفردة، للسبب نفسه: لا تعامل Command Prompt علامات الاقتباس المفردة كاقتباس.

هذا ما يفعله كل جزء:

• req -x509: إنتاج شهادة نهائية وموقّعة بدلاً من طلب توقيع شهادة.
• -newkey rsa:2048: إنشاء مفتاح خاص RSA جديد بطول 2048 بت كجزء من الأمر نفسه. 2048 بت هو الحد الأدنى الحالي وقيمة افتراضية منطقية. استخدم rsa:4096 إذا كانت سياستك تتطلب مفتاحًا أكبر، على حساب مصافحات أبطأ.
• -keyout private.key: اسم ملف المفتاح الخاص.
• -out certificate.crt: اسم ملف الشهادة.
• -days 365: مدة صلاحية الشهادة. راجع قسم الصلاحية أدناه قبل تغيير هذا.
• -nodes: ترك المفتاح الخاص غير مشفّر، لكي يتمكن خادم الويب من البدء دون أن يكتب شخص عبارة مرور.
• -addext “subjectAltName=…”: قائمة أسماء المضيف التي تكون الشهادة صالحة لها. بدون هذا، لا تتطابق الشهادة مع أي شيء.
• -addext “basicConstraints=critical,CA:FALSE”: تحديد الشهادة كشهادة كيان نهائي (خادم) بدلاً من هيئة إصدار شهادات.
• -addext “extendedKeyUsage=serverAuth”: تحديد أن الشهادة مخصصة للمصادقة على خادم TLS. تعامل منصات Apple هذا كإلزامي.

لماذا تُهمّ خيارات -addext الثلاثة

هذه العلامات الثلاثة هي الفرق بين شهادة تعمل وشهادة يرفضها العملاء تمامًا. يستحق الأمر فهمها، لأن الشهادة ذاتية التوقيع المُنشأة بدونها تفشل بثلاث طرق يسهل تشخيصها بشكل خاطئ.

الاسم البديل للموضوع (Subject Alternative Name) هو مكان وجود أسماء المضيف. توقفت المتصفحات عن قراءة حقل الاسم العام (Common Name) منذ سنوات، وتُطابق الآن اسم المضيف فقط مع امتداد الاسم البديل للموضوع (SAN). الشهادة التي لا تحتوي على SAN لا تتطابق مع أي موقع، مهما بدا الاسم العام صحيحًا. اذكر كل اسم ستستخدمه، مفصولة بفواصل. لخدمة محلية يمكنك تضمين عنوان IP أيضًا:

-addext "subjectAltName=DNS:localhost,DNS:dev.example.com,IP:127.0.0.1"

بدون CA:FALSE، تبني لك OpenSSL شهادة هيئة إصدار شهادات (CA). عندما تُترك req -x509 على إعداداتها الافتراضية، تضبط basicConstraints على critical, CA:TRUE، وهذا يصف هيئة إصدار شهادات، لا خادم ويب. يقبل Chrome و Safari ذلك في شهادة خادم. لا يقبله Firefox، ويتوقف برسالة MOZILLA_PKIX_ERROR_CA_CERT_USED_AS_END_ENTITY. يمكنك النقر على Advanced وإضافة استثناء، لكنك تكون بذلك تتفادى مشكلة في شهادة تعرف مسبقًا أنها غير صحيحة التنسيق، وعملاء آخرون يضعون الخط الفاصل في مواضع مختلفة. تمرير basicConstraints=critical,CA:FALSE يتجنب الموقف من البداية.

يتصرف بناء LibreSSL الذي تُقدّمه macOS بشكل مختلف هنا: إذا تُرك على إعداداته الافتراضية، فإنه يكتب شهادة X.509 الإصدار 1 بلا أي امتدادات على الإطلاق، لذا لن تحصل على مشكلة CA:TRUE ولكن أيضًا بلا اسم بديل للموضوع. توفير الامتدادات بشكل صريح يمنحك الشهادة الصحيحة نفسها في كلتا الأداتين.

بدون serverAuth، ترفض منصات Apple الشهادة. تنص متطلبات Apple المنشورة للشهادات الموثوقة على أن شهادة خادم TLS يجب أن تحمل امتداد ExtendedKeyUsage يحتوي على معرّف الغرض id-kp-serverAuth. تفشل الشهادة التي لا تحمله في التحقق من الشهادة على macOS بموجب سياسة TLS برسالة “Invalid Extended Key Usage for policy”، حتى عندما تُقدَّم الشهادة كمرساة ثقة خاصة بها. يتسامح Firefox و Chrome أكثر ويعاملان غياب ExtendedKeyUsage على شهادة خادم كأمر مسموح، لذا يسهل تفويت هذا حتى يصبح جهاز Mac أو iPhone هو الجهاز الذي لن يتصل. إضافة extendedKeyUsage=serverAuth لا تُكلّف شيئًا على المنصات الأخرى وهو ما ستصدره أي هيئة إصدار شهادات عامة على أي حال.

الخطوة 4: أدخل تفاصيل الشهادة

تطلب OpenSSL الحقول التي تشكّل الاسم المميز (Distinguished Name). اضغط Enter لتخطي أي واحد منها، لكن أدخل قيمة واحدة على الأقل، واجعلها الاسم العام (Common Name). يتوقف بناء LibreSSL على macOS برسالة “error, no objects specified in config file” ولا يكتب شيئًا إذا تركت كل الحقول فارغة. القيم أدناه هي أمثلة، لذا استخدم قيمك الخاصة:

• Country Name: رمز البلد المكوّن من حرفين، على سبيل المثال US.
• State or Province Name: مكتوبة بالكامل، على سبيل المثال California.
• Locality Name: مدينتك، على سبيل المثال San Jose.
• Organization Name: اسم شركتك أو مشروعك، على سبيل المثال Example Inc.
• Organizational Unit Name: الفريق المسؤول، على سبيل المثال IT.
• Common Name: اسم المضيف الرئيسي، على سبيل المثال example.com. استخدم نفس الاسم الذي وضعته أولًا في قائمة الاسم البديل للموضوع.
• Email Address: عنوان تواصل، على سبيل المثال [email protected]. اختياري.

الاسم العام هو الوحيد المهم فعليًا هنا، وذلك فقط كتصنيف: يتم تطابق اسم المضيف عبر الاسم البديل للموضوع الذي حدّدته مسبقًا في سطر الأمر. كل ما عداه وصفي فقط.

ستلاحظ أن الأمر لا يطلب أبدًا كلمة مرور تحدٍّ (challenge password). ينتمي هذا الحقل إلى طلبات توقيع الشهادات، وهو حقل بدائي متبقٍ تتجاهله هيئات إصدار الشهادات عمومًا أو ترفضه. ولأن هذا الأمر يُنتج شهادة نهائية بدلاً من طلب، فإن هذا المطالبة لا تظهر على الإطلاق.

الخطوة 5: تحقق من الشهادة قبل استخدامها

لا تتخطَّ هذه الخطوة. يمكن إنشاء شهادة ذاتية التوقيع بنجاح ومع ذلك تكون غير قابلة للاستخدام، ولا يظهر الفشل إلا لاحقًا كخطأ في المتصفح. اقرأ الشهادة بعد إنشائها:

openssl x509 -in certificate.crt -noout -text

في كتلة امتدادات X509v3 تبحث عن ثلاثة أشياء بالضبط:

X509v3 Subject Alternative Name:
    DNS:example.com, DNS:www.example.com
X509v3 Basic Constraints: critical
    CA:FALSE
X509v3 Extended Key Usage:
    TLS Web Server Authentication

إذا كان سطر الاسم البديل للموضوع غائبًا، فلن تتطابق الشهادة مع أي اسم مضيف. إذا قالت Basic Constraints CA:TRUE، سيتوقف Firefox عندها. إذا كان سطر Extended Key Usage غائبًا، سترفض منصات Apple الشهادة. في أي من هذه الحالات، احذف الملفين وأعد تشغيل الأمر مع وجود جميع خيارات -addext الثلاثة.

على OpenSSL 3.x يمكنك طلب فقط هذه الامتدادات بدلاً من قراءة الشهادة كاملة:

openssl x509 -in certificate.crt -noout -ext subjectAltName,basicConstraints,extendedKeyUsage

لا يوجد خيار -ext في بناء LibreSSL الذي تُقدّمه macOS، والذي يُعيد “unknown option -ext”. على جهاز Mac عادي، استخدم نسخة -text أعلاه.

للتأكد من أن الشهادة والمفتاح ينتميان لبعضهما، قارن معاملاتهما (moduli). يجب أن يطبع الأمران نفس التجزئة (hash):

openssl x509 -noout -modulus -in certificate.crt | openssl md5
openssl rsa -noout -modulus -in private.key | openssl md5

الشهادة نفسها هي ملف نصي. فتحها في محرر نصوص يُظهر كتلة base64 بين سطري BEGIN CERTIFICATE و END CERTIFICATE، وهذا ما تلصقه في لوحات التحكم التي تطلب الشهادة بدلاً من رفع ملف.

تنويعات على الأمر

إنشاؤها بدون أي مطالبات

للسكريبتات وخطوط أنابيب CI، قدّم الاسم المميز باستخدام -subj ويعمل الأمر دون تدخل بشري:

openssl req -x509 -newkey rsa:2048 -keyout private.key -out certificate.crt -days 365 -nodes -subj "/C=US/ST=California/L=San Jose/O=Example Inc/CN=example.com" -addext "subjectAltName=DNS:example.com,DNS:www.example.com" -addext "basicConstraints=critical,CA:FALSE" -addext "extendedKeyUsage=serverAuth"

استخدام مفتاح EC بدلاً من RSA

مفاتيح المنحنى الإهليلجي (Elliptic-curve) أصغر وأسرع من RSA بقوة متساوية، ويدعمها كل متصفح حديث. P-256 هو الاختيار المعياري:

openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -keyout private.key -out certificate.crt -days 365 -nodes -addext "subjectAltName=DNS:example.com,DNS:www.example.com" -addext "basicConstraints=critical,CA:FALSE" -addext "extendedKeyUsage=serverAuth"

النتيجة موقّعة بـ ecdsa-with-SHA256. التزم بـ RSA إذا كان عليك دعم عملاء مضمّنين قديمة أو إصدارات Java القديمة، التي قد تفتقر إلى دعم EC.

استخدم OpenSSL الحقيقي لهذا الأمر. يقبل بناء LibreSSL على macOS الأمر، لكنه يكتب المنحنى في الشهادة كمجموعة كاملة من المعاملات الصريحة بدلاً من معرّف P-256 المعياري. ينص RFC 5480 على أن الصيغة الصريحة يجب ألا تُستخدم في الشهادات، وترفض macOS نفسها شهادة مُرمّزة بهذه الطريقة.

تحقق من النتيجة باستخدام openssl x509 -in certificate.crt -noout -text: تريد سطرًا يقول “ASN1 OID: prime256v1″، لا كتلة تسرد Prime و A و B و Generator. على جهاز Mac عادي، استخدم أمر RSA أعلاه أو ثبّت OpenSSL عبر Homebrew أولًا.

-nodes أم -noenc؟

يفعل كل من هذين الخيارين الشيء نفسه: يمنعان OpenSSL من تشفير المفتاح الخاص بعبارة مرور. أضاف OpenSSL 3.x خيار -noenc بوصفه الاسم الأوضح، ويعتبر -nodes مهجورًا (deprecated)، وإن كان لا يزال يقبله. لا يعرف LibreSSL، الذي تُقدّمه macOS، خيار -noenc على الإطلاق ويُصدر خطأً.

يستخدم هذا الدليل -nodes لأنه الخيار الذي يعمل على كل بناء من المرجح أن تصادفه، بما فيها جهاز Mac عادي. إذا كنت تستخدم OpenSSL 3.x وتريد تجنّب الصيغة المهجورة، استبدلها بـ -noenc. لا شيء آخر يتغيّر.

إذا حذفت الخيار تمامًا، تُشفّر OpenSSL المفتاح بعبارة مرور تختارها، وسيطلبها خادم الويب في كل مرة يُعاد تشغيله. هذا نادرًا ما يكون ما تريده لشهادة تطوير.

جعل جهازك يثق بالشهادة

شهادة ذاتية التوقيع صحيحة لا تزال تُنتج تحذير متصفح، لأنه لم يُطلب من أي شيء أن يثق بها. إضافتها إلى مخزن الثقة المحلي هو ما يُوقف التحذير، وهذا عادة ما هو الهدف من إنشاء إحداها في المقام الأول.

افعل هذا فقط على الأجهزة التي تتحكم بها، وفقط للشهادات التي أنشأتها بنفسك. الشهادة الموثوقة تكون موثوقة لكل موقع تُسمّيه، لذا عامل المفتاح الخاص وفقًا لذلك ولا تشاركه مطلقًا.

macOS Keychain

أضف الشهادة إلى سلسلة المفاتيح (keychain) النظامية وحدّدها كموثوقة لـ TLS. سيُطلب منك كلمة مرور المسؤول:

sudo security add-trusted-cert -d -r trustRoot -p ssl -k /Library/Keychains/System.keychain certificate.crt

يحدّ الجزء -p ssl الثقة لاتصالات TLS فقط. اتركه وتصبح الشهادة موثوقة لكل غرض تعرفه macOS، بما فيه توقيع الكود، وهذا أكثر بكثير من ما تحتاجه شهادة تطوير.

لفعل ذلك عبر الواجهة بدلاً من ذلك، انقر مزدوجًا على ملف الشهادة لفتح Keychain Access، جد الإدخال تحت سلسلة مفاتيح System، افتحه، وسِّع Trust، واضبط When using this certificate على Always Trust. لإلغاء ذلك لاحقًا، احذف الإدخال من Keychain Access.

مخزن شهادات Windows

افتح Command Prompt كمسؤول (اضغط Win + R، اكتب cmd، ثم اضغط Ctrl + Shift + Enter) وأضف الشهادة إلى مخزن Trusted Root Certification Authorities:

certutil -addstore -f "Root" certificate.crt

بدلًا من ذلك، انقر مزدوجًا على ملف الشهادة، اختر Install Certificate، اختر Local Machine، ثم Place all certificates in the following store، وتصفح إلى Trusted Root Certification Authorities. لإزالتها لاحقًا، افتح certmgr.msc واحذف الإدخال من ذلك المخزن.

ca-certificates على Linux

على Debian و Ubuntu، انسخ الشهادة إلى مجلد المراسي المحلي وأعد بناء الحزمة. يجب أن يحتفظ الملف بامتداد .crt أو ستتجاهله أداة التحديث:

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

على RHEL و CentOS و AlmaLinux و Rocky و Fedora، تختلف المسارات:

sudo cp certificate.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust extract

استثناء Firefox

يحتفظ Firefox بمخزن ثقته الخاص بدلاً من استخدام نظام التشغيل. على Windows و macOS يقرأ أيضًا الجذور المضافة إلى مخزن نظام التشغيل افتراضيًا، لذا تُغطّي الخطوات أعلاه عادةً ذلك. على Linux لا يفعل ذلك، لذا يجب استيراد الشهادة إلى Firefox مباشرة: افتح Settings، ثم Privacy & Security، انتقل بالتمرير إلى Certificates، اضغط View Certificates، افتح تبويب Authorities، واستخدم Import.

أعد تشغيل المتصفح بعد أي من هذه التغييرات. تخزّن المتصفحات قرارات الشهادات مؤقتًا، وجلسة قديمة سبب شائع لاستمرار ظهور التحذير بعد استيراد صحيح.

متى لا يجب استخدام شهادة ذاتية التوقيع

لا تضع واحدة أبدًا على موقع سيزوره الجمهور. يحصل كل زائر على تحذير أمني بملء الصفحة، والذين يستمرون على أي حال قد تدرّبوا على النقر عبر التحذير الذي يحميهم بالضبط من هجوم حقيقي. لا توجد أيضًا وسيلة يستطيع الزائر بها تمييز شهادتك ذاتية التوقيع عن شهادة مهاجم، وهذا هو السبب الكامل لعدم ثقة المتصفحات بها. نتناول التفاصيل في مقالتنا عن مخاطر الشهادات ذاتية التوقيع.

تفشل الشهادات ذاتية التوقيع أيضًا في تحقيق متطلبات عملية تتجاوز تحذير المتصفح. تتطلب معالجات الدفع، ومتاجر التطبيقات، وتطبيقات الهاتف المحمول التي تستخدم تثبيت الشهادات (certificate pinning)، وأغلب أنظمة الامتثال، شهادة من هيئة إصدار شهادات معتمدة. لأي شيء عام المواجهة، استخدم شهادة صادرة عن هيئة إصدار شهادات موثوقة، والتي تطلبها بواسطة CSR ويتم التحقق منها قبل الإصدار. وبعد أن تصبح مفعّلة، تأكّد من التثبيت بواسطة SSL Checker الخاص بنا.