ملف OpenVPN يحتوي على ثلاث كتل شهادات: أيّها سري؟

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

ملف واحد وثلاث كتل ومهام مختلفة

يدرج الملف النموذجي كتلة ca وكتلة cert وكتلة key بين علامتي BEGIN وEND، أو يشير إلى الثلاث نفسها كملفات منفصلة. تضيف بعض الملفات كتلة رابعة لمفتاح tls-auth أو tls-crypt، وهو سر مشترك لا شهادة. يقرأ العميل كل كتلة وفق التوجيه الذي يسميها، لذا تهم التسميات أكثر من ترتيب ظهورها.

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

التوجيهات المحيطة بالكتل تحدد طريقة استخدامها. غيّر ca فيثق العميل بجهة مختلفة؛ وغيّر cert دون تغيير key فيفشل المصافحة بسبب عدم تطابق لا علاقة له بالثقة.

كتلة CA عامة، ومفتاح CA ليس كذلك أبدًا

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

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

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

شهادتا الخادم والعميل تشيران في اتجاهين متعاكسين

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

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

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

مطالبتان تبدوان متطابقتين وليستا كذلك

المفتاح المخزّن بصيغة مشفرة يطلب عبارة مرور قبل أن يستخدمه العميل. وقد تطلب خدمة VPN كلمة مرور الحساب بشكل منفصل، وقد تظهر المطالبتان بفاصل ثوانٍ وبصياغة شبه واحدة. عبارة المرور تحمي ملفًا على قرصك؛ وكلمة المرور تثبت حسابًا لخادم. والخلط بينهما يدفع الناس إلى إعادة تعيين كلمات مرور لا يمكن أن تساعد.

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

حين تنتهي الشهادة فعلًا، يجب أن يأتي البديل ممن أصدرها. فمفتاح يخص شخصًا آخر ليس مسار تجديد، ولا استعارة ملف عامل من زميل كذلك.

ما تثبته المصافحة النظيفة وما لا تثبته

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

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