استخدم هيئة الشهادات المؤسسية الحالية لأقران OpenVPN

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

أصدر دورين بدل هوية واحدة مشتركة

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

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

وصّل مدخلات الثقة في كل جانب

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

client
ca /etc/openvpn/pki/issuing-root.pem
cert /etc/openvpn/pki/device-17.crt
key /etc/openvpn/pki/device-17.key
remote-cert-tls server
verify-x509-name vpn.corp.example name
crl-verify /etc/openvpn/pki/issuing.crl

يعكس جانب الخادم ذلك باستخدام remote-cert-tls client وشهادته الخاصة، وهذا ما يمنع قبول شهادة عميل بوصفها خادمًا. فحص الاسم قرار منفصل عن فحص الدور. اقرأ التكوين المنشور لمعرفة الحقل الذي يُقارن بدل افتراض مطابقة اسم مضيف على طراز المتصفح. وينبغي أن يكون الجانبان صريحين أيضًا بشأن المصدر الذي يثقان به، لأن مسار ملف مشترك عبر الأسطول ليس الشيء نفسه كسياسة مشتركة.

سلّم الشهادات الوسيطة دون توسيع الثقة

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

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

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

قرّر كيف يصل الإبطال فعليًا

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

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

أثبت القبول بعميل حقيقي

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

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