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 प्रतिसादात काय असते ते परिभाषित करते, या चाचणीने वाचलेल्या स्थिती मूल्यांसह।