CSR मात्र नामांकन होइन: VPN CA ले के जाँच्नुपर्छ

प्रमाणपत्र हस्ताक्षर अनुरोधमा सार्वजनिक कुञ्जी र अनुरोध गरिएको subject हुन्छ, जो मिल्ने निजी कुञ्जीले हस्ताक्षर गरिएको हुन्छ। त्यो हस्ताक्षरले अनुरोधकर्तासँग कुञ्जी छ भनी प्रमाणित गर्छ। यसले अनुरोधकर्तालाई अनुरोध गरिएको नाम, यन्त्र वा VPN भूमिकाको हक छ भनी प्रमाणित गर्दैन, र अनुरोधलाई त्यसो प्रमाणित गरेजस्तै व्यवहार गर्नु नै हेल्प डेस्क टिकट पहुँच अनुमतिमा बदलिने तरिका हो।

दुई नामांकन मोडेलहरूलाई तिनीहरूले कुन प्रोटोकल बोल्छन् भन्नेमा होइन, के बाँध्छन् भन्नेमा तुलना गर्नु उपयुक्त हुन्छ।

अनुरोधले नाम दाबी गर्छ, प्रमाणित गर्दैन

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

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

तिनीहरूले के बाँध्छन् भन्ने आधारमा मोडेलहरू तुलना गर्नुहोस्

हातले हस्ताक्षर गर्नुले अपरेटरले जाँच्न सम्झने कुरा बाँध्छ। स्वचालित नामांकन सेवाले प्रमाणित अनुरोधलाई सेवाले लागू गर्न सक्ने निर्णयसँग बाँध्छ, र 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

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

गलत कारणले काम गर्ने प्रोफाइल, जस्तै मिल्ने सामान्य नाम र कुनै पहिचान जाँच नहुनु, तपाईंले छ भन्ने ठानेको नियन्त्रण हटाइएपछि पनि काम गरिरहनेछ।