सेटअप के निर्देशों में कहीं, एक पूरी डायरेक्टरी हर लैपटॉप पर ज्यों की त्यों कॉपी कर दी जाती है, क्योंकि यह तय करने से आसान था कि उसमें कौन-सी फ़ाइलें रहनी चाहिए। उस डायरेक्टरी में ca.key है, और जैसे ही वह दूसरे डिवाइस तक पहुँचता है, प्रमाणपत्र प्राधिकरण प्राधिकरण नहीं रह जाता। अब कोई भी धारक ऐसी पहचान जारी कर सकता है जिन पर बाकी नेटवर्क भरोसा करेगा।

इस उलझन को एक बार सुलझाना उचित है, क्योंकि दोनों फ़ाइलें दिखने में समान और काम में उलटी हैं।

सत्यापन सामग्री और हस्ताक्षर सामग्री

क्लाइंट को CA का सार्वजनिक प्रमाणपत्र चाहिए ताकि वह जाँच सके कि सामने वाले पक्ष द्वारा प्रस्तुत प्रमाणपत्र उसी प्राधिकरण ने हस्ताक्षरित किया है। यह सत्यापन का काम है और इसमें किसी रहस्य की आवश्यकता नहीं है। किसी साथी के प्रमाणपत्र पर हस्ताक्षर करना दूसरा काम है, जो CA चलाने वाला एक बार करता है, उस निजी कुंजी से जो कभी अपने संरक्षित भंडार से बाहर नहीं जाती। इन दोनों कामों को अलग रखना ही दो फ़ाइलें भेजने का पूरा उद्देश्य है।

इसलिए ca.crt प्रोफ़ाइल में आता है और ca.key उसके क़रीब कहीं नहीं आता। फ़ाइल के नाम एक परंपरा हैं, गारंटी नहीं, इसलिए प्रकार को नाम से अनुमान लगाने के बजाय जाँचना पड़ता है।

मध्यस्थ CA या ऑनलाइन जारीकरण सेवा वाली संरचना इसका अपवाद नहीं है। बड़े पैमाने पर डिवाइस प्रमाणपत्र जारी करते हुए हस्ताक्षर क्षमता को अंतिम बिंदुओं से दूर रखने का यही मानक तरीका है।

क्लाइंट को अपनी कुंजी से क्या सिद्ध करना चाहिए

हर डिवाइस को अपनी कुंजी-जोड़ी और अपना प्रमाणपत्र मिलता है, जिस पर CA एक बार हस्ताक्षर करता है। क्लाइंट वह प्रमाणपत्र प्रस्तुत करता है और उससे मेल खाने वाली निजी कुंजी रखने को सिद्ध करता है, और सर्वर तय करता है कि उसे स्वीकार करना है या नहीं। लैपटॉप खोने पर यही पहचान निरस्त की जाती है।

चोरी के बाद यह अंतर सबसे ज़्यादा मायने रखता है। प्रति-डिवाइस पहचान के साथ एक उजागर क्लाइंट को निरसन या साथी हटाने से हटा दिया जाता है, और बाकी बेड़ा काम करता रहता है।

लीक हुई प्राधिकरण कुंजी के साथ ऐसा नहीं किया जा सकता। उसने अब तक जिस भी प्रमाणपत्र पर हस्ताक्षर किए या कर सकती थी, वे सब संदिग्ध हो जाते हैं, इसलिए प्रतिक्रिया एक निरसन नहीं बल्कि भरोसे का प्रतिस्थापन है। यह एक परियोजना है, टिकट नहीं।

FileRoleBelongs on
ca.crtPublic certificate used to verify signaturesEvery client profile
ca.keyPrivate key that issues certificatesProtected CA storage only
client key pairProves one device's identityThat device alone

किसी फ़ाइल को कहीं भी कॉपी करने से पहले उसे पढ़ें

दो कमांड बिना कोई रहस्य छापे बताते हैं कि आपके हाथ में किस प्रकार की वस्तु है। पहला प्रमाणपत्र पर विषय और CA ध्वज बताता है; दूसरा कुंजी को मान्य करता है और उसका प्रकार बताता है। जिस बंडल को आप वितरित करने वाले हैं उसकी फ़ाइलों पर दोनों चलाएँ। जो भी निजी कुंजी के रूप में मान्य हो, वह क्लाइंट डायरेक्टरी में नहीं रहना चाहिए।

openssl x509 -in ca.crt -noout -subject -ext basicConstraints
openssl pkey -in ca.key -noout -check

अगर दूसरा कमांड क्लाइंट बंडल में पड़ी किसी फ़ाइल पर सफल हो, तो रुकिए और बंडल को समझौता-ग्रस्त मानिए। जो आउटपुट कहता है कि कुंजी वैध है, वह यह भी कहता है कि वह मौजूद है, और मौजूदगी ही पूरी समस्या है।

दूसरी दिशा पर भी ध्यान दें: क्लाइंट प्रोफ़ाइल में उस क्लाइंट की अपनी निजी कुंजी वैध रूप से होती है। जो भी कुंजी मिले उसे मिटा देना कुछ सुधारे बिना कनेक्शन तोड़ देता है, इसलिए हटाने से पहले वस्तु की पहचान करनी होती है।

पहले ही वितरित कुंजी को नियंत्रित करना

यह न मानें कि स्थानीय प्रति मिटाने से जोखिम उलट जाता है। जिसके भी पास फ़ाइल थी वह उसकी प्रति बना सकता था, और सुरक्षित अनुमान यही है कि उसने बनाई। ऑपरेटर की घटना प्रक्रिया का पालन करें और भरोसा-लंगर बदलें, नई CA के अधीन डिवाइस प्रमाणपत्र फिर से जारी करते हुए।

फिर उस पैकेजिंग को बदलें जिसने समस्या पैदा की। फ़ाइलों की स्पष्ट अनुमति-सूची के साथ डायरेक्टरी सूची भेजें, CA कुंजी ऐसी मशीन पर रखें जो कभी क्लाइंट बेड़े से नहीं जुड़ती, और दर्ज करें कि कौन-सा सिस्टम उसे रखता है।

अगर प्राधिकरण को बार-बार जारी करना पड़े, तो हस्ताक्षर को संकीर्ण दायरे और छोटी वैधता वाली सेवा या मध्यस्थ के पीछे ले जाएँ। इस तरह भविष्य की ग़लती पूरे परिनियोजन के भरोसा-मूल के बजाय जारीकरण के एक उपसमुच्चय को उजागर करती है।

संबंधित लेख