रद्द गरिएको VPN प्रमाणपत्र अझै जोडिन्छ? CRL कार्यान्वयन जाँच्नुहोस्
रद्द गरिएका प्रमाणपत्रहरू अझै जोडिन्छन् जब CRL कहिल्यै प्रमाणिकरणकर्तासम्म पुग्दैन। यही क्रममा जारीकर्ता, लोड गरिएको क्रम संख्या, पुनः लोड व्यवहार र सक्रिय सत्रहरू जाँच्नुहोस्।
तपाईंले प्रमाणपत्र रद्द गर्नुभयो, नयाँ सूची बनाउनुभयो, र पुरानो प्रोफाइल अझै सुरुङ उभ्याउँछ। रद्द गर्ने कार्य आफैंमा बिग्रिएको छैन: CRL एउटा हस्ताक्षरित घोषणा हो कि क्रम संख्या अब मान्य छैन, र यसले पहुँच तब मात्र परिवर्तन गर्छ जब TLS अन्त्य गर्ने घटकले यसलाई सही जारीकर्ताका लागि लोड गर्छ, स्वीकृति निर्णय गर्नुअघि। अधिकांश यस्ता घटनाहरू त्यहीँ छन्, र त्यसैले रद्द गर्नु र अस्वीकार गर्नु दुई फरक तथ्य हुन्।
तलका पाँच जाँचहरू क्रममा गर्नुहोस् र पहिलो असफल हुनेमा रोक्नुहोस्, किनकि प्रत्येक पछिल्लो जाँचले अघिल्ला सही छन् भनी मान्छ।
स्वीकृति निर्णय कुन घटकले गर्छ जाँच्नुहोस्
क्लाइन्ट प्रमाणपत्र प्रमाणित गर्ने प्रक्रियाको नाम भन्नुहोस्, किनकि त्यही प्रक्रियाले मात्र सूची कार्यान्वयन गर्न सक्छ। OpenVPN सर्भरमा त्यो डेमन आफैं हो, crl-verify सँग कन्फिगर गरिएको। ocserv मा त्यो ocserv.conf भित्रको crl लाइन हो। strongSwan मा इनपुट लोड गरिएका CRL हुन् strictcrlpolicy सँग। VPN अगाडि TLS अन्त्य गर्ने प्रोक्सी वा यन्त्र पनि वास्तविक प्रमाणिकरणकर्ता हुन सक्छ, र यदि त्यस्तो छ भने त्यसपछाडिको डेमनले क्लाइन्ट प्रमाणपत्र कहिल्यै देख्दैन।
WireGuard अर्को श्रेणीमा पर्छ। यससँग प्रमाणपत्र पनि छैनन् र रद्द सूची पनि छैन; सहकर्मी कन्फिगरेसनमा उसको सार्वजनिक कुञ्जीबाट स्वीकार गरिन्छ, त्यसैले पहुँच अन्त्य गर्नु भनेको त्यो कुञ्जी हटाउनु हो। यदि तपाईं WireGuard मात्र भएको तैनाथीमा CRL खोज्दै हुनुहुन्छ भने त्यो संयन्त्र त्यहाँ छैन।
क्लाइन्ट पक्षको जालबाट पनि सावधान रहनुहोस्। सर्भरको प्रमाणपत्र मन नपरेर जोडिन अस्वीकार गर्ने क्लाइन्टले सर्भरको शृंखला कार्यान्वयन गरिरहेको हुन्छ, आफ्नै प्रमाणहरू रद्द गरिरहेको हुँदैन। प्रयोगकर्ता प्रमाणपत्र त्यहीँ मात्र रद्द हुन्छ जहाँ त्यो प्रयोगकर्ता प्रमाणपत्र प्रमाणित हुन्छ, र त्यो लगभग सधैं सर्भर पक्ष हुन्छ।
सूची कुन जारीकर्ताका लागि हस्ताक्षर गरिएको छ जाँच्नुहोस्
CRL एउटै जारीकर्ता CA मा सीमित हुन्छ। मूल र मध्यस्थ CA हुँदा पातका प्रमाणपत्रहरू मध्यस्थबाट आउँछन्, त्यसैले महत्त्वपूर्ण सूची मध्यस्थको CRL हो; मूलको सूचीले ती पातहरूबारे केही भन्दैन। गलत फाइलतिर देखाइएको प्रमाणिकरणकर्ताले त्यसलाई खुसीसाथ पार्स गर्छ, मिल्ने प्रविष्टि भेट्दैन र सबै स्वीकार गर्छ।
डेमन छुनुअघि जोडीको पुष्टि गर्नुहोस्। प्रमाणपत्रमा भएको जारीकर्ता सूचीको subject सँग मिल्नुपर्छ:
openssl x509 -in client.crt -noout -issuer -serial
openssl crl -in intermediate.crl -noout -issuer -lastupdate -nextupdateजब दुवै एउटै CA बाट आउँछन्, प्रमाणपत्रका लागि छापिएको क्रम संख्या त्यही मान हो जो सूचीमा आउनुपर्छ। यदि ती मिल्दैनन् भने तपाईंसँग गलत CRL वा त्यसको गलत प्रतिलिपि छ।
मान्यता त्यही जाँचको हो। विगतमा भएको nextUpdate ले सूची पुरानो बनाउँछ, र बन्द रूपमा असफल हुने प्रमाणिकरणकर्ताले तब रद्द गरिएको मात्र नभई हरेक क्लाइन्ट अस्वीकार गर्छ।
क्रम संख्या डेमनले लोड गरेको प्रतिलिपिमा छ कि छैन जाँच्नुहोस्
रद्द गर्ने कार्यले CA डाटाबेसमा प्रविष्टि लेख्छ, र पुनः उत्पादनले नयाँ फाइल लेख्छ। दुवैमध्ये कुनै पनि कार्यले सुरु हुँदा पुरानो प्रतिलिपि लोड गरेको चलिरहेको डेमनसम्म पुग्दैन। सूची डम्प गर्नुहोस् र क्रम संख्या खोज्नुहोस्:
openssl crl -in intermediate.crl -noout -text | grep -i -A2 'Serial Number'
openssl ca -revoke client.crt
openssl ca -gencrl -out intermediate.crlत्यसपछि तपाईंको कार्यान्वयनले फाइल कसरी लिन्छ जाँच्नुहोस्। OpenVPN ले crl-verify लाई दिइएको बाटो सुरु हुँदा एक पटक पढ्छ, त्यसैले नयाँ सूचीका लागि पुनः सुरु वा पुनः सुरु संकेत चाहिन्छ; त्यही विकल्प कुनै डाइरेक्टरीतिर भएमा हरेक जडानमा फेरि पढिन्छ, र त्यसैले डाइरेक्टरी मोड छ। strongSwan ले आफ्ना प्रमाणहरू पुनः लोड गर्नुपर्छ, उदाहरणका लागि swanctl --load-creds बाट। फाइल डिस्कमा सही हुनु र प्रमाणिकरणकर्ताले त्यसलाई प्रयोग गर्नु दुई फरक तथ्य हुन्।
हराएको वा म्याद सकिएको सूचीको नीति जाँच्नुहोस्
यो त्यस्तो निर्णय हो जो धेरै तैनाथीहरूले कहिल्यै स्पष्ट रूपमा गर्दैनन्, र यसले रद्द गर्ने कार्यले तपाईंको रक्षा गर्छ वा सबैलाई बाहिर बन्द गर्छ भन्ने निर्धारण गर्छ। Fail-closed भन्नाले उपयोगी रद्द जानकारी बिना अस्वीकृति हुन्छ भन्ने हो; fail-open भन्नाले प्रमाणिकरणकर्ता त्यसबिना अगाडि बढ्छ भन्ने हो। strongSwan ले विकल्प strictcrlpolicy का रूपमा देखाउँछ। OpenVPN ले crl-verify सँग पढ्न वा पार्स गर्न नसक्ने फाइलमा सुरु हुन अस्वीकार गर्छ, र म्याद सकिएको सूची चुपचाप स्वीकृतिको सट्टा म्याद सकिएको CRL बारे TLS प्रमाणिकरण त्रुटिको रूपमा देखिन्छ।
| State of the revocation data | Fail-closed result | Fail-open result |
|---|---|---|
| List missing or unreadable | Verification fails, so expect an outage | Every client connects, including the revoked one |
List past nextUpdate | Validation errors until a fresh list is deployed | Old status is trusted indefinitely |
| Revoked serial present in the loaded list | Handshake rejected for that certificate | Handshake rejected for that certificate |
तपाईं जुनसुकै दिशा रोज्नुहोस्, स्वचालन रोजाइभन्दा महत्त्वपूर्ण छ: CRL लाई nextUpdate अघि पुनः उत्पादन गर्ने कार्य, र तैनाथ प्रतिलिपि पुरानो हुँदा दिइने चेतावनी, दुवै नीतिलाई घटना बन्नबाट रोक्छन्। OCSP सँग अनलाइन जाँचले ताजगी उत्तरदातातिर सार्छ, तर त्यही नियम लागू हुन्छ, किनकि उत्तर जाँच्न कन्फिगर नगरिएको प्रमाणिकरणकर्ताले केही बदल्दैन।
सक्रिय सत्र जाँच्नुहोस्, त्यसपछि कुञ्जीका प्रतिलिपिहरू
रद्द गर्ने कार्यको मूल्याङ्कन प्रमाणपत्र प्रमाणिकरणका क्रममा हुन्छ, जो जोडिँदा र पुनः वार्तामा हुन्छ। स्थापित सत्र पुनः वार्ता नगरेसम्म चल्छ, र OpenVPN को पूर्वनिर्धारित मान reneg-sec 3600 सँग घण्टामा एक पटक हो। यदि व्यक्ति अहिले नै सञ्जालबाट बाहिर जानुपर्ने छ भने सूची प्रकाशनसँगै सत्र पनि अन्त्य गर्नुहोस्, र त्यसपछि पुनः जडान अस्वीकार हुने पुष्टि गर्नुहोस्।
प्रमाणहरूलाई तिनका प्रतिलिपिबाट अलग राख्नुहोस्। एउटा ल्यापटपमा प्रोफाइल मेटाउनुले त्यही निजी कुञ्जीको अर्को प्रतिलिपिलाई प्रमाणित हुनबाट रोक्दैन; रद्द गर्ने कार्यले हरेक प्रतिलिपि बेकार बनाउँछ, र त्यो पनि अघिल्ला जाँचहरू सही भएमा मात्र। प्रतिस्थापन यन्त्रलाई आफ्नै प्रमाणपत्र दिनुहोस् ताकि एउटालाई अर्को नछोई रद्द गर्न सकियोस्।
यसलाई पूर्ण भन्नुअघि: प्रमाणित गर्ने घटक पहिचान भइसकेको छ, सूचीको जारीकर्ता पातको जारीकर्तासँग मिल्छ, रद्द गरिएको क्रम संख्या डेमनले वास्तवमै लोड गरेको प्रतिलिपिमा छ, हराएका वा म्याद सकिएका सूचीहरूको नीति जानाजानको हो र निगरानीमा छ, र सक्रिय सत्र पर्खनुको सट्टा अन्त्य गरिएको छ। यी सबैका पछाडिका ढाँचाहरू RFC 5280 मा निर्दिष्ट छन्।