एउटै साझा नाम, दुई प्रमाणपत्र: अनुमति सूची कि रद्द गर्ने?

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

सर्भरले प्रयोग गर्ने नामकरण नीतिबाट सुरु गर्नुहोस्

दुई नियन्त्रण मिसिन्छन्: ग्राहक आफूलाई को भन्छ भन्ने आधारमा प्रवेश दिने, र एउटा निश्चित प्रमाणपत्र सेवाबाट हटाउने। पहिलो नाम जाँच हो, दोस्रो रद्द जाँच हो। ती फरक प्रश्नको उत्तर दिन्छन्, र एउटा तैनाथीमा अर्कोबिना एक हुन सक्छ।

सर्भर कन्फिगरेसन पढ्नुहोस् र कुन पहिचान स्रोत प्रयोगमा छ त्यो नोट गर्नुहोस्। username-as-common-name ले प्रमाणित प्रयोगकर्ता नामलाई ग्राहक-विशिष्ट खोजका लागि प्रभावकारी नाम बनाउँछ। त्यो नभए प्रमाणपत्रको विषय साझा नाम प्रयोग गरिन्छ। उत्तर जे भए पनि, कुनै अनुमति सूची छुनुअघि त्यो लेख्नुहोस्।

दुई मार्गले एउटै प्रमाणपत्रका लागि फरक अनुमत नामको समूह दिन्छन्। यहाँ अनुमान गर्नु भनेको गलत फाइल सम्पादन गरी नियन्त्रण चल्दैन भन्ने निष्कर्ष निकाल्नु हो।

ग्राहकलाई वास्तवमा केले प्रवेश दिन्छ जाँच्नुहोस्

मिल्ने फाइल भएको client-config-dir ले ग्राहक-विशिष्ट विकल्प दिन्छ; एक्लैले यो प्रवेश नियम होइन। नामअनुसार प्रवेशका लागि ccd-exclusive आवश्यक हुन्छ, जसले मिल्ने फाइल नभएका ग्राहकलाई अस्वीकार गर्छ। चालु तैनाथीमा त्यो खोल्दा फाइल नभएका सबैको जडान काटिन्छ, त्यसैले केही बदल्नुअघि फाइलहरू गन्नुहोस्।

grep -nE 'ccd-exclusive|client-config-dir|username-as-common-name' /etc/openvpn/server/server.conf
ls -1 /etc/openvpn/ccd/

गणना नै जाँच हो: डाइरेक्टरी सूचीलाई तपाईंले जोडिने अपेक्षा गर्ने पहिचानसँग तुलना गर्नुहोस्।

त्यसपछि प्रत्येक फाइल नाम प्रभावकारी पहिचानसँग ठ्याक्कै मिल्छ कि मिल्दैन भनी पुष्टि गर्नुहोस्, अक्षरको आकार र खाली ठाउँसमेत। office-laptop का लागि फाइलले विषय Office-Laptop भनी पढिने प्रमाणपत्रका लागि केही गर्दैन। अन्त्यका खाली ठाउँ पनि साधारण सूचीबाट लुक्छन्, र त्यसैले उपस्थित देखिने फाइल नपढी रहन्छ।

गेटवेले लोड गर्ने CRL जाँच्नुहोस्

CRL ले रद्द भएका प्रमाणपत्रलाई जारीकर्ता र क्रम संख्याद्वारा नाम दिन्छ, र त्यो नाम जाँचमा नहुने सूक्ष्मता हो। दुई प्रमाणपत्रले साझा नाम बाँड्न सक्छन् र क्रम संख्यामा फरक पर्न सक्छन्, र क्रम तहको सूचीले मात्र तिनलाई छुट्याउँछ।

फाइलमा विश्वास गर्नुअघि कन्फिगर गरिएको बाटो, जारी मिति र अर्को अद्यावधिक फिल्ड पुष्टि गर्नुहोस्।

openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate
openssl x509 -in office-laptop.crt -noout -serial -subject

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

प्रतिस्थापन गर्नुहोस्, त्यसपछि दुवै नतिजा प्रमाणित गर्नुहोस्

उही साझा नाममा प्रतिस्थापन जारी गर्नुहोस्, दुवै क्रम संख्या रेकर्ड गर्नुहोस्, र त्यसपछि मात्र पुरानो रद्द गर्नुहोस्। त्यो क्रमले परिवर्तन तयार पार्दा काम गर्ने पहिचान उपलब्ध राख्छ।

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

पहिले नै स्थापित सत्रहरू छुट्टै कुरा हुन्, किनकि गेटवे सक्रिय जडान काट्न कन्फिगर नभएसम्म रद्द नयाँ प्रमाणीकरणमा लागू हुन्छ। कसैलाई वचन दिनुअघि तत्काल हटाउनु आवश्यक छ कि छैन निर्णय गर्नुहोस्।

नाम जाँचले कहिल्यै गर्न नसक्ने कुरा

अनुमति सूचीले यो पहिचान जोडिन सक्छ कि भन्ने उत्तर दिन्छ। त्यो पहिचानले कुन प्रमाणपत्र प्रयोग गर्यो भन्न सक्दैन, र प्रमाण वैध र नरद्द भएसम्म पुरानो प्रमाण स्वीकार गरिरहन्छ। त्यो अन्तर घटनाको बेला देखिन्छ, जब प्रतिस्थापन महिनौं अघि जारी भयो र पूर्ववर्ती अझै चल्छ।

प्रमाणपत्र तहको नियन्त्रण आवश्यक भएमा प्रमाणपत्रको नाम लिने संयन्त्र प्रयोग गर्नुहोस्: CRL प्रविष्टि, वा अपरेटरले राख्ने औंठाछाप जाँच्ने प्रमाणीकरण हुक। दुवैलाई मर्मत चाहिन्छ, र दुवैले आफूले जाँच्ने वस्तुबारे इमानदार छन्। OpenVPN 2.6 पुस्तिका अनुसार crl-verify र ग्राहक-विशिष्ट प्रवेश छुट्टाछुट्टै विकल्पका रूपमा अभिलेख गरिएका छन्, त्यही कारणले।

कुन नियन्त्रणले कुन काम गर्छ लेख्नुहोस्, त्यसपछि नकारात्मक अवस्था परीक्षण गर्नुहोस्। जसले कहिल्यै जडान अस्वीकार गरेको नदेखेको रद्द भनेको चल्छ भन्ने आशा गरिएको कन्फिगरेसन हो।