لماذا يفشل cryptoapicert في OpenVPN 3 و Connect على Windows

تنسخ ملف تعريف OpenVPN 2 عاملًا إلى عميل Windows أحدث، ولم تعد الشهادة التي كان العميل القديم يجدها بنفسه معروضة. السطر الذي جعل ذلك يعمل هو محدد خاص بـ Windows ينتمي إلى عميل Community 2، والتطبيق الأحدث برنامج مختلف بمسار اعتماد مختلف. وملف التعريف لم يتغير سوى ذلك السطر، وهذا بالضبط ما يجعل الفرق صعبًا في الرؤية.

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

ما يعنيه الخيار حيثما وُجد

في عميل Community OpenVPN 2 على Windows، يحدد cryptoapicert شهادة يجب أن يجدها العميل في مخزن شهادات Windows بدلًا من ملف. وهو تسهيل خاص بـ Windows، ويعمل لأن ذلك العميل يعرف كيف يسرد المخزن ويسلّم المفتاح الناتج إلى حزمة TLS الخاصة به. لذلك فإن التوجيه جزء من لغة تهيئة ذلك العميل، وليس خاصية من خصائص بروتوكول OpenVPN. ولا شيء في صيغة الإرسال يحمله.

انسخ السطر نفسه إلى تطبيق آخر وستكون قد نسخت كلمة قد يحللها البرنامج الجديد أو يتجاهلها أو يرفضها. فالتوجيه ليس ميزة بروتوكول، وهذا التوجيه ليس حتى ميزة لكل عميل يتحدث OpenVPN.

ما تتيحه المكتبة الأساسية بدلًا من ذلك

مكتبة OpenVPN 3 Core هي مكتبة تُضمّنها تطبيقات أخرى، وهي تتعامل مع بيانات الاعتماد الخارجية عبر واجهة برمجية بدلًا من البحث في المخزن. يوفّر التطبيق المُضمِّن سلسلة شهادات، ثم يطلب لاحقًا من المكتبة أن توقّع بمفتاح خارجي، فتعود المكتبة إلى التطبيق لتفعل ذلك. وهذا تصميم أعم، ويعني أن الواجهة الأمامية هي التي تقرر أي مزوّدين يوجدون. وفي معالجة الخيارات الخاصة بالمكتبة الأساسية يظهر cryptoapicert بين التوجيهات غير المنفَّذة، وهو ما يتسق مع هذا التقسيم للمسؤولية.

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

ما تفعله واجهة Windows الأمامية بدلًا من ذلك

يتبع OpenVPN Connect طريقًا مختلفًا: يقوم المشغّل باستيراد ملف PKCS#12 يحتوي على الشهادة ومفتاحها الخاص إلى OpenVPN Certificate Store أُنشئ لهذا الغرض، ثم يُسند الشهادة الخارجية إلى ملف التعريف. وهذه خطوة استيراد مقصودة، لا اكتشاف تلقائي لما يوجد في المخزن الشخصي. والتمييز مهم عندما يفترض أحدهم أن شهادة مثبَّتة لغرض آخر ستظهر ببساطة في قائمة العميل.

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

اختر مسارًا يوافق سياسة المفتاح

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

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

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