شهادة IKEv2 وSAN: لماذا يفشل فحص الهوية
شهادة IKEv2 صالحة تفشل مع ذلك عندما لا تتوافق الهوية المتوقعة ونوع SAN. طابق DNS مع DNS وIP مع IP، وافحص ملف التعريف أولاً.
سلسلة شهادتك تعود إلى جهة إصدار موثوقة، والتواريخ سليمة، ومع ذلك يرفض النظير إكمال المرحلة 1 بخطأ في الهوية. الوصول القابل للتحقق والتوقيع الصالح هما نصف ما يفحصه عميل IKEv2 فقط. النصف الآخر هو ما إذا كانت الهوية التي يتوقعها تظهر في الحقل الصحيح داخل الشهادة، وهذا التوقع يحدده ملف التعريف لا اسم ملف الشهادة.
العرض دائماً بالشكل نفسه
يُغيَّر ملف اتصال من اسم مضيف إلى عنوان IP، أو يُجدَّد من شهادة تحمل اسم DNS إلى شهادة تحمل عناوين فقط، ويتوقف النفق عن التفاوض. لم يتغير شيء في مسار الشبكة. يصل العميل إلى النظير ويتلقى شهادة ويرفض هوية النظير لأن المعرّف الذي طُلب منه توقعه غير ممثل في حقل يقبله. التجديدات هي المُحفِّز المعتاد، لأن شهادة الاستبدال غالباً تأتي من قالب مختلف عن الذي تحل محله.
يسجّل الطرفان بعد ذلك شيئاً غير مفيد، ولهذا يُبلَّغ عن الفشل عادةً كمشكلة شهادة. قد يذكر سجل العميل الهوية التي أرادها، وهذا الاسم هو الدليل الذي تريده لا تاريخ الانتهاء.
طابق نوع المعرّف لا القيمة وحدها
حقل dNSName في SAN وحقل iPAddress في SAN حقلان مختلفان بقواعد مطابقة مختلفة، فشهادة تحمل 203.0.113.10 كسلسلة DNS لا تُرضي عميلاً يتوقع هوية IP. يتجاهل المدققون الحديثون الاسم الشائع إلى حد كبير، فالاسم الودود في تفاصيل الشهادة لا يثبت شيئاً عما سيطابق. إذا استُبدل اسم مضيف بعنوان أثناء استكشاف الأخطاء، فافترض أن الهوية المتوقعة انتقلت معه حتى تتحقق. قارن السلسلة في ملف التعريف بالسلسلة في SAN حرفاً بحرف، لأن نقطة زائدة أو مسافة عابرة تكفي.
أحرف البدل تسهيل خاص بـ DNS وتتبع قواعد مطابقة خاصة بها، وهذا سبب آخر يمنع ملفاً معتمداً على IP من الاعتماد عليها أبداً.
اعرف أين يخزّن كل عميل التوقع
في strongSwan تأتي القيمة المقارنة بالشهادة من إعداد هوية النظير: rightid في التكوين الكلاسيكي، أو id في قسم اتصال بعيد داخل swanctl. وثائق التوافق مع Apple IKEv2 مفيدة هنا لأنها توضح اصطلاحات الهوية التي يستخدمها عميل يقوده ملف تعريف، وتلك الاصطلاحات تفسر صنفاً من عدم التطابق يبدو عشوائياً على الشبكة.
تحمل ملفات تعريف Apple حقلاً لمعرّف الطرف البعيد، والقيمة هناك هي ما يفحصه العميل لا عنوان الخادم في إعدادات الاتصال. ولكل من Windows والأجهزة حقل خاص به وقيمة افتراضية خاصة، والافتراضي غالباً يتبع العنوان الذي كتبته. وحين يختلف حقلان، يفوز الحقل الذي يقرأه العميل فعلاً، وهو نادراً ما يكون الحقل الذي حرّرته.
أصلح ملف التعريف أو الشهادة عن قصد
افحص شهادة النظير بأدوات معتمدة وأدرج إدخالات SAN مع أنواعها قبل تغيير أي شيء. هذا الفحص لا يحتاج مفتاحاً خاصاً ولا رفعاً، ويحسم المسألة في ثوان. إذا كان النشر يقصد هوية DNS واحدة، فيجب أن تحملها الشهادة كإدخال dNSName، وإذا كان يقصد عنواناً، فتحتاج الشهادة إلى إدخال iPAddress لذلك العنوان بالضبط.
حين تكون الشهادة خاطئة، اطلب من المشغّل شهادة مصححة بالمعرّف المتوقع المحدد. وحين يكون ملف التعريف خاطئاً، أصلح الملف واترك الشهادة كما هي. تعطيل التحقق من الهوية يجعل الخطأ يختفي ويزيل الفحص الذي يؤكد أن النفق يتحدث إلى النظير الذي تقصده.
وثّق الهوية المتوقعة لكل منصة عميل، لأن قيمة يستنتجها عميل تلقائياً قد تحتاج إلى أن تكون صريحة على عميل آخر.
أعطِ طلب التجديد أربع حقائق
اكتب المعرّف المتوقع ونوعه، وإدخالات SAN التي تحملها الشهادة الحالية فعلاً، والعميل والإصدار الذي يقوم بالفحص، ونص الخطأ الحرفي. طلب تجديد مبني على تلك الأسطر الأربعة يحصل على الشهادة الصحيحة من المرة الأولى، بدل شهادة أخرى بالاسم المألوف نفسه.