مزامنة CMS وتشغيل الشهادات
1. نظرة عامة
DAT CMS (Certificate Management Service) هو الخادم الذي يُنشئ الشهادات المشتركة على مستوى المجموعة (Cluster) وينشرها.
يستلم كل تطبيق قائمة الشهادات دورياً عبر عميل CMS (DatCmsManager)، وهذه المزامنة هي ما يؤتمت تدوير المفاتيح. فحتى دون أن يبدّل المشغّل المفاتيح يدوياً، تُنشأ الشهادات من جديد وفق دورة محددة وتنتهي القديمة تلقائياً.
خادم تسجيل الدخول وحده يتلقى شهادات صالحة للإصدار، أما خوادم المحتوى فتتلقى شهادات للتحقق فقط. يكفي أن يعرف خادم المحتوى CMS فقط، ولا حاجة لأن يعرف خادم تسجيل الدخول.
2. بروتوكول المزامنة
2.1. الطلب والاستجابة
| نقطة النهاية | الغرض |
|---|---|
GET /v1/certs?version=N | الشهادة الكاملة (تتضمن مفتاح التوقيع الخاص) |
GET /v1/certs/verify-only?version=N | شهادة التحقق فقط |
GET /v1/certs.json, /v1/certs/verify-only.json | المحتوى نفسه بصيغة JSON |
POST /v1/cert/{sig-alg}/{crypto-alg}/{delay}/{duration}/{ttl} | إنشاء شهادة يدوياً (يتطلب رمز Master) |
GET /health | فحص الحالة |
جسم الاستجابة نص عادي، سطره الأول هو النسخة الحالية للخادم، ثم تأتي الشهادات ابتداءً من السطر التالي بواقع شهادة في كل سطر.
1712345678
1a.1712345000.3600.1800.ECDSA-P256.IV-AES256-GCM.<sig-key>.<crypto-key>
2b.1712348600.3600.1800.ECDSA-P256.IV-AES256-GCM.<sig-key>.<crypto-key>2.2. مؤشر النسخة
يحفظ العميل آخر نسخة نجحت ويرسلها مع الطلب التالي. ويعيد الخادم الشهادات الأحدث من تلك القيمة فقط.
- إذا كانت نسخة العميل أقدم من الخادم ← يعيد الشهادات التي أُنشئت بعدها فقط.
- إذا كانت نسخة العميل أحدث من الخادم (استبدال خادم، تهيئة قاعدة بيانات، إلخ) ← يعيد المؤشر إلى
0ويرسل المجموعة الكاملة. - لا يقدّم العميل النسخة إلى الأمام إلا عند نجاح الاستيراد. والهدف منع انتقال المؤشر باستجابة فاشلة، مما يؤدي إلى فقدان الشهادات إلى الأبد.
الطلب تزايدي لكن الاستجابة استبدال كامل
?version=N طلب معناه "أعطني التغييرات بعد N"، لكن العميل لا يدمج القائمة المستلمة مع القائمة القائمة بل يستبدلها (clear = true). والسبب أن الخادم يحدد دائماً مجموعة الشهادات الصالحة كاملةً ويرسلها، وبفضل هذا الأسلوب لا تبقى لدى العميل شهادة سُحبت (revoke) من CMS.
2.3. رموز المصادقة
يقسّم CMS الوصول عبر ثلاثة أنواع من الرموز.
| الرمز | الصلاحية |
|---|---|
رمز Master | إنشاء شهادة DAT، عرض إصدار الخادم |
رمز Full Cert | GET شهادة Full (Pair Key, Hash Key) |
رمز Verify Cert | GET شهادة Verify (Verify Key Only) |
القاعدة أن تُمنح خوادم التحقق فقط رمز Verify Cert. غير أن مفتاح التشفير يُدرج أيضاً في استجابة verify-only، ولمعرفة دلالة ذلك راجع التنبيهات الواردة في مستند الشهادة.
3. تأخير إصدار الشهادة (delay)
إذا استُخدمت الشهادة الجديدة في الإصدار فور إنشائها، فلن تستطيع العقد الأخرى التي لم تتزامن بعد التحقق من الرموز الموقّعة بها. وتأخير الإصدار قيمة وُضعت للقضاء على هذه الفجوة.
لنفترض مثلاً أن CMS أنشأ الشهادة A وأن الخادمين 1 و2 يتزامنان بدورة 60 ثانية. إذا استلمها الخادم 1 أولاً وأصدر بها DAT بينما لم يستلمها الخادم 2 بعد، فلن يستطيع الخادم 2 التحقق من ذلك الـ DAT.
وبضبط التأخير على 180 ثانية، تبقى الشهادة غير قابلة للإصدار لمدة 180 ثانية بعد إنشائها، وخلالها تُتم جميع الخوادم مزامنتها بأمان. ومراعاةً لأعطال الشبكة العارضة، يُوصى بضبط هذه القيمة على ما لا يقل عن 3 إلى 4 أضعاف دورة المزامنة لكل خادم.
4. السلوكيات المقصودة
جميع السلوكيات التالية مقصودة في التصميم وليست عيوباً. ونذكرها صراحةً لأنها قد تبدو مخالفة للتوقعات أثناء التشغيل.
4.1. يستمر التوقيع بالشهادة المخزَّنة مؤقتاً حتى بعد إغلاق نافذة الإصدار
يواصل التطبيق استخدام شهادة الإصدار التي اختارها وقت المزامنة، ولا يعيد فحص issuable() عند كل إصدار.
السبب: إذا أُغلقت نافذة الإصدار أثناء انقطاع الاتصال بـ CMS، فإن أسلوب إعادة الفحص يوقف تسجيل الدخول في الخدمة بأكملها في تلك اللحظة. وقد اختار DAT في هذه الحالة مبدأ "واصل الإصدار حتى لو لم تستلم شهادة جديدة".
الثمن: إذا طال عطل الشبكة، فقد تستمر الرموز في الخروج بشهادة تجاوزت نافذة إصدارها. غير أن تلك الرموز تظل تُتحقق بشكل سليم في العقد الأخرى حتى الانتهاء النهائي للشهادة، ولذلك اعتُبرت هذه مقايضة أفضل من توقف الخدمة أثناء العطل.
4.2. تُهمَل الشهادة المحدَّثة التي تحمل نفس CID
إذا وردت شهادة تحمل نفس CID لشهادة موجودة بالفعل، تُتجاهل الشهادة الواردة حديثاً.
السبب: CID معرّف ثابت للشهادة. فإذا صار CID واحد يشير إلى مفاتيح مختلفة، لن يُعرف بأي مفتاح يجب التحقق من الرموز التي أُصدرت وما زالت متداولة.
تبديل المفاتيح يكون بـ CID جديد دائماً
إذا نشرت مفتاحاً جديداً مع الإبقاء على نفس CID، فإنه لن ينعكس لدى العميل أبداً ولن يظهر أي خطأ. عند تبديل المفاتيح أصدر شهادة بـ CID جديد.
4.3. عند عدم وجود شهادات جديدة تبقى القائمة الحالية
إذا لم تتضمن الاستجابة أي شهادة، يُبقي العميل قائمته كما هي. ولا يفرّغها.
السبب: إذا أُفرغت الشهادات المحفوظة في أسوأ لحظة، أي عند سقوط خادم الشهادات أو عند استجابة غير سليمة، فستفشل جميع عمليات التحقق من الرموز فوراً. فالأأمن هو الصمود بما هو موجود عند عدم استلام أي جديد.
4.4. وضع SINGLE_NODE يُنشئ شهادة عند كل إقلاع
عند تشغيل CMS في وضع العقدة الواحدة، يُنشئ شهادة واحدة عند كل إقلاع بغض النظر عن وجود شهادة قابلة للإصدار.
السبب: وضع العقدة الواحدة تكوين يهدف إلى تشغيل CMS بشكل مستقل دون بنية تحتية منفصلة. ولذلك يجب أن تتوفر شهادة قابلة للإصدار فور الإقلاع مباشرة.
تنبيه: تتراكم الشهادات إذا تكرر إعادة التشغيل. غير أن كل شهادة تُستبعد من القائمة بعد تجاوز وقت انتهائها، فلا يزداد العدد بلا حدود.
4.5. عند عدم وجود شهادة قابلة للإصدار يتم الإصدار فوراً دون تأخير
إذا لم تكن هناك أي شهادة قابلة للإصدار لحظة إنشاء الشهادة، فإن CMS يتخطى مرحلة التأخير ويضم مدة التأخير إلى مدة الإصدار.
السبب: الالتزام بالتأخير يعني أن المجموعة بأكملها لن تصدر أي رمز خلال تلك المدة. وفي حالات الإقلاع الأول أو التعافي من عطل شامل يجب أن يكون الإصدار ممكناً فوراً. ويُسجَّل تحذير في سجل الخادم في هذه الحالة.
5. سحب الشهادات وانتهاؤها
- تبقى الشهادة في قائمة النشر حتى لحظة انتهائها النهائي (
start + duration + ttl). ولا تختفي فور إغلاق نافذة الإصدار. - الـ DAT الذي خرج قُبيل نهاية نافذة الإصدار يبقى حياً بمقدار TTL الخاص به، ولذلك يستطيع حتى خادم التحقق الذي أقلع لأول مرة بعد تلك اللحظة أن يستلم الشهادة ويتحقق من ذلك الرمز.
- تُستبعد الشهادة التي تجاوزت انتهاءها النهائي من القائمة، ثم تُحذف من المخزن أيضاً في عملية التنظيف اللاحقة.
6. النشر
تُعالَج خيارات تشغيل خادم CMS وطرق النشر عبر Docker وKubernetes والملف الثنائي ومتغيرات البيئة في مستند منفصل.