لماذا يُفسد نسخ ca.key إلى كل عميل VPN عمل سلطة الشهادات
يتحقق العميل من الشهادة العامة لسلطة الشهادات؛ ولا يحتاج أبدًا إلى المفتاح الذي يوقّع. أما نسخ ca.key إلى كل جهاز فيمنح صلاحية الإصدار لمن يحصل على نسخة واحدة.
في مكان ما داخل تعليمات الإعداد، يُنسخ دليل كامل إلى كل حاسوب محمول لأن ذلك كان أسهل من تحديد الملفات التي يجب أن تكون فيه. ذلك الدليل يحتوي على ca.key، وبمجرد وصوله إلى جهاز ثانٍ تتوقف سلطة الشهادات عن كونها سلطة. فكل من يحمله يستطيع الآن إصدار هويات يثق بها بقية الشبكة.
يستحق هذا الالتباس أن يُفكّ مرة واحدة، لأن الملفين متشابهان في المظهر ومتعاكسان في الوظيفة.
مادة التحقق ومادة التوقيع
يحتاج العميل إلى الشهادة العامة لسلطة الشهادات ليتحقق من أن الشهادة التي يقدّمها الطرف الآخر قد وُقّعت من تلك السلطة. وهذه مهمة تحقق لا تحتاج إلى أي سرّ على الإطلاق. أما توقيع شهادة طرف آخر فهو مهمة مختلفة، تُنفَّذ مرة واحدة ممن يدير سلطة الشهادات، بالمفتاح الخاص الذي لا يغادر مخزنه المحمي أبدًا. والفصل بين المهمتين هو الغاية كلها من إرسال ملفين.
لذلك ينتمي ca.crt إلى الملف الشخصي، ولا ينتمي ca.key إلى أي مكان قريب منه. أسماء الملفات عُرف لا ضمان، ولهذا يجب فحص نوع الكائن بدلًا من استنتاجه من الاسم.
ولا يُستثنى من ذلك تصميم يستخدم سلطة شهادات وسيطة أو خدمة إصدار متصلة. فهو الطريقة المعتادة لإبعاد القدرة على التوقيع عن الأجهزة الطرفية مع إصدار شهادات الأجهزة على نطاق واسع.
ما يجب أن يثبته العميل بمفتاحه الخاص
يحصل كل جهاز على زوج مفاتيح خاص به وشهادة خاصة به، موقّعة مرة واحدة من سلطة الشهادات. يقدّم العميل تلك الشهادة ويثبت حيازته للمفتاح الخاص المطابق، ويقرر الخادم قبولها أو رفضها. وهذه هي الهوية التي تُلغى عند فقدان حاسوب محمول.
يظهر التباين بأقصى وضوح بعد السرقة. فمع هويات لكل جهاز، يُزال العميل المكشوف بالإلغاء أو بإزالة النظير، ويستمر بقية الأسطول في العمل.
أما المفتاح المسرّب للسلطة فلا يمكن التعامل معه بتلك الطريقة. فكل شهادة وقّعتها أو كان يمكن أن توقّعها تصبح موضع شك، لذا يكون الرد استبدالًا لمرساة الثقة لا إلغاءً واحدًا. وهذا مشروع كامل، لا تذكرة دعم.
| File | Role | Belongs on |
|---|---|---|
ca.crt | Public certificate used to verify signatures | Every client profile |
ca.key | Private key that issues certificates | Protected CA storage only |
| client key pair | Proves one device's identity | That device alone |
اقرأ الملف قبل نسخه إلى أي مكان
يخبرك أمران بنوع الكائن الذي تحمله دون طباعة أي سرّ. الأول يذكر الموضوع وعلامة سلطة الشهادات على شهادة؛ والثاني يتحقق من مفتاح ويبلّغ عن نوعه. نفّذ الاثنين على الملفات الموجودة في الحزمة التي أنت على وشك توزيعها. وأي ملف يتحقق كمفتاح خاص لا ينتمي إلى دليل عميل.
openssl x509 -in ca.crt -noout -subject -ext basicConstraints openssl pkey -in ca.key -noout -check
إذا نجح الأمر الثاني على ملف موجود في حزمة عميل، توقف وعامل الحزمة على أنها مخترقة. فالمخرجات التي تقول إن المفتاح صالح تقول أيضًا إنه موجود، ووجوده هو المشكلة كلها.
لاحظ الاتجاه الآخر كذلك: ملف تعريف العميل يحتوي بشكل مشروع على المفتاح الخاص لذلك العميل. وحذف كل مفتاح تجده يقطع الاتصال دون تحسين شيء، لذا يجب تحديد نوع الكائن قبل إزالته.
احتواء مفتاح وزّعته بالفعل
لا تفترض أن حذف النسخة المحلية يعكس الانكشاف. فأي شخص حصل على الملف يمكن أن يكون نسخه، والافتراض الآمن أنه فعل. اتبع إجراء الحوادث لدى المشغّل واستبدل مرساة الثقة، وأعد إصدار شهادات الأجهزة تحت سلطة شهادات جديدة.
ثم غيّر التغليف الذي خلق المشكلة. أرسل قائمة دليل بقائمة سماح صريحة بالملفات، وأبقِ مفتاح سلطة الشهادات على جهاز لا ينضم أبدًا إلى أسطول العملاء، وسجّل النظام الذي يحتفظ به.
إذا كان على السلطة أن تصدر كثيرًا، فانقل التوقيع خلف خدمة أو سلطة وسيطة بنطاق ضيق وصلاحية قصيرة. بهذه الطريقة يكشف خطأ مستقبلي جزءًا من الإصدار بدلًا من جذر الثقة للنشر بأكمله.