الفصل : 6
الجزء : 3
العنوان : ال Certificates
الحصول على شهادة SSL من سلطة تصديق عامة
نحن الآن مرتاحون نسبيًا في الحصول على الشهادات من خادم CA الخاص بنا داخل شبكتنا، ولكن ماذا عن التعامل مع شهادات SSL لخوادم الويب الخاصة بنا التي يجب الحصول عليها من سلطة تصديق عامة؟ بالنسبة للعديد منكم، سيكون هذا هو التفاعل الأكثر شيوعًا الذي لديك مع الشهادات، ومن المهم جدًا فهم هذا الجانب أيضًا. عندما تحتاج إلى الحصول على شهادة SSL من سلطة التصديق العامة التي تختارها، هناك عملية من ثلاث خطوات للقيام بذلك: إنشاء طلب شهادة، تقديم طلب الشهادة، وتثبيت الشهادة الناتجة.
سوف نستخدم الخادم WEB1 الخاص بي، حيث لدي موقع ويب يعمل. حاليًا، الموقع قادر فقط على التعامل مع حركة مرور HTTP، ولكن عندما نطلقه على الإنترنت، نحتاج إلى تفعيل HTTPS للحفاظ على المعلومات التي يتم إرسالها إلى الموقع مشفرة.
لاستخدام HTTPS، نحتاج إلى تثبيت شهادة SSL على الخادم WEB1. هذا الخادم يعمل على منصة خدمات الويب من Microsoft، وهي Internet Information Services (IIS).
عملية الثلاث خطوات التي تقوم بها هي نفسها إذا كنت تقوم بتشغيل خادم ويب مختلف، مثل Apache، ولكن الأشياء الخاصة التي تحتاج إلى القيام بها لتحقيق هذه الخطوات الثلاث ستكون مختلفة لأن Apache أو أي خادم ويب آخر سيكون لديه واجهة مستخدم مختلفة عن IIS. نظرًا لأننا نعمل على خادم ويب Windows Server 2022، فإننا نستخدم IIS 10.
ال Public/private key pair
قبل أن نبدأ في تنفيذ تلك الخطوات الثلاث، دعونا نتحدث عن سبب أهمية هذا الأمر. ربما سمعت عن مصطلح الprivate key ولكن قد لا تفهم تماماً ما يعنيه. عندما نرسل حركة المرور عبر الإنترنت من أجهزة الكمبيوتر العميلة إلى موقع ويب HTTPS، نفهم أن هذه الحركة مشفرة. هذا يعني أن الحزم تُعبأ في حزمة صغيرة لطيفة قبل مغادرة جهاز اللابتوب الخاص بي بحيث لا يمكن لأحد رؤيتها أثناء انتقالها، ثم تُفك تلك الحزم بنجاح عندما تصل إلى الخادم. يستخدم جهاز اللابتوب مفتاحًا لتشفير الحركة، ويستخدم الخادم مفتاحًا لفك تشفير تلك الحركة، ولكن كيف يعرفون المفاتيح التي يجب استخدامها؟ هناك نوعان مختلفان من منهجية التشفير التي يمكن استخدامها هنا:
-ال Symmetric encryption : الطريقة الأبسط للتشفير، المتماثل، تعني أن هناك مفتاحًا واحدًا ويستخدمه كلا الجانبين. تُعبأ الحركة باستخدام مفتاح، ويُستخدم نفس المفتاح لفك تلك الحركة عند وصولها إلى وجهتها. نظرًا لأن هذا المفتاح الواحد هو Oz كلّي القدرة، لا ترغب في أن يقع في الأيدي الخاطئة، مما يعني أنك لن تقدمه على الإنترنت. لذلك، لا يُستخدم التشفير المتماثل عمومًا لحماية حركة مرور مواقع الويب على الإنترنت. بدلاً من ذلك، يُستخدم أكثر شيوعًا في الأماكن التي تتحكم فيها في كلا الجانبين من تيار الاتصال، مثل حركة مرور VPN.
- ال Asymmetric encryption : هذا هو تركيزنا مع حركة مرور HTTPS. يستخدم التشفير غير المتماثل مفتاحين: مفتاح عام ومفتاح خاص. المفتاح العام مشمول داخل شهادة SSL الخاصة بك، بحيث يمكن لأي شخص على الإنترنت الاتصال بموقعك والحصول على المفتاح العام. ثم يستخدم جهاز اللابتوب هذا المفتاح العام لتشفير الحركة ويرسلها إلى الخادم. لماذا يعتبر هذا آمنًا إذا كان المفتاح العام يبث إلى الإنترنت كله؟ لأن الحركة يمكن فك تشفيرها فقط باستخدام المفتاح الخاص المقابل، والذي يُخزن بأمان على خادم الويب الخاص بك. من المهم جدًا الحفاظ على أمان مفتاحك الخاص وخوادم الويب الخاصة بك، وضمان عدم وقوع المفتاح في جيب أي شخص آخر.
إنشاء طلب توقيع شهادة
إذا كنت قد تقدمت بالفعل وحصلت على شهادة SSL من كيان CA العام الخاص بك عن طريق تسجيل الدخول إلى موقعهم على الويب، وشراء شهادة، وتنزيلها فورًا، فقد فاتتك الفرصة. تلك الشهادة بالطبع لن تعرف أي شيء عن مفتاح خاص قد يكون لديك على خادم الويب الخاص بك، وبالتالي ستكون تلك الشهادة غير مجدية عند تثبيتها في أي مكان. عندما تثبت شهادة SSL على خادم ويب، من المهم جدًا أن تعرف الشهادة عن مفتاحك الخاص. كيف نتأكد من حدوث ذلك؟ هنا يأتي دور طلب توقيع الشهادة (CSR). الخطوة الأولى في الحصول على شهادة SSL بشكل صحيح هي توليد CSR من خادم الويب المحلي الخاص بك. عند إنشاء هذا الملف، يقوم منصة خادم الويب بإنشاء المفتاح الخاص اللازم ويخفيه على خادمك.
ثم يتم إنشاء CSR بطريقة تعرف بالضبط كيفية التفاعل مع هذا المفتاح الخاص، ثم تستخدم CSR عند تسجيل الدخول إلى موقع CA لطلب الشهادة. المفتاح الخاص ليس داخل CSR، ولا يعرف بائع CA الخاص بك أبدًا ما هو مفتاحك الخاص. هذا المفتاح مهم جدًا ويتم تخزينه فقط على خادم الويب الخاص بك، داخل مؤسستك.
لإنشاء CSR، افتح IIS من قائمة Tools في Server Manager، ثم انقر على اسم خادم الويب من شجرة التنقل على الجانب الأيسر من الشاشة. سيؤدي هذا إلى ملء عدد من الأبلتات المختلفة في مركز وحدة التحكم. الأبلت الذي نريد العمل معه يسمى Server Certificates. انقر نقرًا مزدوجًا على ذلك:
الآن، على شاشة Server Certificates، يمكنك رؤية أي شهادات موجودة على الخادم مدرجة هنا. هذا هو المكان الذي نحتاج فيه في النهاية لرؤية شهادة SSL الجديدة لدينا حتى نتمكن من استخدامها داخل خصائص موقعنا الإلكتروني عندما نكون مستعدين لتشغيل HTTPS. الخطوة الأولى للحصول على الشهادة الجديدة الخاصة بنا هي إنشاء طلب الشهادة ليتم استخدامه مع CA، وإذا نظرت إلى الجانب الأيمن من الشاشة، سترى قسمًا يسمى Actions، تحت الذي مدرج Create Certificate Request.... انقر على ذلك الإجراء:
في المعالج الناتج، تحتاج إلى ملء المعلومات التي سيتم تخزينها داخل شهادة SSL الخاصة بك. حقل الاسم الشائع هو أهم قطعة من المعلومات هنا. يجب أن يكون اسم DNS الذي ستحميه هذه الشهادة. لذلك بشكل أساسي، أدخل اسم موقع الويب الخاص بك هنا، ثم استمر في ملء باقي المعلومات الخاصة بشركتك. بعض الملاحظات الخاصة هنا التي غالبًا ما تزعج المسؤولين هي أن الوحدة التنظيمية يمكن أن تكون أي شيء على الإطلاق؛ عادةً ما أدخل كلمة Web. تأكد أيضًا من كتابة اسم ولايتك بالكامل؛ لا تستخدم اختصارًا.
في صفحة خصائص موفر الخدمة التشفيرية، عادةً ما تريد ترك موفر الخدمة التشفيرية مضبوطًا على الإعداد الافتراضي، إلا إذا كان لديك بطاقة تشفير متخصصة في خادمك وتخطط لاستخدامها لمعالجة التشفير لهذا الموقع. على خادم IIS، سيكون لديك دائمًا تقريبًا Microsoft RSA SChannel Cryptographic Provider مدرجًا هنا. ما تريد تغييره، مع ذلك، هو طول البتات. كان طول البتات القياسي لسنوات عديدة 1024، وهذا لا يزال الخيار الافتراضي في Windows Server 2022. قررت الصناعة العامة للتشفير SSL أن 1024 ضعيف جدًا، والمعيار الجديد هو 2048. عندما تتوجه إلى موقع CA لطلب شهادة، من المرجح أن تجد أن طلبك يحتاج إلى 2048 بت كحد أدنى. لذا اذهب وقم بتغيير هذا الإعداد إلى 2048:
الشيء الوحيد المتبقي لنا في CSR هو إعطائه موقعًا واسم ملف. حفظ هذا csr كملف نصي هو الطريقة العادية للذهاب ويخدم أغراضنا جيدًا لأنه كل ما نحتاجه عندما نطلب الشهادة هو فتح الملف ثم نسخ ولصق المحتويات. لقد أنشأنا الآن ملف csr، ويمكننا استخدام هذا الملف لطلب الشهادة من CA العامة الخاصة بنا.
تقديم طلب الشهادة
الآن، توجه إلى موقع الويب الخاص بسلطة الشهادة العامة الخاصة بك. مرة أخرى، أي من الشركات التي ذكرناها سابقًا، مثل GoDaddy أو Verisign، مناسبة لهذا الغرض. لكل سلطة واجهتها الخاصة لتفاعلها مع المستخدم، لذلك لا يمكنني إعطائك الخطوات الدقيقة التي تحتاج إلى اتخاذها لهذه العملية. بمجرد أن يكون لديك حساب وتسجيل الدخول إلى موقع السلطة، يجب أن تكون قادرًا على العثور على خيار لشراء شهادة SSL. بالنسبة لبعض سلطات الشهادة، تكون عملية الشراء وعملية الحصول على الشهادة عمليتين مختلفتين. على سبيل المثال، تشتري وتدفع مقابل شهادة SSL الجديدة الخاصة بك ثم تزور قسمًا مختلفًا من الواجهة لاستخدام "رصيد الشهادة" الذي اشتريته للتو لإنشاء شهادة. من ناحية أخرى، تأخذك بعض سلطات الشهادة خلال العملية بأكملها من البداية إلى النهاية. في أي حال، بمجرد شراء تلك الشهادة، سيكون هناك عملية لطلب وتوزيع تلك الشهادة.
بمجرد العثور على الواجهة المستخدمة لإنشاء الشهادة الجديدة، ستُطلب منك عادةً أربع قطع من المعلومات:
1. **فترة الصلاحية** – ما المدة التي يجب أن تستمر فيها هذه شهادة SSL؟ كان من الشائع أن تشتري الشركات شهادات SSL بفترات صلاحية سنة، سنتين، أو حتى ثلاث سنوات، مما يعني أن الشهادة كانت "صالحة" لتلك الفترة الزمنية. مؤخرًا، قررت Apple أن متصفح الويب Safari سيثق فقط في الشهادات التي لها فترة صلاحية سنة واحدة، أكثر أو أقل. بدلاً من الدفع للخلف، قالت الصناعة "بالتأكيد، لماذا لا؟" وبالتالي فإن شهادات SSL ستكون صالحة لمدة سنة واحدة فقط في كل مرة. للتوضيح، يمكنك لا يزال شراء شهادة SSL لعدة سنوات في كل مرة، مما قد يمنحك صفقة أفضل على تكلفة السنة، ولكن حتى إذا كنت قد اشتريت عدة سنوات من استخدام شهادة SSL، فسوف تحتاج إلى استبدال الشهادة كل عام بشهادة جديدة من موفر الشهادة الخاص بك. سنتحدث أكثر عن هذا قريبًا، عندما نناقش إعادة تأهيل الشهادات.
2. **منصة خادم الويب** – ما نوع خادم الويب الذي تقوم بتشغيله؟ يؤثر الإجابة على هذا السؤال على نوع الملف المتاح للتنزيل في نهاية هذه العملية. عند العمل مع Windows Server، ستكون إجابتك "IIS"، ولكن الخيارات الأخرى المحتملة تشمل Apache، Tomcat، NGINX، والعديد من اختيارات خادم الويب الأخرى القائمة على Linux.
3. **التحقق من ملكية النطاق** – هذا واحد مثير للاهتمام، وإذا لم تكن قد مررت بهذه العملية من قبل، فمن المحتمل أنك لم تفكر في سبب ضرورتها. ما الذي يمنع الهاكر جو الجالس في مقهى الإنترنت على بعد نصف العالم، أو طفل يبلغ من العمر 12 عامًا يلعب ألعاب الفيديو في قبوهم، أو حتى جارك المجاور من إنشاء تسجيل دخول خاص بهم إلى CA وشراء شهادة SSL تحمل اسم شركتك وموقع الويب الخاص بك؟ يعد التحقق من ملكية النطاق عملية لإثبات أنك تملك حقًا contoso.com (أو أيًا كان نطاقك) بحيث يُسمح لك فقط بشراء شهادات SSL صالحة تحمي حركة المرور لنطاقك. الطريقة الأكثر شيوعًا للتحقق من ملكية النطاق هي اختيار عنوان بريد إلكتروني محدد مسبقًا داخل CA وإرسال بريد إلكتروني للتحقق إلى ذلك العنوان. على سبيل المثال، قد يكون لديك اختيار من عناوين البريد الإلكتروني مثل ما يلي:
- admin@contoso.com
- administrator@contoso.com
- webmaster@contoso.com
- hostmaster@contoso.com
كل ما تحتاجه هو التحقق من أنه يمكنك تلقي بريد إلكتروني إلى أحد تلك العناوين، وعند اختيار هذا الخيار، ستتلقى بريدًا إلكترونيًا إلى ذلك العنوان الذي يحتوي عادةً على رابط وكود. ببساطة انسخ الكود والصقه في الرابط، وهذه طريقة سهلة للتحقق من ملكية النطاق لأنك كمالك لذلك النطاق، فقط أنت سيكون لديك حق الوصول إلى تلك العناوين البريدية. الشكل الثاني للملكية، إذا لم يكن البريد الإلكتروني ينفع، هو أن CA قد يمنحك سجل DNS خاص يمكن وضعه في DNS العام لنطاقك. تقوم بإدخال السجل، وترى CA أن السجل يظهر على الإنترنت، وتتحقق من أنك مالك النطاق. تستغرق هذه العملية وقتًا أطول بكثير لتحقيقها من التحقق عبر البريد الإلكتروني، لذا نادراً ما تُستخدم.
4.ال **CSR** – آخر شيء (والأهم) ستُطلب تقديمه هو النص من داخل ملف CSR الذي أنشأناه قبل دقائق. سيكون هناك إما وظيفة تحميل أو ببساطة صندوق إدخال، وكل ما تحتاج إلى القيام به هو نسخ/لصق المحتوى الكامل لـ CSR في ذلك الصندوق. إذا فتحت الملف النصي الذي حفظناه سابقًا، سترى مجموعة كبيرة من البيانات غير المفهومة:
تحتوي هذه البيانات الفوضوية على معلومات حول طلب الشهادة الخاص بك وهي بالضبط ما يحتاجه CA لإنشاء شهادة SSL الجديدة الخاصة بك بحيث يعرف كيفية التفاعل مع المفتاح الخاص بخادم الويب الخاص بك. فقط الخادم الذي أنشأ CSR سيتمكن من قبول واستخدام شهادة SSL المستندة إلى هذا CSR بشكل صحيح.
تنزيل وتثبيت الشهادة الخاصة بك
الآن يمكنك الجلوس والانتظار. بناءً على الهيئة التي تستخدمها وعدد مرات شراء شركتك للشهادات من هذه الهيئة، قد تكون شهادتك متاحة للتنزيل على الفور تقريبًا، أو قد يستغرق الأمر بضع ساعات قبل أن تظهر الشهادة في قائمة التنزيلات المتاحة. والسبب في ذلك هو أن العديد من CAs يستخدمون الموافقة البشرية للشهادات الجديدة، وأنت تنتظر حرفيًا لشخص ما لينظر في طلب الشهادة ومعلوماتك للتأكد من أنك تعمل حقًا في الشركة وأنك تملك هذا اسم النطاق بالفعل. تذكر، الفائدة الحقيقية لشهادة SSL العامة هي أن CA تضمن أن مستخدم هذه الشهادة هو الشخص الحقيقي، لذلك يريدون التأكد من أنهم لا يصدرون الشهادة، على سبيل المثال، لـ portal.contoso.com لشخص في مؤسسة Fabrikam عن طريق الخطأ.
بمجرد أن تتمكن من تنزيل الشهادة من موقع CA على الويب، تابع وانسخها إلى الخادم الذي أنشأنا منه CSR. من الأهمية بمكان أن تقوم بتثبيت هذه الشهادة الجديدة على نفس الخادم. إذا قمت بتثبيت هذه الشهادة الجديدة على خادم ويب مختلف، واحد لم يقم بإنشاء CSR التي تم بناء هذه الشهادة منها، فسيتم استيراد الشهادة بنجاح، لكنها لن تكون قادرة على العمل. مرة أخرى، هذا لأن المفتاح الخاص الذي تخطط الشهادة للتفاعل معه لن يكون موجودًا على خادم مختلف.
داخل وحدة إدارة IIS، يمكننا الآن استخدام الإجراء التالي المعروض على الجانب الأيمن من الشكل 6.25، يسمى Complete Certificate Request.... هذا يطلق معالجًا صغيرًا حيث تقوم بتوجيهه إلى ملف الشهادة الذي تم تنزيله حديثًا، ويقوم المعالج بعد ذلك باستيراده إلى خادمنا. الآن بعد أن أصبحت الشهادة موجودة على الخادم، فهي جاهزة للاستخدام من قبل موقعنا على الويب.
هناك عنصر إضافي دائمًا أتحقق منه بعد تثبيت أو استيراد شهادة SSL. يمكنك الآن رؤية شهادتك الجديدة مدرجة داخل IIS، وإذا نقرت نقرة مزدوجة على شهادتك الجديدة، سترى صفحة الخصائص للشهادة. في علامة التبويب General من هذه الخصائص، ألق نظرة بالقرب من الأسفل. يجب أن تعرض شهادتك رمز مفتاح صغير والنص "You have a private key that corresponds to this certificate". إذا كان بإمكانك رؤية هذه الرسالة، فقد كان استيرادك ناجحًا وتطابقت الشهادة الجديدة تمامًا مع CSR. الآن الخادم والشهادة يتشاركان تلك المعلومات الحرجة للمفتاح الخاص، وستتمكن شهادة SSL من العمل بشكل صحيح لحماية موقعنا على الويب. إذا لم تشاهد هذه الرسالة، فهناك خطأ ما في العملية لطلب وتنزيل شهادتك. إذا لم تشاهد الرسالة هنا، فستحتاج إلى البدء من جديد عن طريق إنشاء CSR جديدة، لأن ملف الشهادة الذي حصلت عليه لم يتم تكييفه بشكل صحيح مع تلك CSR، أو شيء من هذا القبيل. بدون النص "You have a private key that corresponds to this certificate" في أسفل هذه الشاشة، لن تتمكن شهادتك من التحقق من حركة المرور بشكل صحيح.
إعادة توليد الشهادات (Re-keying Certificates)
أثناء التنقل في واجهة CA العامة الخاصة بك، قد تكون لاحظت وظيفة أو زرًا لـ "re-key" الشهادة. ماذا يعني ذلك؟ عندما تشتري شهادة مثلportal.contoso.com من CA الخاص بك، يمكنك الآن استخدام CSR لصياغة شهادة بناءً على ذلك الاسم. ثم تقوم بتثبيت تلك الشهادة على خادم الويب الخاص بك، ومن ثم تحمي حركة المرور لموقعك portal.contoso.com. كل عام، يمكنك إعادة شراء الشهادة، وإعادة إنشاء CSR جديد، وإعادة تثبيت الشهادة كما لو كانت جديدة. ولكن ماذا لو كنت بحاجة إلى إعادة تثبيت هذه الشهادة في منتصف العام؟ ربما دفعت مقابل شهادة من يناير إلى يناير، ولكن الآن هو يوليو وخادم الويب الخاص بك قد تعطل؟ تقوم باستبدال الخادم، وإعادة تثبيت موقعك، والآن تدرك أنك بحاجة إلى الحصول على شهادة SSL جديدة على هذا الخادم الجديد لحماية حركة المرور لموقع portal.contoso.com نفسه. هل تحتاج إلى شراء شهادة SSL أخرى وتقبل الخسارة للتكلفة للأشهر الستة التي لم تستخدمها؟ لا، هنا يمكن أن تساعدك عملية re-keying للشهادة. إذا استخدمت خادم الويب الجديد الخاص بك لإنشاء CSR جديد، فيمكنك بعد ذلك أخذ ذلك CSR الجديد إلى موقع CA الخاص بك والعثور على الشهادة التي اشتريتها بالفعل، وتقوم ببساطة بإعادة توليد الشهادة مقابل CSR الجديد. ستؤدي هذه العملية إلى إبطال النسخة القديمة من الشهادة، وستصدر شهادة جديدة بناءً على CSR الجديد (بناءً على المفتاح الخاص للخادم الجديد، بالطبع)، والتي يمكنك بعد ذلك تثبيتها على خادم الويب الجديد الخاص بك. بهذه الطريقة، يمكنك الاستمرار في استخدام شهادة SSL التي اشتريتها على خادم جديد وإكمال السنة.
سبب آخر محتمل قد تجد نفسك فيه بإعادة توليد شهادة هو عندما تكون قد اشتريت عدة سنوات من شهادة SSL. إذا اشتريت portal.contoso.com لمدة ثلاث سنوات، تذكر أنه يمكنك فقط إصدار شهادة لمدة عام واحد في المرة الواحدة. لذلك كل عام، في أو قبل تاريخ انتهاء صلاحية الشهادة، ستحتاج إلى زيارة CA الخاص بك وإعادة توليد الشهادة للحصول على نسخة جديدة، مما يمنحك الحماية لسنة أخرى. لن تحتاج إلى الدفع مقابل ذلك إذا كنت قد اشتريت الشهادة لعدة سنوات، ولكن ستظل بحاجة إلى إجراء إعادة توليد الشهادة واستبدالها لخادم الويب الخاص بك للاستمرار في العمل بشكل صحيح.
تصدير واستيراد الشهادات
غالبًا ما أجد نفسي بحاجة إلى استخدام نفس شهادة SSL على خوادم متعددة. قد يحدث هذا في حالة وجود أكثر من خادم IIS يقدم نفس الموقع واستخدام شكل من أشكال توازن الحمل لتقسيم الحركة بينها. قد تنشأ هذه الحاجة أيضًا عند العمل مع أي شكل من أشكال توازن الحمل الأجهزة، حيث تحتاج أحيانًا إلى استيراد الشهادات ليس فقط إلى خوادم الويب نفسها ولكن أيضًا إلى صندوق توازن الحمل. مثال آخر هو عند استخدام الشهادات العامة (wildcard certificates)؛ عندما تشتري شهادة عامة، تنوي عادةً تثبيتها على خوادم متعددة. هل يعني ذلك أنك بحاجة إلى إنشاء CSR جديدة من كل خادم، وطلب نسخة جديدة من نفس الشهادة عدة مرات؟ بالتأكيد لا، وفي الواقع، قد يتسبب ذلك في مشكلات أخرى: تذكر أنه عند إعادة توليد الشهادة العامة - بمعنى آخر، إذا كنت قد طلبت بالفعل شهادة باسم معين ثم تعود لاحقًا لطلب نسخة أخرى من نفس الشهادة - من المرجح أن تقوم CA بإبطال النسخة الأولى أثناء إصدار النسخة الثانية. هذا ليس واضحًا دائمًا على الفور، حيث عادةً ما يتم تعيين مؤقت على إبطال الشهادة الأولى. إذا قمت بزيارة واجهة CA على الويب وطلبت نسخة جديدة من نفس الشهادة باستخدام CSR جديد لخادمك الثاني، قد تكتشف أن كل شيء يعمل بشكل جيد لبضعة أيام، ولكن بعد ذلك يتوقف خادم الويب الأساسي عن التحقق من صحة الحركة لأن شهادته SSL، النسخة الأصلية، قد انتهت صلاحيتها.
عندما تحتاج إلى إعادة استخدام نفس شهادة SSL على خوادم متعددة، يمكنك ببساطة تصديرها من واحدة واستيرادها على التالية. لا يوجد حاجة للاتصال بـ CA على الإطلاق. هذه العملية بسيطة جدًا، وهناك مكانان شائعان حيث يمكنك القيام بذلك: داخل إما MMC snap-in للشهادات أو من داخل IIS نفسه. من المهم ملاحظة أن العملية تختلف قليلاً حسب المسار الذي تتبعه، ويجب أن تكون مدركًا بشكل خاص لما يحدث مع المفتاح الخاص أثناء مرورك عبر هذه المعالجات.
التصدير من MMC
ارجع إلى مخزن الشهادات لجهاز الكمبيوتر المحلي في MMC وانتقل إلى Personal | Certificates بحيث يمكنك رؤية شهادة SSL الخاصة بك مدرجة. انقر بزر الماوس الأيمن على الشهادة، ثم انتقل إلى All Tasks | Export.... عند المرور عبر معالج التصدير هذا، الجزء المهم الذي أردت ذكره يحدث في بداية خطوات المعالج. الاختيار الأول الذي يجب عليك القيام به هو ما إذا كنت تريد تصدير المفتاح الخاص. مرة أخرى، المفتاح الخاص هو المكون السري الذي يسمح للشهادة بالتفاعل بشكل صحيح مع الخادم الذي تم تثبيتها عليه. إذا قمت بالتصدير بدون المفتاح الخاص، فلن تعمل الشهادة على خادم آخر. لذا من المهم هنا أنه، إذا كنت تقوم بتصدير هذه الشهادة بنية تثبيتها على خادم ويب ثاني واستخدامها للتحقق من صحة حركة SSL، يجب أن تختار الخيار الأعلى Yes, export the private key:
كما يحذر المعالج بشكل كافٍ، عندما تختار تصدير شهادة تحتوي على معلومات المفتاح الخاص، يتعين عليك تزويد كلمة مرور، والتي سيتم استخدامها لحماية ملف PFX المصدر. من المهم اختيار كلمة مرور جيدة. إذا نسيتها، سيكون ملفك المصدر عديم الفائدة تمامًا (وهذا ليس سيئًا، لأنك يمكن أن تقوم بتصديره مرة أخرى). إذا أدخلت كلمة مرور بسيطة جدًا أو سهلة التخمين، قد يتمكن أي شخص يحصل على هذا ملف PFX من استخدام شهادتك والمفتاح الخاص على خوادم الويب الخاصة به، وهذا لن يكون جيدًا.
تصدير من IIS
بدلاً من ذلك، يمكن توليد ملف PFX من داخل وحدة التحكم الخاصة بـ IIS. داخل تطبيق Server Certificates لـ IIS، انقر بزر الفأرة الأيمن على الشهادة واختر "تصدير...". سيظهر معالج صفحة واحدة يسألك ببساطة عن الموقع وكلمة المرور:
لدينا العديد من الخيارات التي كان يمكننا اختيارها أو رفضها عند التصدير باستخدام MMC، فلماذا هذا قصير جدًا؟ يقوم IIS بعمل افتراضات لباقي الإعدادات لتسريع عملية التصدير. عند تصدير شهادة SSL، من شبه المؤكد أنك تقصد أيضًا تصدير المفتاح الخاص. لذلك، يقوم IIS بعمل هذا الافتراض وتجاوز باقي الخيارات. يجب عليك إدخال كلمة مرور لأنك لا تملك خيارًا حول المفتاح الخاص؛ سيتم تضمينه تلقائيًا مع تصدير الشهادة. لذلك، إذا كان لديك سبب ما لتصدير شهادة لا تحتوي على معلومات المفتاح الخاص، فلن تستطيع استخدام وحدة التحكم الخاصة بـ IIS لهذه المهمة. ستحتاج إلى فتح MMC والمشي خلال المعالج الأكثر شمولًا الموجود هناك.
استيراد إلى خادم ثاني
بغض النظر عن الطريقة التي تتبعها لتحقيق التصدير، بمجرد توفر ملف PFX الكامل، يكون استيراده إلى الخادم الثاني سهلًا جدًا. من داخل أي وحدة تحكم، MMC أو IIS، يمكنك النقر بزر الفأرة الأيمن واختيار إجراء الاستيراد. عند المشي خلال الخطوات، ما عليك سوى اختيار ملف PFX ثم إدخال كلمة المرور التي استخدمتها لحماية الملف. ثم يتم استيراد الشهادة، وإذا فتحت الخصائص، سترى رمز المفتاح الصغير ورسالة المفتاح الخاص تظهر بشكل صحيح في أسفل شاشة خصائص الشهادة. إذا لم ترَ رسالة المفتاح الخاص، فقد فعلت شيئًا بشكل غير صحيح خلال عملية التصدير وستحتاج إلى المحاولة مرة أخرى.
اذهب وقم بتجربتها بنفسك؛ ابحث عن خادم يحتوي على شهادة SSL وجرب تصدير تلك الشهادة مع وبدون المفتاح الخاص. عند الاستيراد إلى خادم جديد، سترى أن استيراد ملف الشهادة بدون مفتاح خاص لا يؤدي إلى عرض هذه الرسالة في أسفل صفحة الخصائص، ولكن الملف المصدر الذي يحتوي على المفتاح الخاص يؤدي إلى عرض الرسالة بشكل صحيح هنا. لأخذ خطوة إضافية، حاول استخدام كلتا الشهادتين على موقع غير مهم وانظر ماذا سيحدث. ستجد أن الشهادة التي تفتقر إلى المفتاح الخاص ستفشل في التحقق من حركة مرور SSL.
إذا حاولت تصدير شهادة SSL وكان خيار تضمين المفتاح الخاص غير متاح (grayed out)، فهذا يعني أن المسؤول الأصلي عند تثبيته لهذه الشهادة على الخادم اختار خيارًا خاصًا يمنع القدرة على تصدير المفتاح الخاص في المستقبل. في هذه الحالة، لن تتمكن من تصدير الشهادة مع المفتاح الخاص.
الOpenSSL لخوادم Linux
يجب أن توفر لك هذه الفقرة كل المعلومات اللازمة لحماية المواقع بشهادات SSL الصادرة من CA عام...على خادم Windows. بينما هذا الكتاب يركز بشكل واضح على Microsoft، فإن الغالبية العظمى من الخوادم الموجودة ليست تعمل على منصات خوادم Microsoft. لذا، من المرجح أن تصادف نفس العدد من خوادم Linux كما تفعل مع IIS، وسيكون من المفيد جدًا لدورك كمسؤول خادم أن تكون قادرًا على تثبيت الشهادات على هذه الخوادم أيضًا.
أحد الاختلافات الرئيسية بين خوادم Windows وLinux هو أنواع الملفات المستخدمة للشهادات. يخفي IIS المفتاح الخاص؛ لا تتعامل معه فعليًا. عند تنزيل ملفات الشهادة لـ IIS، تكون عادة ملفات CER أو CRT. بينما يتوقع خادم Linux شيئًا آخر. على معظم خوادم Linux، تكون ملف الشهادة وملف المفتاح الخاص كلاهما ملفات منفصلة وواضحة على الخادم. عادةً ما تكون هذه الملفات بامتداد PEM.
لحسن الحظ، العملية العامة ذات الخطوات الثلاث للحصول على وتثبيت شهادة هي نفسها تمامًا. توليد CSR، استخدام CSR للحصول على شهادة من CA، وتثبيت الشهادة على الخادم. داخل هذه الخطوات الثلاث هناك بعض الاختلافات الكبيرة بين منصة Windows وLinux. دعونا نناقشها.
توليد CSR
قريبًا، سنقوم بتثبيت مجموعة أدوات تسمى OpenSSL واستخدامها لبعض الوظائف المتعلقة بالشهادات. هناك طريقة داخل أداة OpenSSL لتوليد ملف مفتاح خاص وملف CSR الموافق، لكن هذه ليست الطريقة التي أجدها الأكثر ملاءمة للمستخدم. بدلاً من ذلك، عندما يتعلق الأمر بمتطلبات تثبيت شهادة SSL على خادم Linux، أعود مباشرة إلى عالم Windows وأولد CSR من داخل IIS. لحظة، ماذا؟؟ ألم أقل للتو أن العمليات في Windows وLinux مختلفة؟ نعم، لكن تحمل معي للحظة. لا يهم CA من أين يأتي ملف CSR، وبالتالي بدلاً من استخدام منصة CLI مثل OpenSSL للعبث بأوامر النصوص واللجوء إلى Google للوصول إلى الأوامر الصحيحة، أقوم ببساطة بإنشاء ملف CSR بنفس الطريقة التي أفعلها لخادم Windows، داخل IIS.
إذا حاولت تصدير شهادة SSL وكان خيار تضمين المفتاح الخاص غير متاح، فهذا يعني أن المسؤول الأصلي عند تثبيت هذه الشهادة على الخادم اختار خيارًا خاصًا يمنع القدرة على تصدير المفتاح الخاص في المستقبل. في هذه الحالة، لن تتمكن من تصدير الشهادة مع المفتاح الخاص.
إذا لم يكن لديك خادم مثبت عليه IIS، يمكنك بسهولة توليد CSR من جهاز الكمبيوتر الذي يعمل بنظام Windows 10. إذا توجهت إلى لوحة التحكم ووجدت الخيار لتشغيل ميزات Windows أو إيقافها، ستكتشف خيار تثبيت Internet Information Services. هذا يثبت نفس واجهة وأدوات IIS على جهاز الكمبيوتر الذي يعمل بنظام Windows 10 كما يفعل على خادم Windows. من داخل وحدة التحكم الخاصة بـ IIS، سيكون لديك نفس الإجراءات المتاحة لتوليد وإكمال طلبات توقيع الشهادات، مباشرة على جهاز الكمبيوتر المحمول الخاص بك.
الحصول على الشهادة
الآن بعد أن لديك ملف CSR، تابع نفس سلسلة الخطوات التي ناقشناها سابقًا لتقديم CSR الخاص بك إلى CA، والتحقق من نفسك كمالك النطاق، وتنزيل ملف الشهادة الناتج.
تثبيت الشهادة
هنا نبدأ في توجيه السفينة بشكل مختلف للتعامل مع خادم Linux. أولاً وقبل كل شيء، تحتاج إلى تثبيت الشهادة على نفس خادم IIS (أو محطة العمل) الذي قمت بتوليد ملف CSR منه. مرة أخرى، هذا أمر بالغ الأهمية بحيث تقترن الشهادة الجديدة بنجاح مع المفتاح الخاص الذي تم إنشاؤه عند إنشاء CSR الخاص بك. بمجرد تثبيت الشهادة الجديدة والتحقق من أنها تبدو جيدة، يمكنك الآن استخدام المعرفة التي لديك من الصفحات السابقة وتصدير هذه الشهادة (بما في ذلك المفتاح الخاص) إلى ملف PFX.
يحتوي ملف PFX الجديد الخاص بك على كل من الشهادة والمفتاح الخاص. الخطوة الوحيدة المتبقية هي تمرير ملف PFX الخاص بك من خلال بضع أوامر OpenSSL، والتي ستقوم بعد ذلك بتحويل هذا الملف PFX إلى ملفين منفصلين بامتداد PEM، أحدهما يحتوي على شهادة SSL والآخر يحتوي على المفتاح الخاص. هذه الملفات هي بالضبط ما تتطلبه معظم خوادم Linux عندما تطلب منك تقديم شهادة SSL.
إليك الخطوات المطلوبة لتحقيق هذا الجزء الأخير من اللغز:
1. قم بتنزيل وتثبيت OpenSSL. الإصدار المتاح من هذا سيتغير أحيانًا، لذلك لا يمكنني توفير رابط تنزيل ثابت، ولكن يمكنك بسهولة العثور عليه بالبحث على الويب. الإصدار واسم الملف المحددين اللذين أعرف أنهما يعملان لهذا الغرض، لأنه هو المثبت على جهاز الكمبيوتر الخاص بي حاليًا، هو Win64OpenSSL-1_1_1n.exe.
2. ضع ملف PFX الخاص بك في موقع سنقوم بالإشارة إليه في أوامرنا. لأجل مثالنا، سأفترض أن ملف PFX الخاص بك يسمى Export.pfx، وأنه موجود داخل مجلد يسمى C:\Cert.
3. افتح موجه الأوامر وانتقل إلى المجلد حيث تم تثبيت OpenSSL. بالنسبة لإصداري، هذا هو الأمر الذي يأخذني إلى هذا المجلد:
CD C:\Program Files\OpenSSL-Win64\bin
4. قم بتشغيل الأمرين التاليين:
openssl pkcs12 -in c:\cert\export.pfx -nokeys -out c:\cert\portal.contoso.com-crt.pem -nodes
openssl pkcs12 -in c:\cert\export.pfx -nocerts -out c:\cert\portal.contoso.com-key.pem -nodes
(سيطلب منك إدخال كلمة مرور PFX بعد كل من هذه الأوامر.)
هذا كل شيء! الأوامر أعلاه ستضع ملفين جديدين داخل مجلد C:\Cert. الأول هو شهادتك، بينما الثاني هو مفتاحك الخاص. يجب نقل هذين الملفين إلى مجلد معين على خادم Linux الخاص بك أو تحميلهما في واجهة رسومية لأي برنامج تقوم بتشغيله على ذلك الخادم، لتحديد شهادة SSL التي ستستخدمها الموقع.
هذه الخطوات هي نوع من الجمع الغريب بين استخدام أدوات Windows وLinux للحصول على شهادة SSL في Apache، Tomcat، NGINX، أو خوادم مماثلة. أستخدم هذه الطريقة لأنني دائمًا ما أملك IIS جاهزًا بوجوده مثبتًا على جهاز الكمبيوتر الذي يعمل بنظام Windows 10، وبهذه الطريقة يمكنني ببساطة تخزين هذين الأمرين الخاصين بـ OpenSSL للوصول السريع لتحويل ملفات الشهادات عند الحاجة.
ملخص
غالبًا ما تحصل الشهادات على سمعة سيئة، وأعتقد أن هذا بسبب أن الناس يعتقدون أنها صداع للتعامل معها. أرى وجهة نظرهم. بدون معرفة كيفية التنقل خلال وحدات التحكم الإدارية المختلفة التي تتعامل مع بنية شهاداتك، سيكون من الصعب جعل حتى أبسط العناصر تعمل. من خلال استعراض المهام الشائعة المتعلقة بالشهادات التي سيضطر أي مسؤول خادم في نهاية المطاف للتعامل معها داخل شبكاتهم، آمل أن تكون قد وجدت بعض الراحة والثقة للتقدم في تلك المشاريع التي قد تكون متوقفة حاليًا، في انتظار بناء بنية الشهادات. في الفصل التالي، سندرس الشبكات مع Windows Server 2022.
النهاية
نكون هنا انتهينا من الفصل 6 تماما من شهادة MCSA المقدمة من Microsoft الأن نغوص في الأعماق
و لا بد وانت تقرا ان تكون مركز جيدا لكل معلومة ومعك ورقة وقلم , لانك بالتاكيد ستحتاجها
واذا واجهتك اي مشكلة في الفهم او ما شابه , يمكنك على الفور الذهاب الى المجتمع الخاص بنا في Telegram للمناقشة والتواصل معنا من هنا
او اذا واجهتك مشكلة في الموقع او تريد اجابة سريعة يمكنك الذهاب الى اخر صفحة في الموقع ستجد صفحة اتصل بنا موجودة يمكنك ارسالة لنا مشكلتك , وسيتم الرد عليها بسرعة جدا ان شاء الله
ويمكنك الأنضمام الى المجتمع Hidden Lock بالكامل مع جميع قنواته للأستفادة في اخر الأخبار في عالم التقنية وايضا الكتب بالمجان والكورسات والمقالات من خلال الرابط التالي لمجموعة القنوات من هنا
يمكنك ايضا متابعتنا في منصات X او Twitter سابقا , لمشاهدة الاخبار والمقالات السريعة والمهمة من
وفقط كان معكم Sparrow اتمنى ان تدعوا لي وتتذكروني في الخير دوما
