रद्द किया गया 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 में निर्दिष्ट हैं।