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 प्रतिक्रिया में क्या होता है, जिसमें वे स्थिति मान भी शामिल हैं जो यह परीक्षण पढ़ता है।