CMS सिंक और प्रमाणपत्र संचालन
1. अवलोकन
DAT CMS (Certificate Management Service) वह सर्वर है जो पूरे क्लस्टर द्वारा साझा किए जाने वाले प्रमाणपत्र बनाता और वितरित करता है।
प्रत्येक एप्लिकेशन 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 | स्थिति जाँच |
प्रतिक्रिया का मुख्य भाग एक सादा टेक्स्ट है जिसकी पहली पंक्ति सर्वर का वर्तमान 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 को आगे बढ़ाता है। यह इसलिए, ताकि विफल प्रतिक्रिया से कर्सर आगे बढ़ जाने पर प्रमाणपत्र हमेशा के लिए छूट जाने की स्थिति न बने।
अनुरोध वृद्धिशील है, पर प्रतिक्रिया पूर्ण प्रतिस्थापन है
?version=N का अर्थ है "N के बाद के परिवर्तन दीजिए", फिर भी क्लाइंट प्राप्त सूची को मौजूदा सूची में मिलाता नहीं, बल्कि प्रतिस्थापित (clear = true) कर देता है। ऐसा इसलिए कि सर्वर हमेशा सभी वैध प्रमाणपत्रों का निर्धारण करके भेजता है, और इसी तरीक़े की बदौलत CMS में निरस्त (revoke) किया गया प्रमाणपत्र क्लाइंट में बचा नहीं रहता।
2.3. प्रमाणीकरण टोकन
CMS तीन प्रकार के टोकन से एक्सेस को विभाजित करता है।
| टोकन | अधिकार |
|---|---|
Master टोकन | DAT प्रमाणपत्र बनाएं, सर्वर संस्करण देखें |
Full Cert टोकन | Full (Pair Key, Hash Key) प्रमाणपत्र GET करें |
Verify Cert टोकन | Verify (Verify Key Only) प्रमाणपत्र GET करें |
केवल सत्यापन करने वाले सर्वरों को सिद्धांततः केवल 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 प्रमाणपत्र का अपरिवर्तनीय पहचानकर्ता है। यदि एक ही 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 · बाइनरी परिनियोजन की विधियाँ और एनवायरनमेंट वेरिएबल अलग दस्तावेज़ में दिए गए हैं।