अकेला CSR नामांकन नहीं है: VPN CA को क्या जाँचना चाहिए

प्रमाणपत्र हस्ताक्षर अनुरोध में एक सार्वजनिक कुंजी और एक अनुरोधित विषय होता है, जो मेल खाती निजी कुंजी से हस्ताक्षरित होता है। वह हस्ताक्षर साबित करता है कि अनुरोधकर्ता के पास कुंजी है। यह साबित नहीं करता कि अनुरोधकर्ता को उस नाम, उपकरण या VPN भूमिका का हक है जिसके लिए वह अनुरोध कर रहा है, और अनुरोध को ऐसे मानना जैसे वह यह साबित करता हो, यही तरीका है जिससे हेल्प-डेस्क टिकट प्रवेश अनुमति बन जाता है।

दो नामांकन मॉडलों की तुलना इस आधार पर करनी चाहिए कि वे क्या बाँधते हैं, यह पर नहीं कि वे कौन-सी प्रोटोकॉल बोलते हैं।

अनुरोध एक नाम का दावा करता है, उसे साबित नहीं करता

अनुरोध को इस बात के लिए पढ़ें कि उसमें वास्तव में क्या है: एक सार्वजनिक कुंजी, अनुरोधकर्ता द्वारा चुना गया एक विषय, और दोनों पर एक स्व-हस्ताक्षर। उस संरचना में कुछ भी आपकी सूची, खाता निर्देशिका या स्वीकृति प्रवाह का संदर्भ नहीं देता। cn=finance-laptop जैसा विषय किसी के द्वारा टाइप किया गया एक स्ट्रिंग है। जब तक जारी करने की प्रक्रिया उस स्ट्रिंग को किसी भरोसेमंद रिकॉर्ड के विरुद्ध जाँच नहीं लेती, प्रमाणपत्र हस्ताक्षर जुड़ा हुआ एक दावा है। यही अंतर नामांकन प्रक्रिया के होने का पूरा कारण है।

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

मॉडलों की तुलना इस आधार पर करें कि वे क्या बाँधते हैं

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

दोनों मॉडलों को अभी भी वही तीन प्रश्नों का उत्तर देना है। कौन माँग रहा है, किस उपकरण या भूमिका पर, और कितने समय के लिए। उत्तर दर्ज करने वाली टिकट प्रणाली वास्तविक काम करती है; जहाँ कोई सामान्य नाम को देखता रहता है ऐसी कतार नहीं करती, बाद में प्रमाणपत्र कितनी भी सावधानी से स्वरूपित किया जाए।

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

जीवनचक्र पहली बार जारी करने से दर्ज करें

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

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

जारी प्रमाणपत्र जाँचें, फिर पहुँच

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

openssl req -in client.csr -noout -verify -subject
openssl x509 -in client.crt -noout -subject -issuer -dates -ext extendedKeyUsage
openssl verify -CAfile ca.crt client.crt

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

गलत कारण से काम करने वाली प्रोफ़ाइल, जैसे मेल खाता सामान्य नाम और कोई पहचान जाँच नहीं, आपके द्वारा रखा हुआ माना गया नियंत्रण हटाए जाने के बाद भी काम करती रहेगी।