रद्द केलेले 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 मध्ये निर्दिष्ट आहेत।