SoftEther ServerCertSet: استيراد السلسلة المجدَّدة باستخدام vpncmd

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

الملف المجدَّد لا يغيّر هوية الخادم

الإصدار والنشر حدثان منفصلان ولهما أنماط فشل منفصلة. يكتب عميل ACME الملفات في دليل نسل ويسجّل النجاح؛ ويواصل SoftEther استخدام الشهادة التي حُمّلت آخر مرة في إعداداته. لذا فإن حالة خروج صفرية تصف الملفات لا الخدمة، وقد يختلف الاثنان طالما لا ينظر أحد. تعامل مع الاستيراد كخطوة النشر ومع التجديد كمدخل لها.

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

اختر التحدي الذي يناسب المستمع

يجب أن تسمّي الشهادة المضيف الذي يتحقق منه العملاء، لذا استخدم اسم DNS العام بدلًا من تسمية داخلية أو عنوان. يحتاج HTTP-01 إلى الإجابة عن التحدي على المنفذ 80 لفترة وجيزة، وهو مستمع مؤقت وليس أبدًا سببًا لنقل منفذ SoftEther نفسه. أما DNS-01 فيثبت التحكم عبر سجل ولا يحتاج إلى أي HTTP وارد إطلاقًا.

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

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

استورد السلسلة على مستوى الخادم

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

ServerCertSet /LOADCERT:/etc/letsencrypt/live/vpn.example.com/fullchain.pem /LOADKEY:/etc/letsencrypt/live/vpn.example.com/privkey.pem

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

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

اربط النشر لا التجديد

بعد أن يعمل الاستيراد اليدوي، ضع تلك الخطوات بالضبط في غلاف صغير واستدعه من عميل ACME بعد تجديد ناجح. يضبط Certbot المتغيرين RENEWED_LINEAGE و RENEWED_DOMAINS للخطاف، فيستطيع الغلاف العمل على شهادة واحدة في جهاز يدير عدة شهادات. رشّح حسب السلسلة بدلًا من التفاعل مع كل تجديد على المضيف. الغلاف شيفرة نشر تعمل بامتيازات الخادم، فراجعه كأي سكربت آخر في هذا الموقع.

certbot renew --deploy-hook /usr/local/sbin/softether-deploy.sh

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

قارن السلسلة المعروضة بالملف

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

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts </dev/null 2>/dev/null | grep -c 'BEGIN CERTIFICATE'
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -dates -fingerprint -sha256

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