شهادة VPN مُجدَّدة: بعض العملاء ما زالوا يرفضونها
قد يحتفظ التجديد بالاسم ويغيّر الكائن. قارن ثقة CA وفحوص الاسم وتثبيتات العميل قبل قبول أي تحذير أمني.
يعود نصف الأجهزة إلى الاتصال بعد التجديد، وترفض ثلاثة أجهزة، كل منها بتحذير بشأن هوية البوابة. التجديد نفسه روتيني. ما تحتفظ به تلك الأجهزة الثلاثة هو تثبيت للكائن القديم، و التثبيت ليس قائمة CA ولا فحص اسم ولا إدخالاً في مخزن الثقة. قارن الآليات الثلاث قبل لمس أي عميل.
تجديد واحد، سلوكان
العملاء الذين يعيدون الاتصال لديهم قرار ثقة ما زال ينجح، والذين يرفضون لديهم شرط لا تحققه الشهادة الجديدة. هذا الفرق معلومة وليس ضجيجاً. اقرأ رسالة العميل الفاشل بدقة. عدم تطابق الاسم ومُصدر غير معروف وبصمة متغيّرة هي ثلاثة أحكام مختلفة، وآخرها فقط يشير إلى تثبيت.
تحقق أيضاً من الملف الشخصي الذي اختاره العميل الفاشل. النسخة المستوردة التي تعيش في مخزنها الخاص لا تتغير عندما يحرر المسؤول الملف الأصلي في مكان آخر.
التجديد يستبدل الكائن، لا التاريخ فقط
تحدد البصمة محتويات الشهادة المرمزة. ينتج التجديد شهادة جديدة، لذا تتغير البصمة حتى عندما يبقى اسم الموضوع والمفتاح العام متطابقين. هذا متوقع وغير ضار للعملاء الذين يثقون بـ CA ويتحققون من الاسم. وهو قاتل لعميل مُهيأ لقبول شهادة واحدة بالضبط، وهو أيضاً قاتل لعميل لم يتلقَّ مخزن ثقته المُصدر الجديد قط.
openssl x509 -in server.pem -noout -subject -issuer -dates -fingerprint -sha256
openssl x509 -in server.pem -noout -pubkey | openssl sha256
السطر الثاني يجيب عن سؤال مختلف: هل نجا زوج المفاتيح. التجديد الذي أعاد استخدام المفتاح يحتفظ بتلك القيمة ويغيّر الشهادة فقط، وهي بالضبط الحالة التي يُغرى فيها المسؤول بافتراض أن شيئاً لم يتغير. افحص الشهادة المنشورة، لا التي على مضيف البناء. مقارنة ملف في مستودع تثبت ما تم توليده، لا ما يعرضه المستمع حالياً.
اقرأ ما يثبته العميل
بعض العملاء يحتفظون ببصمة في ملفهم الشخصي ويقارنونها في كل اتصال. وآخرون يخزنونها في مخزن ثقة المنصة، وآخرون يعتمدون على CA فقط. يختلف الإصلاح في كل حالة، لذا حدد الآلية أولاً.
grep -n 'peer-fingerprint' /etc/openvpn/client/*.conf
openssl s_client -connect gw.lab.example.net:443 -servername gw.lab.example.net < /dev/null 2>&1 | openssl x509 -noout -fingerprint -sha256
الأمر الأول يُظهر تثبيتاً في ملف شخصي تقليدي؛ والثاني يُظهر البصمة التي تقدمها نقطة النهاية فعلياً الآن. عندما يختلف الاثنان، تكون قد حددت الفشل دون تخمين. لا تلصق القيمة الجديدة في كل عميل يشتكي. العميل الذي يرفض بسبب المُصدر سيبقى يرفض، وستكون قد علّمت نفسك أن البصمة كانت المشكلة حين لم تكن كذلك.
قارن الشهادة التي يقدمها كل خادم خلفي
النتائج المتقطعة تعني عادة أكثر من نقطة نهاية واحدة، والتجديد الذي طُبق على عقدة واحدة يترك الأخريات يقدمن الكائن القديم. قارن كل خادم خلفي بالعنوان بدلاً من الاسم المشترك.
for h in 10.30.0.11 10.30.0.12; do echo "$h"; openssl s_client -connect $h:443 -servername gw.lab.example.net < /dev/null 2>&1 | openssl x509 -noout -subject -dates -fingerprint -sha256; done
مجموعة تتخلف فيها عقدة واحدة تفسر عميلاً يتصل في المحاولة الثانية ويفشل في الأولى. وتفسر أيضاً فحص مراقبة ينجح بينما يشتكي المستخدمون. أصلح التخلف أولاً. دحرجة إعداد الثقة قبل أن تقدم كل عقدة الشهادة الجديدة تخلق نافذة لا يعمل فيها شيء، ودحرجتها بعد ذلك تترك العملاء يفشلون بشكل غير متوقع.
غيّر الثقة عبر المسار المُدار
أكّد الاستبدال عبر قناة إدارية موثوقة مسبقاً قبل قبوله في أي مكان. تاريخ انتهاء معقول ليس دليلاً على الملكية. حدّث الإعداد المُدار عبر العملية التي تملكه أياً كانت، مع أي تداخل مخطط لهويات مقبولة، واحتفظ بالتحقق من الاسم الذي يتطلبه النشر. تثبيت بلا فحص اسم تصميم أضعف من ثقة CA التي حلّ محلها.
ثم تحقق لكل عميل: اتصل، وأكّد الهوية التي قبلها، وسجّل إصدار الشهادة الذي يثق به الآن. التحذير الذي يُتجاهل مرة له طريقة في العودة عند التجديد التالي.