OCSP र CRL: प्रत्येक रद्दीकरण जाँच वास्तवमा कसरी काम गर्छ

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

चरण 1: प्रत्येक जाँचले के फर्काउँछ र कति समय प्रयोगयोग्य रहन्छ

CRL एउटा हस्ताक्षरित वस्तुका रूपमा प्रकाशित हुन्छ जसले जारीकर्ताले रद्द गरेको हरेक प्रमाणपत्र समेट्छ, त्यसैले प्रमाणकर्ताले यसलाई एक पटक लिन्छ र सूचीको nextUpdate नाघुन्जेल पुनः प्रयोग गर्छ। OCSP प्रतिक्रिया अझ साँघुरो छ: यो ठ्याक्कै एउटा प्रमाणपत्रका लागि उत्तर दिन्छ र thisUpdate, producedAt र प्रायः nextUpdate पनि बोक्छ। त्यही भिन्नताले बाँकी सबैलाई निर्देशन गर्छ। क्यास गरिएको CRL चुपचाप पुरानो हुन्छ, किनकि फाइल अझै पार्स हुन्छ र यसको हस्ताक्षर अझै प्रमाणित हुन्छ, तर म्याद सकिएको OCSP प्रतिक्रिया यसको समय-छाप पढ्ने क्षणमै स्पष्ट रूपमा मूल्यहीन हुन्छ।

त्यसैले क्यासिङ पहिले तय गर्नुपर्ने कुरा हो: कुन घटकले प्रतिलिपि राख्छ, र त्यो प्रतिलिपिले कुन उच्चतम सीमा पालना गर्छ। गेटवेमा सीमा nextUpdate घटाएर सुरक्षा मार्जिन हुनुपर्छ, कहिल्यै पनि HTTP क्यास हेडरले संयोगवश सुझाएको कुरा होइन। openssl crl -in issuer.crl -noout -lastupdate -nextupdate दुवै मिति छाप्छ, र जसको nextUpdate पहिले नै विगतमा छ त्यस्तो सूचीलाई केवल पुरानो होइन, हराएको मान्नुपर्छ।

चरण 2: प्रमाणपत्रले ग्राहकलाई कहाँ निर्देशन गर्छ

पात प्रमाणपत्रले सामान्यतया दुई संकेत बोक्छ: CRL वितरण बिन्दु विस्तार र OCSP का लागि प्राधिकरण सूचना पहुँच प्रविष्टि। openssl x509 -in client.pem -noout -ext crlDistributionPoints पहिलो छाप्छ, र दोस्रो openssl x509 -in client.pem -noout -text को AIA खण्डमुनि हुन्छ। कुनै पनि विस्तार सूचक हो, बाध्यता होइन। जुन ग्राहकले कहिल्यै रद्दीकरण जाँच लागू गर्दैन, त्यो विस्तारहरूले एक वर्षदेखि मृत प्रतिक्रियाकर्ताको नाम दिने प्रमाणपत्रसँग राम्ररी जोडिन्छ।

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

चरण 3: अवरोधअघि fail-closed वा fail-open छान्नुहोस्

पहुँच नभएको प्रतिक्रियाकर्ता वा म्याद सकिएको सूचीले निर्णय गर्न बाध्य बनाउँछ: जडान अस्वीकार गर्नुहोस्, वा स्वीकार गरी खाडल अभिलेख गर्नुहोस्। OpenSSL को verify उपआदेशले कठोर विकल्प स्पष्ट बनाउँछ, किनकि -crl_check थप्दा अनुपलब्ध CRL unable to get certificate CRL र असफल प्रमाणीकरण बन्छ। अधिकांश स्ट्याकमा सफ्ट-फेल कुनै झन्डा नै होइन, त्यो जाँचको अनुपस्थिति हो, र त्यसैले यो दुर्घटनावश पठाइन्छ।

ग्राहकको वास्तवमा कस्तो व्यवहार छ हेर्न प्रतिक्रियाकर्ता हटाएर फेरि जोडिनुहोस्। सुरुङ तैपनि माथि आयो भने, छोडिएको जाँच अभिलेख गर्ने लग लाइन खोज्नुहोस्, अनि घटनाको समयमा कसैले त्यो लाइन पढ्छ कि भनी सोध्नुहोस्। एउटै विक्रेता प्रोटोकलअनुसार फरक हुन सक्छ: एउटै मेसिनमा IKEv2 ग्राहक र OpenVPN ग्राहकले असम्बन्धित कन्फिगरेसन सेटिङ पढ्छन्।

चरण 4: ट्राफिक स्वीकार गरिने ठाउँमै जाँच चल्छ भनी प्रमाणित गर्नुहोस्

जडान अन्त्य गर्ने वा अधिकृत गर्ने प्रक्रिया खोज्नुहोस्, अनि रद्दीकरण जाँच सक्षम गर्ने कन्फिगरेसन लाइन सोध्नुहोस्। शृंखला प्रमाणित गर्ने तर रद्दीकरणबारे कहिल्यै नसोध्ने गेटवेले तपाईंको कागजातमा भएको नीतिभन्दा फरक नीति लागू गर्छ, र प्रमाणपत्र शृंखलाको कुनै स्क्रिनसटले उल्टो प्रमाणित गर्दैन। OpenVPN यो विकल्प crl-verify लेख्छ; strongSwan CRL र OCSP खोजहरू CA कन्फिगरेसनमुनि राख्छ, जहाँ crl_uris वा ocsp_uris सेट गरिन्छ। दुवैमध्ये कुनैलाई देखाउन सक्नुहुन्न भने जाँच अनुपस्थित छ भनी मान्नुहोस्।

OCSP प्रतिक्रिया तब मात्र मान्य हुन्छ जब जारी गर्ने CA ले यसमा हस्ताक्षर गरेको हुन्छ, वा त्यस CA ले प्रत्यायोजन गरेको OCSPSigning विस्तारित कुञ्जी प्रयोग भएको प्रतिक्रियाकर्ताले हस्ताक्षर गरेको हुन्छ, त्यसैले असम्बन्धित सेवाबाट आएको उत्तरले केही पनि प्रमाणित गर्दैन। तपाईं आफैले प्रतिक्रियाकर्ता चलाउनुहुन्छ भने यसलाई कठोर निर्भरता मानी अनुगमन गर्नुहोस्, किनकि एउटा मृत सेवा एकैचोटि हरेक fail-closed ग्राहकका लागि अवरोध बन्छ।

चरण 5: जानाजान एउटा प्रमाणपत्र रद्द गर्नुहोस्

परीक्षण प्रमाणपत्र लिनुहोस्, उत्पादनले प्रयोग गर्ने त्यही माध्यमबाट रद्द गर्नुहोस्, र प्रतिक्रियाकर्तालाई सिधै सोध्नुहोस्। openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text ले रद्दीकरण समयसहित Cert Status: revoked रिपोर्ट गर्नुपर्छ, र good उत्तरको अर्थ तपाईंको रद्दीकरण तपाईंका ग्राहकले सोध्ने प्रतिक्रियाकर्तासम्म पुगेन। त्यसपछि सूची मार्गबाट त्यही निर्णय हेर्न openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem चलाउनुहोस्। निकास कोडको सट्टा कारणको स्ट्रिङ पढ्नुहोस्, किनकि रद्दीकरण अस्वीकृति र शृंखला त्रुटि दुवै असफलतामा टुंगिन्छन्।

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