प्रमाणपत्र मान्य हुँदा पनि नयाँ VPN लगइन असफल हुन्छन्: CRL जाँच्नुहोस्

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

दुई तालिका छुट्याउनु नै सम्पूर्ण निदान हो, र यसले सुधार कस्तो हुनुपर्ने हो भन्ने बदल्छ।

दुई घडी, र तिनमध्ये एउटा मात्र प्रमाणपत्र हो

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

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

सेवाले वास्तवमा लोड गर्ने सूची पढ्नुहोस्

तपाईंले अपेक्षा गर्नुभएको फाइलबाट होइन, चलिरहेको कन्फिगरेसनबाट सुरु गर्नुहोस्। crl-verify को बाटो निरपेक्ष, प्रोफाइलसँग सापेक्ष, वा इमेजमा गाडिएको प्रतिलिपि हुन सक्छ, र प्रमाणित गर्नेले त्यही प्रतिलिपि पढ्छ। यसलाई यसको ठाउँमै openssl crl -in /etc/openvpn/crl.pem -noout -issuer -lastupdate -nextupdate प्रयोग गरी जाँच्नुहोस् र मितिहरूलाई सर्भरको घडीसँग तुलना गर्नुहोस्।

त्यसपछि फाइल साँच्चै प्रयोग भइरहेको फाइल हो भनी पुष्टि गर्नुहोस्: openssl crl -in /etc/openvpn/crl.pem -CAfile /etc/openvpn/ca.crt -noout प्रयोग गरी यसको हस्ताक्षर जाँच्नुहोस्, जसले फाँटहरू चुपचाप छाप्नुको सट्टा प्रमाणीकरण परिणाम रिपोर्ट गर्छ। अर्को CA ले हस्ताक्षर गरेको सूची, वा दोस्रो डाइरेक्टरीमा छाडिएको पुरानो प्रतिलिपि, म्याद सकिएको सूचीजस्तै असफल हुन्छ।

शून्यबाट होइन, रद्दीकरण डेटाबेसबाट पुनः उत्पन्न गर्नुहोस्

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

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

प्रमाणित गर्नेले हेर्ने ठाउँमै परिनियोजन गर्नुहोस्

नयाँ सूचीलाई सेवाले पढ्ने बाटोमा प्रतिलिपि गर्नुहोस्, स्वामित्व र मोड यसरी सेट गर्नुहोस् कि सेवा खाताले पढ्न सकोस् तर अरूले नसकून्, र अभिलेखित व्यवहारअनुसार पुनः लोड वा पुनः सुरु गर्नुहोस्। यदि डेमनले सुरु हुँदा सूची क्यास गर्छ भने, पुनः लोड नगरी फाइल बदल्दा चलिरहेको प्रक्रियाले थाहा पाउने केही पनि बदलिँदैन। पुनः लोडपछि प्रक्रियाले रिपोर्ट गर्ने टाइमस्ट्याम्प पुष्टि गर्नुहोस्।

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

अर्को समयसीमा बित्नुअघि नै देखिने बनाउनुहोस्

लामो प्रकाशन अन्तरालले प्रक्रिया नबनाई यो घटनाको आवृत्ति घटाउँछ। सञ्चालकको नीतिबाट अन्तराल छान्नुहोस्, त्यसपछि पुनः उत्पन्न र परिनियोजनका लागि पर्याप्त समयसहित परिनियोजित सूचीको अर्को-अद्यावधिक फाँटमा सतर्कता राख्नुहोस्। परिनियोजित प्रतिलिपिमा सतर्कता राख्नुहोस्, CA होस्टमा होइन, किनभने परिनियोजित प्रतिलिपि नै असफल हुन्छ।

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