الخلاصة

  • في التبادل العادي لـ CMP عبر HTTP، يفرض RFC 9811 استجابة 200 OK تحمل رسالة CMP في المتن. نجاح الغلاف لا يقرر إن كانت العملية مقبولة أو ممنوحة بتعديلات أو مرفوضة أو قيد الانتظار.
  • يجب أن يربط السجل القابل للدفاع بين الجهة المقصودة وHTTP وPKIMessage المحمية وtransactionID والاستطلاع والتأكيد ومخزن المفاتيح والتحقق لدى الأنظمة المعتمدة، مع إبقاء معنى كل طبقة مستقلاً.

أخطر خطأ في أتمتة الشهادات قد لا يكون تنبيهاً أحمر، بل عبارة خضراء مبالغاً في معناها: 200 OK.

يحدد RFC 9811، المنشور ضمن مسار معايير IETF في يوليو 2025، طريقة نقل Certificate Management Protocol بواسطة HTTP. تُرسل PKIMessage مشفرة بصيغة DER في متن طلب POST مع النوع application/pkixcmp. وعندما ينجح طلب HTTP العادي، يعيد الخادم استجابة CMP في متن رد يحمل الرمز 200، ولا يجوز استخدام رمز نجاح 2xx آخر لهذا الغرض.

هذه الدقة لا تجعل HTTP جهة إصدار. إنها تثبت الإيصال الخارجي كي يبقى القرار داخل CMP.

نتيجتان في استجابة واحدة

يعرف RFC 9810 حالات منها accepted وgrantedWithMods وrejection وwaiting. لذلك قد يحمل HTTP 200 قبولاً مطابقاً للطلب، أو قبولاً بعد تغيير، أو رفضاً، أو معاملة لم تكتمل. تبدو كلها ناجحة في رسم HTTP، لكنها لا تسمح بالفعل التالي نفسه.

والخطأ المعاكس هو تجاهل المتن عند رؤية 4xx أو 5xx. يطلب RFC 9811 من العميل معالجة استجابة CMP إذا ظهرت داخل متن ردود 2xx أو 4xx أو 5xx. قد يجتمع خطأ خارجي مع تفسير داخلي محمي وقابل للربط بالمعاملة.

المسار الصحيح تراكمي: استلام رد HTTP، التحقق من النوع والحجم، فك DER، التحقق من حماية CMP والمرسل، ربط الرسالة بالمعاملة، ثم تفسير نوع المتن والحالة ومعلومات الفشل. نجاح خطوة يسمح بفحص التالية، ولا يثبت النهاية كلها.

غياب الرد يترك حالة غير محسومة

إذا لم يؤكد رد HTTP الاستلام، يفرض RFC 9811 افتراض أن رسالة CMP لم تُسلَّم بنجاح. هذه قاعدة نقل محافظة تمنع ادعاء التسليم بلا إيصال، لكنها لا ترى ما حدث داخل الخادم.

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

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

معاملة ذات حالة فوق نقل عديم الحالة

تحتاج بعض عمليات PKI إلى عدة أزواج من الطلبات والاستجابات. يمكن أن تكون كل رحلة HTTP مستقلة، بينما يجمع transactionID رسائل CMP في معاملة واحدة. بعد تثبيت قيمته، يجب أن تستخدمها الرسائل اللاحقة، ولا يجوز للعميل تشغيل معاملتين متزامنتين بالقيمة نفسها نحو الخادم نفسه.

يوصي RFC 9810 بـ128 بتاً شبه عشوائي عندما ينشئ العميل المعرّف. ويمكن للخادم فرض تفرد الزوج {client, transactionID} أو تفرد المعرّف وحده بحسب قدرته على تمييز العملاء. وإذا منع التضارب الربط الصحيح، تكون النتيجة transactionIdInUse.

الربط ليس مصادقة. لا يثبت الحقل هوية الطالب أو حقه في ملف شهادة أو سلامة الرسالة أو عدم تكرار الأثر التجاري. لحماية CMP وnonces ومعرّفات الطلب والسياسة المحلية سلطات مختلفة. ينبغي جمعها في ملف واحد من دون تحويل رقم تتبع إلى وثيقة تفويض.

للانتظار ساعته الخاصة

تعني waiting أن متن الطلب لم يُعالج بعد. يرسل العميل pollReq. وتعيد CA أو RA النتيجة النهائية إذا أصبحت جاهزة، وإلا تعيد pollRep مع checkAfter. ينتظر العميل المدة المحددة على الأقل قبل المحاولة التالية.

قد يكون السبب ضغط النظام الخلفي، أو نقلاً غير متصل بين جهات PKI، أو موافقة موظف في RA. انتهت رحلة الشبكة، لكن القرار المؤسسي بقي مفتوحاً.

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

قد لا ينتهي الأمر عند صدور الشهادة

يعرف RFC 9810 رسالة certConf كي يقبل العميل الشهادات المعادة أو يرفضها، ثم pkiconf لتأكيد الجهة وإغلاق التبادل. إذا غيرت CA حقولاً مطلوبة، فعلى الكيان النهائي فحص الشهادة الفعلية. لا تعني grantedWithMods إذناً بالتثبيت بلا مراجعة.

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

قد تسجل قاعدة الإصدار شهادة جديدة بينما يعرض موازن الحمل القديمة. وقد ينجح النشر بينما يرفض عميل مهم السلسلة أو الاسم أو الغرض أو المدة. وقد تعمل الخدمة مع فقدان تأكيد CMP. لحالة التشغيل وإغلاق البروتوكول إيصالان مختلفان.

للإعلانات عقد إيصال آخر

عند دفع إعلان عن مفتاح CA أو شهادة أو إبطال أو CRL، يصبح خادم CMP عميلاً لـHTTP، ولا يعيد المستلم رسالة CMP، بل استجابة HTTP فارغة.

يعني 201 Created أن المعلومة حُفظت أو كانت موجودة. ويعني 202 Accepted أنها قُبلت لمعالجة لاحقة فقط؛ يستطيع المرسل الانتظار والإعادة حتى يتأكد من المعالجة. لا يجوز نقل هذا المعنى إلى الطلب العادي الذي يحمل فيه 200 قرار CMP.

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

/.well-known/cmp مسار لا تفويض

يجب على خوادم CMP التي تدعم HTTP أو HTTPS قبول بادئة /.well-known/cmp. ويمكن لمقاطع لاحقة تمييز العملية أو CA أو ملف الشهادة. يسجل دليل IANA للـWell-Known URIs اللاحقة cmp كقيمة دائمة يديرها IETF.

يوحد المسار موضع السؤال داخل origin، لكنه لا يكتشف اسم المضيف الصحيح. يوضح RFC 8615 أنه لا يحدد اكتشاف المضيف، ويحذر من سلطة الموقع المعروفة على مستوى origin. يجب حفظ مصدر الإعداد، والحل، والتحويلات، ونظير TLS، ومرسل CMP المحمي، والسياسة التي تربط هذه الهويات.

يسمح RFC 9811 بدعم 3xx لكنه يدعو إلى الحذر قبل اتباعها آلياً. قد يحول 301 خبيث محفوظ العميل بعيداً عن الخادم الصحيح بصورة دائمة. لا ينبغي لسهولة HTTP أن تعيد كتابة نقطة الثقة سراً.

سجل للتسليمات لا خانة نجاح واحدة

يحفظ الملف الأدنى CA أو RA المتوقعة؛ URI المعدة والنهائية؛ التحويلات؛ هوية TLS؛ طريقة HTTP ورمزه ونوعه وبصمات المتن؛ مرسل CMP ومستلمه ونوع الرسالة وفحص الحماية؛ transactionID وnonces ومعرّف الطلب؛ PKIStatus والفشل وcheckAfter؛ بصمة الشهادة والفروق وcertConf وpkiconf؛ نسخة المخزن والتشغيل والتراجع؛ وملاحظات مستقلة من الخدمات المهمة.

ويحفظ الحدود أيضاً: لا رد يعني تسليماً غير مؤكد؛ 200 يعني وصول استجابة؛ الإصدار يعني إنشاء كائن؛ التثبيت يعني تغير حالة محلية؛ نجاح اتصال يعني قبول طرف محدد. لا تولد مرحلة المرحلة التالية تلقائياً.

يضع Running-Code Primacy الاختبار الأخير في العميل العامل وحالة CA/RA ومخزن المفاتيح والاتصال الحقيقي. ويدعم Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption طبقة مشتركة دقيقة وضيقة من دون ابتلاع سياسة الشهادة والنشر. ويمنع Reality Layers ضغط حقائق متعددة في إشارة خضراء واحدة.

لا يضعف RFC 9811 معنى 200 OK. بل يجعله صادقاً: نجح طلب HTTP ووصلت استجابة CMP. أما قرار الشهادة فما زال ينبغي قراءته في الداخل.

المصادر