OpenVPN verify-x509-name: subject, name और name-prefix में अंतर

पहले मिलान का प्रकार पढ़ें, फिर पाठ: एक verify-x509-name निर्देश सही दिख सकता है और फिर भी ऐसा प्रमाणपत्र स्वीकार कर सकता है जिस पर भरोसा करने का आपका इरादा नहीं था। समान अपेक्षित पाठ पर अलग प्रकार वाली दो पंक्तियाँ अलग आवश्यकताएँ हैं। पहले प्रकार पढ़ें, फिर पाठ। निर्देश को कनेक्शन पर एक और शर्त मानें, पूरी जाँच नहीं।

विकल्प वास्तव में क्या दावा करता है

निर्देश उस पहचान का नाम देता है जो सामने वाले पक्ष के प्रमाणपत्र में होनी चाहिए। जब तुलना विफल होती है, OpenVPN हैंडशेक रोक देता है और कोई सुरंग नहीं उठती। प्रोफ़ाइल में बाकी सब अब भी लागू है: प्रमाणपत्र को विश्वसनीय CA तक शृंखलित होना चाहिए और भूमिका जाँच पास होनी चाहिए, इसलिए यह एक अतिरिक्त शर्त है, विकल्प नहीं। ऐसी प्रोफ़ाइल जो नाम की अपेक्षा पूरी करे पर भूमिका जाँच में विफल हो, अब भी टूटी है, और लॉग सामान्यतः यही कहता है।

यह ब्राउज़र द्वारा किए जाने वाले होस्टनाम सत्यापन से भी अलग है। ब्राउज़र अपने TLS स्टैक के नियमों के अनुसार नामों को subject के वैकल्पिक नामों से मिलाता है, जबकि OpenVPN आपके चुने प्रकार से प्रमाणपत्र का एक क्षेत्र तुलना करता है। इसीलिए ब्राउज़र-शैली का होस्टनाम निर्देश में चिपकाने पर बेमेल हो सकता है, भले ही प्रमाणपत्र वास्तव में सेवा को कवर करता हो।

subject: पूरा विशिष्ट नाम, अक्षर दर अक्षर

जब कोई प्रकार न लिखा हो तो डिफ़ॉल्ट subject है, और अपेक्षित मान को प्रमाणपत्र का पूरा subject DN फिर से पैदा करना चाहिए। क्षेत्रों का क्रम, विभाजक, अंतराल और escaping सब गिने जाते हैं, क्योंकि तुलना उसी स्ट्रिंग पर चलती है जैसी वह एन्कोड है। प्रकार छोड़ दें तो आपने तीनों में सबसे कड़ी तुलना चुनी है। कोई सामान्यीकरण चरण नहीं है जो दिखावटी अंतर बचा ले। यह पहले नवीनीकरण से पहले जानना उपयोगी है, बाद में नहीं।

यह कड़ाई नवीनीकरणों के बीच नाज़ुक है। जो CA विशेषताओं को पुनःक्रमित करता है, अतिरिक्त क्षेत्र डालता है या किसी मान का escaping बदलता है, वह उसी मशीन के लिए नई स्ट्रिंग बनाता है, और सालों चला निर्देश अगले निर्गमन पर विफल होने लगता है। स्वीकृत DN को परिवर्तन-रिकॉर्ड में रखना अगले नवीनीकरण को एक सरल अंतर बना देता है। जहाँ ऑपरेटर पूरा DN प्रकाशित करता है और उसका आकार गारंटी करता है, वहाँ subject उचित चुनाव है; अन्यत्र संकीर्ण क्षेत्र सच रखना आसान है।

name: एक क्षेत्र, आमतौर पर सामान्य नाम

प्रकार name subject के एक क्षेत्र की तुलना करता है। जब तक प्रोफ़ाइल कुछ और न कहे, वह क्षेत्र सामान्य नाम है, और अपेक्षित मान ठीक वही क्षेत्र है, उसके आसपास का DN नहीं।

पेच यह है कि आधुनिक प्रमाणपत्र सेवा का नाम हमेशा CN में नहीं रखते। कई उसे subject के वैकल्पिक नाम में रखते हैं और CN खाली या सामान्य छोड़ देते हैं, इसलिए ब्राउज़र जिसे स्वीकार करता है वह प्रमाणपत्र इस तुलना में विफल हो सकता है। अपेक्षा लिखने से पहले वह प्रमाणपत्र देखें जो वास्तव में आपको जारी हुआ, और पुष्टि करें कि प्रोफ़ाइल कौन-सा क्षेत्र चुनता है। खाली CN की किसी नाम से तुलना बेमेल है, कॉन्फ़िगरेशन दुर्घटना नहीं।

name-prefix: डिज़ाइन से व्यापक, इसलिए दायरा सीमित करें

एक name-prefix प्रकार की अपेक्षा चुने गए क्षेत्र की शुरुआत से मेल खाती है। यह नामकरण योजना के लिए सुविधाजनक और किसी भी साझा चीज़ के लिए खतरनाक है।

अपेक्षा के रूप में vpn.example होने पर, दोनों vpn.example.com और vpn.example.net पास होते, बशर्ते शेष शृंखला पर भरोसा हो। चौड़ाई ही विशेषता है, और यही वह हिस्सा है जिसे लिखित में न्यायसंगत ठहराना चाहिए। उपसर्ग तब उचित है जब CA और नामकरण योजना आपकी हों, और बहुत कमज़ोर तब जब सार्वजनिक CA उसी पैटर्न में जारी करता हो। यदि योजना को लचीलापन चाहिए तो क्लाइंट जाँच बढ़ाने के बजाय उसे CA पर सीमित करें।

पहचानकर्ता से प्रकार चुनें, फिर उसे सिद्ध करें

ऑपरेटर जिस पहचान का इरादा रखता है वहाँ से पीछे काम करें। यदि वह पूरा DN प्रकाशित करता है और उसे स्थिर रखता है, subject यही व्यक्त करता है। यदि सेवा को सामान्य नाम से कहता है, तो उपयोग करें name। यदि नामकरण योजना का स्वामी है और उसका पूरा क्षेत्र स्वीकार करता है, name-prefix यह स्पष्ट कहता है।

नवीनीकरण वही जगह है जहाँ निर्देश परखा जाता है। स्वीकृत पहचान की तुलना नए प्रमाणपत्र से करें, पुरानी फ़ाइल से नहीं, क्योंकि नया एंडपॉइंट पता नई प्रमाणपत्र पहचान नहीं दर्शाता। केवल इसलिए निर्देश न हटाएँ कि कोई जाना-पहचाना पता उत्तर दे रहा है: पहुँच और इच्छित सामने वाला पक्ष अलग-अलग तथ्य हैं, और पता केवल यह सिद्ध करता है कि किसी चीज़ ने उत्तर दिया। सटीक त्रुटि और नाम के सार्वजनिक विवरण साफ़ की गई रिपोर्ट में दर्ज करें, क्योंकि नाम का बेमेल बिना किसी निजी कुंजी सामग्री के दिखाया जा सकता है।

समर्थित सुधार के बाद, हर इच्छित जाँच सक्षम रखते हुए फिर से जुड़ें और वह संसाधन जाँचें जो वास्तव में आपको चाहिए। सफलता का अर्थ है इच्छित सर्वर स्वीकार हुआ, कोई प्रमाणपत्र बलपूर्वक पार नहीं कराया गया। आधिकारिक मैनुअल OpenVPN 2.6 manual तीनों प्रकारों और उनके भरोसा-नोटों का दस्तावेज़ीकरण करता है, और जब कोई विक्रेता इंटरफ़ेस प्रोफ़ाइल से असहमत हो तो यही उद्धरण का संदर्भ है।