شهادة CA موقّعة تبادليًا: المفتاح متطابق، لكن ارتباط AKI ليس كذلك

يمكن أن تحمل شهادتا CA المفتاح العام نفسه والموضوع نفسه ومع ذلك لا تكونان قابلتين للتبادل. إحداهما موقّعة ذاتيًا، والأخرى موقّعة تبادليًا بواسطة الجذر القديم، وتختلف أسماء المُصدر والأرقام التسلسلية والتوقيعات بينهما. يمكن للورقة أن ترتبط بإحداهما تحديدًا عبر معرّف مفتاح المُصدر (Authority Key Identifier). يبقى ذلك الارتباط غير مرئي حتى يختار العميل السلسلة الخاطئة وتفشل المصافحة دون سبب واضح.

نفّذ هذه الفحوص الخمسة بالترتيب: كل واحد منها يستبعد نوعًا مختلفًا من الفشل.

الفحص 1: ارسم السلسلتين قبل لمس القالب

دوّن المسارات. الفئة القديمة تثق بالجذر القديم A، الذي أصدر CA B، الذي أصدر ورقة الخادم. الفئة الجديدة تثق بـ CA B الموقّعة ذاتيًا مباشرة. تحمل شهادتا B المفتاح والموضوع نفسهما، وهذا بالضبط سبب رؤية من يقرأ سطر الموضوع شهادة CA واحدة حيث يرى العميل اثنتين.

يجب أن تكون النسخة الموقّعة تبادليًا شهادة CA حقيقية أيضًا، مع basic constraints وkey usage يسمحان بالتوقيع.

الفحص 2: قارن حقول AKI، لا المفتاح وحده

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

افحص الورقة بدلًا من التخمين: openssl x509 -in server.pem -noout -ext authorityKeyIdentifier.

ثم قارن المرشحين مع openssl x509 -in b-cross.pem -noout -text | grep -A2 "Authority Key Identifier"، ونفّذ الأمر نفسه على النسخة الموقّعة ذاتيًا.

إذا كانت الورقة تحمل المُصدر والرقم التسلسلي، فلن تُكمل السلسلة إلا الشهادة التي تصفها تلك القيم، أيًا كانت النسخة التي حمّلها العميل.

الفحص 3: غيّر سياسة الإصدار، لا البايتات الموقّعة أبدًا

تعيش الامتدادات داخل التوقيع. إضافة أحدها أو حذفه أو تعديله على ورقة قائمة ليس إصلاحًا، بل شهادة مختلفة، وتحتاج إلى إعادة إصدار. التغيير مكانه سياسة الإصدار: authorityKeyIdentifier = keyid,issuer:always يجعل الأوراق الجديدة تحمل الارتباط الخاص بالشهادة، بينما keyid وحده يحفظ الصيغة الأكثر مرونة التي تناسب انتقالًا متعمّدًا للتوقيع التبادلي. قرّر أيّهما تريده بنيتك PKI قبل توقيع الدفعة التالية.

تعديل قالب مشترك يغيّر أيضًا كل شهادة مستقبلية، وليس الخادم الذي أمامك فقط.

الفحص 4: تحقّق من كل فئة ثقة على حدة

اختبر المسار القديم والمسار الجديد كعمليتين منفصلتين. openssl verify -purpose sslserver -verify_hostname vpn.example -CAfile old-root.pem -untrusted b-cross-signed.pem server.pem يمارس المسار الموقّع تبادليًا، والأمر نفسه مع الجذر الجديد ودون ملف untrusted يمارس المسار الموقّع ذاتيًا. خلط الجذرين في حزمة واحدة يخفي أي سلسلة اختيرت. أعد الاختبار بعد ذلك مع عملاء حقيقيين، لأن خادم VPN الخلفي قد يفضّل سلسلة أو يثبّت شهادة بطرق لا يفعلها openssl.

سلّم الشهادة الوسيطة عبر إعداد الخدمة الذي يقرأه العميل فعليًا، لا عبر صفحة ويكي.

الفحص 5: أبقِ المسار القديم على ساعة إحالة للتقاعد

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

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