توقيعان في IKEv2: الشهادة وIKE_AUTH
توقّع الجهة المُصدرة الشهادة، ويوقّع النظير تبادل IKE_AUTH بمخطط خاص به. اقرأ كل توقيع من حقله، ثم سجّل الاثنين.
تقول تذكرتك إن الشهادة بخوارزمية SHA-256 بينما يسجّل سجل البوابة خوارزمية توقيع مختلفة، وقد صاغ أحدهم بالفعل طلبًا لإعادة إصدار CA. قبل أن يذهب ذلك الطلب إلى أي مكان، افصل التوقيعين: أحدهما بصمة الجهة المُصدرة على مفتاح عام، والآخر هو إثبات النظير أنه يحمل المفتاح الخاص المطابق أثناء IKE_AUTH. مكوّنات مختلفة تختارها، ويُسمح لها أن تختلف. وقراءة كل واحد من موضعه تتطلب أمرين وجدولًا واحدًا.
اقرأ توقيع الجهة المُصدرة من الشهادة
تضع CA توقيعها على ارتباط بين هوية ومفتاح. يسجّل ذلك التوقيع ما فعلته CA عند الإصدار، لا ما سيفعله الموضوع عند الاتصال، لذا تصف خوارزميته اختيار CA الخاص بالتجزئة والمفتاح. يمكن أن يستقر مفتاح موضوع من نوع تحت مفتاح CA من نوع آخر دون أي تناقض، وتدوير مفتاح CA إجراء روتيني لا عطل. اقرأ الحقلين وستحصل على نصف الجرد:
openssl x509 -in peer.pem -noout -text | grep -E "Signature Algorithm|Public Key Algorithm"سجّل التسميتين كمدخلين منفصلين. الأولى تصف CA، والثانية تصف مفتاح الموضوع، ولا واحدة منهما تتنبأ بالتوقيع المباشر.
اقرأ التوقيع المباشر من تبادل IKE
أثناء المصادقة يوقّع كل نظير بيانات التبادل بمفتاحه الخاص، ويتحقق الطرف الآخر من ذلك الإثبات مقابل هوية الشهادة وسلسلة الثقة والسياسة. في RSA تنتمي الحشوة والتجزئة إلى هذا المخطط المباشر، لذا لا يمكن لمفتاح أطول أو شهادة SHA-256 جديدة أن تختار RSA-PSS لتوقيع المصادقة من تلقاء نفسها. تظهر الطريقة المتفاوض عليها في سجل الخدمة أو في قائمة اتصالاتها، لا في الشهادة أبدًا. اسأل كل طرف عمّا تفاوض عليه، لأن الاتجاهين قد يختلفان.
ipsec statusall | grep -i "auth\|proposal"حين يسمّي أحد الطرفين مخططًا لا يستطيع الآخر إنتاجه، فقد وجدت عدم التطابق الذي كانت التذكرة عنه. وإعادة إصدار CA هي الإصلاح الخاطئ له، لأن الشهادة لم تكن أبدًا هي ما فشل.
ما يغيّره RFC 7427 وما لا يغيّره
الطرق الأصلية مرقّمة حسب كل توليفة خوارزميات في RFC 7296. أما امتداد التوقيع في RFC 7427 فيضيف طريقة Digital Signature عامة مع إشارات دعم تجزئة التوقيع، بحيث لم تعد التجزئة الجديدة تحتاج رقم طريقة خاصًا بها. يُتفاوض عليه ولا يُفترض: فالنظير لا يكسب الامتداد لأن مكتبته تستطيع تحليل الشهادات نفسها، والنظير الذي ينفّذ الطرق الأصلية فقط يفرض على البوابة الاحتفاظ بواحدة منها. تلك مقايضة في السياسة بتكلفة توافق، لا عيب.
الدعم لكل اتجاه ولكل اتصال، لذا اختبر البناء الذي أمامك بدل الثقة بادعاء على مستوى عائلة كاملة. مصفوفة قدرات كُتبت قبل ثلاث سنوات تصف بناءات عمرها ثلاث سنوات.
ضع أربعة صفوف في الجرد
السجل الذي ينهي الجدال فيه أربعة أسطر، كل منها مقروء من موضع مختلف ومغيّر بواسطة شخص مختلف. املأه قبل أن تقرر أي شيء، لأن الصف الخاطئ هو ما يختار الإصلاح.
| العنصر | اقرأه من | يغيّره |
|---|---|---|
| توقيع مُصدر الشهادة | حقل Signature Algorithm في الشهادة | مشغّل CA، عند الإصدار |
| المفتاح العام للموضوع | حقل Public Key Algorithm في الشهادة | من يولّد مفتاح الموضوع |
| مخطط مصادقة IKE | سجل الخدمة أو قائمة الاتصالات، إشعار auth وتجزئة التوقيع | ملف IKE على كلا النظيرين |
| خوارزميات حماية IKE وESP | قائمة مقترحات الاتصال | ملف IPsec، لكل اتجاه |
يحمل كل صف نتيجته التوافقية. تغيير شيفرة ESP لا يختار توقيع المُصدر، وتخفيف التحقق من CA لا يضيف طريقة مباشرة لم يتفاوض عليها النظيران. وعندما تدّعي تذكرة عدم تطابق في التوقيع، فالصف الخاطئ فعلاً ليس الأول تقريبًا أبدًا.
احسم حالة القديم دون إضعاف PKI
قد لا يقدّم نظير أقدم سوى مخطط لم تعد سياستك تسمح به. الخيارات هي استثناء توافق محدّد زمنيًا، أو تحديث العميل، أو ترتيب مصادقة مختلف لذلك النظير وحده. وإعادة بناء PKI حول توقيع شهادة أضعف لا تصلح قصورًا في التبادل المباشر، وتُضعف كل خدمة أخرى تثق بـ CA نفسها. سجّل أي صف غيّرت ومتى ينتهي الاستثناء.
ثم أعد إجراء القراءتين من الأعلى، لأن تغييرًا في صف قد يزحزح ما يُتفاوض عليه في صف آخر. والجرد كله أمران وجدول واحد، وهو العمل نفسه سواء كان النظير موجهًا أو حاسوبًا محمولًا أو جهازًا.