CMS ہم آہنگی اور سرٹیفکیٹ آپریشن ​

1. جائزہ ​

DAT CMS (Certificate Management Service) ایک ایسا سرور ہے جو پورے کلسٹر کے مشترکہ سرٹیفکیٹس تیار اور تقسیم کرتا ہے۔

ہر ایپلیکیشن CMS کلائنٹ (DatCmsManager) کے ذریعے وقتاً فوقتاً سرٹیفکیٹس کی فہرست حاصل کرتی ہے، اور یہی ہم آہنگی کی رولنگ کو خودکار بناتی ہے۔ منتظم کے ہاتھ سے کی تبدیل کیے بغیر ہی سرٹیفکیٹس مقررہ وقفے سے نئے بنتے رہتے ہیں اور پرانے خود بخود ختم ہو جاتے ہیں۔

اجرا کے قابل سرٹیفکیٹ صرف لاگ ان سرور کو ملتے ہیں؛ کنٹینٹ سرورز کو صرف تصدیقی سرٹیفکیٹ ملتے ہیں۔ کنٹینٹ سرور کو صرف CMS کا علم ہونا کافی ہے، اسے لاگ ان سرور کا علم ہونا ضروری نہیں۔

2. ہم آہنگی کا پروٹوکول ​

2.1. درخواست اور جواب ​

جواب کے باڈی کی پہلی سطر سرور کا موجودہ version ہوتی ہے، اور اس کے بعد ہر سطر میں ایک سرٹیفکیٹ سادہ متن کی شکل میں ہوتا ہے۔

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. ورژن کرسر ​

کلائنٹ آخری کامیاب version یاد رکھتا ہے اور اگلی درخواست کے ساتھ بھیج دیتا ہے۔ سرور صرف اس قدر سے نئے سرٹیفکیٹس چھانٹ کر واپس کرتا ہے۔

• اگر کلائنٹ کا version سرور سے پرانا ہو → اس کے بعد بننے والے سرٹیفکیٹس ہی واپس کیے جاتے ہیں۔
• اگر کلائنٹ کا version سرور سے آگے ہو (سرور کی تبدیلی، DB ری سیٹ وغیرہ) → کرسر کو 0 پر واپس کر کے مکمل سیٹ واپس کیا جاتا ہے۔
• کلائنٹ صرف امپورٹ کامیاب ہونے کی صورت میں version آگے بڑھاتا ہے۔ مقصد یہ ہے کہ ناکام جواب سے کرسر آگے بڑھ کر سرٹیفکیٹس ہمیشہ کے لیے ضائع نہ ہو جائیں۔

2.3. توثیقی ٹوکنز ​

CMS تین قسم کے ٹوکنز سے رسائی کو تقسیم کرتا ہے۔

اصول یہ ہے کہ صرف تصدیق کرنے والے سرورز کو محض Verify Cert ٹوکن دیا جائے۔ البتہ انکرپشن کی verify-only جواب میں بھی شامل ہوتی ہے، اس لیے اس کے مفہوم کے بارے میں سرٹیفکیٹ دستاویز میں دی گئی احتیاطی ہدایات بھی ضرور دیکھیں۔

3. سرٹیفکیٹ کے اجراء میں تاخیر (delay) ​

اگر نیا سرٹیفکیٹ بنتے ہی اجراء کے لیے استعمال کر لیا جائے تو جو نوڈ ابھی ہم آہنگ نہیں ہوا، وہ اس سرٹیفکیٹ سے دستخط شدہ ٹوکن کی تصدیق نہیں کر سکے گا۔ اجراء کی تاخیر اسی وقفے کو ختم کرنے کے لیے ہے۔

مثال کے طور پر فرض کریں کہ CMS سرٹیفکیٹ A بناتا ہے اور سرور 1 اور 2 ہر 60 سیکنڈ کے وقفے سے ہم آہنگ ہوتے ہیں۔ اگر سرور 1 نے پہلے حاصل کر کے A سے DAT جاری کر دیا اور سرور 2 نے ابھی تک حاصل نہیں کیا، تو سرور 2 اس DAT کی تصدیق نہیں کر سکے گا۔

اگر تاخیر 180 سیکنڈ رکھی جائے تو سرٹیفکیٹ کی تخلیق کے بعد 180 سیکنڈ تک اجراء ناممکن رہتا ہے، اور اسی دوران تمام سرورز محفوظ طریقے سے ہم آہنگی مکمل کر لیتے ہیں۔ عارضی نیٹ ورک خرابیوں کو مدنظر رکھتے ہوئے یہ قدر ہر سرور کے ہم آہنگی وقفے سے کم از کم 3 تا 4 گنا زیادہ رکھنے کی سفارش کی جاتی ہے۔

4. ارادی رویہ ​

نیچے دیے گئے تمام رویے ڈیزائن کے مطابق ارادی ہیں، خرابیاں نہیں۔ آپریشن کے دوران یہ توقع سے مختلف دکھائی دے سکتے ہیں، اس لیے انہیں واضح طور پر بیان کیا جا رہا ہے۔

4.1. اجراء کی کھڑکی بند ہونے کے بعد بھی کیشڈ سرٹیفکیٹ سے دستخط جاری رہتے ہیں ​

ایپلیکیشن ہم آہنگی کے وقت چنے گئے اجراء والے سرٹیفکیٹ کو استعمال کرتی رہتی ہے اور ہر اجراء پر دوبارہ issuable() کی جانچ نہیں کرتی۔

وجہ: اگر CMS سے رابطہ منقطع ہونے کی حالت میں اجراء کی کھڑکی بند ہو جائے تو دوبارہ جانچ والے طریقے میں اسی لمحے پوری سروس کا لاگ ان رک جاتا ہے۔ DAT نے اس صورت میں "نیا سرٹیفکیٹ نہ ملنے کے باوجود فی الحال اجراء جاری رکھو" کا انتخاب کیا ہے۔

قیمت: نیٹ ورک کی خرابی لمبی ہو جائے تو ایسے سرٹیفکیٹ سے بھی ٹوکن نکلتے رہ سکتے ہیں جس کی اجراء کی کھڑکی گزر چکی ہو۔ البتہ وہ ٹوکن بھی سرٹیفکیٹ کی حتمی میعاد ختم ہونے تک دوسرے نوڈز پر بخوبی تصدیق ہوتا رہتا ہے، اس لیے یہ طے کیا گیا کہ خرابی کی حالت میں سروس کے مکمل بند ہو جانے سے یہ ٹریڈ آف بہتر ہے۔

4.2. وہی 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 · بائنری ڈیپلائمنٹ کے طریقے اور ماحولیاتی متغیرات الگ دستاویز میں بیان کیے گئے ہیں۔

• سرٹیفکیٹ منیجر ڈیپلائمنٹ گائیڈ