टोकन के लिए OpenConnect को कौन-सा PKCS#11 URI चाहिए?

जिस स्मार्ट कार्ड में पहले से सही कुंजी है, उसे भी बताया जाना चाहिए कि उस पर कौन-सी वस्तु इस्तेमाल करनी है। उस स्थिति में OpenConnect कॉपी की गई .key फ़ाइल नहीं चाहता; वह ऐसा PKCS#11 URI चाहता है जो प्रमाणपत्र का नाम दे और, जब स्वचालित खोज काम पूरा न कर सके, उसके बगल वाली निजी कुंजी का भी। मुश्किल बात यह है कि व्याकरण की दृष्टि से मान्य URI कुछ भी सिद्ध नहीं करता। उसे उस नामांकन का नाम देना चाहिए जिस पर गेटवे पहले से भरोसा करता है, सिर्फ़ ऐसी वस्तु नहीं जिसे कार्ड खोलने को तैयार है।

निर्यात की गई कुंजी की जगह क्लाइंट क्या चाहता है

-c विकल्प सामान्यतः फ़ाइल पथ लेता है, लेकिन जब मान को PKCS#11 URI के रूप में पार्स किया जाता है, तो OpenConnect उसे डिस्क पर की फ़ाइल के बजाय टोकन के भीतर की वस्तु का संदर्भ मानता है। -k विकल्प निजी कुंजी के लिए वैसे ही व्यवहार करता है। कुछ भी निर्यात नहीं होता, और कुंजी कभी उस सुरक्षा को नहीं छोड़ती जो कार्ड देता है। क्लाइंट को आपसे ऐसा नाम चाहिए जिस पर टोकन मॉड्यूल, प्रमाणपत्र भंडार और गेटवे नामांकन सहमत हों।

अंतिम यही बाधा है जहाँ अधिकांश प्रयास अटकते हैं। एक URI पूरी तरह सुगठित हो सकता है और फिर भी ऐसा प्रमाणपत्र चुन सकता है जिसे गेटवे अस्वीकार कर देगा, क्योंकि वैधता और प्रासंगिकता अलग-अलग प्रश्न हैं। जो जाँच करने योग्य है वह नामांकन रिकॉर्ड से तुलना है, संयोग से खुलने वाली पहली वस्तु की खोज नहीं।

दो URI, दो अलग काम

प्रमाणपत्र का URI बताता है कि आप कौन-सी पहचान का दावा कर रहे हैं। यह ऐसी प्रमाणपत्र वस्तु की ओर इशारा करता है जिसकी सार्वजनिक कुंजी और विषय पंक्ति VPN प्रशासक द्वारा जारी खाते या डिवाइस प्रोफ़ाइल से मेल खाती है। वही प्रमाणपत्र सामान्यतः बगल में संग्रहीत निजी कुंजी वस्तु के साथ आता है, और यही जोड़ी TLS हैंडशेक को वास्तव में चाहिए।

कुंजी का URI बताता है कि मेल खाता निजी सामग्री कहाँ रहती है जब OpenConnect उसका अनुमान नहीं लगा सकता। केवल -c सेट होने पर क्लाइंट प्रमाणपत्र के गुणों से कुंजी-खोज बनाता है; -k देने से अनुमान की जगह स्पष्ट वस्तु संदर्भ आ जाता है। टोकन का PIN तीसरा, असंबंधित इनपुट है: यह क्रिया के लिए कार्ड खोलता है, और कभी किसी वस्तु की पहचान नहीं करता।

openconnect --protocol=anyconnect \
  -c 'pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=1a2b3c4d;id=%01' \
  vpn.example.net

उस उद्धृत स्ट्रिंग में सब कुछ डेटा है। अर्धविराम URI विशेषताओं को अलग करते हैं और प्रतिशत-एस्केप ऐसे अक्षरों को कूटबद्ध करते हैं जो अन्यथा पार्सिंग तोड़ देंगे, इसलिए पूरे तर्क को शेल से अक्षुण्ण निकलना होगा।

अपने नामांकन से मेल खाता URI ढूँढना

GnuTLS के साथ p11tool आता है, जो सूचीबद्ध करता है कि वर्तमान उपयोगकर्ता p11-kit के ज़रिए वास्तव में कहाँ पहुँच सकता है। p11tool --list-tokens से शुरू करें, फिर जिस टोकन में आपकी रुचि है उस पर प्रमाणपत्र वस्तुओं की सूची बनाएँ। जब वस्तुएँ केवल PIN के बाद दिखें तो --login जोड़ें, और पहले दिखने वाली चीज़ चुनने के बजाय विषय और जारीकर्ता की नामांकन रिकॉर्ड से तुलना करें।

अगर टोकन बिलकुल न दिखे, तो समस्या OpenConnect के नीचे है: p11-kit में उस मिडलवेयर के लिए कोई मॉड्यूल पंजीकृत नहीं है, या मॉड्यूल किसी दूसरे खाते के लिए पंजीकृत है। सिस्टम-व्यापी पंजीकरण /etc/pkcs11/modules के अंतर्गत रहता है, और प्रति-उपयोगकर्ता निर्देशिका सिस्टम प्रति को छुए बिना वही रख सकती है। जाँचें कि मॉड्यूल फ़ाइल में प्रदाता पथ ऐसी लाइब्रेरी की ओर इशारा करता है जो रीडर के सॉफ़्टवेयर ने वास्तव में स्थापित की है।

सूची से URI कॉपी करते समय उसके चारों ओर के उद्धरण रखें। बिना उद्धरण वाले अर्धविराम तर्क को पहली विशेषता पर काट देते हैं और क्लाइंट फिर ऐसी वस्तु की सूचना देता है जो उसे नहीं मिलती।

जब स्वचालित कुंजी-खोज हार मान लेती है

OpenConnect प्रमाणपत्र के URI से कुंजी-खोज निकाल सकता है, पर जो सटीक मिलान वह करता है वह संस्करण पर निर्भर है, और वस्तु प्रकार तथा लेबल का व्यवहार समय के साथ बदला है। URI को तब तक छोटा करने की सलाह पुराना उपाय बताती है, कोई आवश्यकता नहीं। अगर निकली हुई खोज विफल हो, तो प्रमाणपत्र के URI को और अस्पष्ट बनाने के बजाय -k से कुंजी का नाम स्पष्ट रूप से दें।

क्लाइंट को दोष देने से पहले p11tool --list-keys से पुष्टि करें कि कुंजी मौजूद है और दिखती है। फिर जाँचें कि वस्तु हस्ताक्षर या डिक्रिप्शन के लिए उपयोगी के रूप में चिह्नित है, क्योंकि गलत विशेषताओं से बनी कुंजी हैंडशेक पूरा नहीं कर सकती, चाहे URI कितना भी सही हो। OpenVPN प्रोफ़ाइल से क्रमबद्ध pkcs11-id मान को OpenConnect विकल्प में न ले जाएँ; एक ही कार्ड से बात करते हुए भी दोनों क्लाइंट अलग पहचानकर्ता प्रारूप इस्तेमाल करते हैं।

अगर URI हल हो जाए और PIN स्वीकार हो जाए पर प्रमाणीकरण फिर भी विफल हो, तो URI को ट्यून करना बंद करें। गेटवे की अपनी त्रुटि पढ़ें, क्योंकि अगली विफलता टोकन के ऊपर है।

ऐसी विफलताएँ जो सिर्फ़ URI समस्याओं जैसी लगती हैं

अलग प्रोटोकॉल बोलने वाला गेटवे आपका URI सही हो या गलत, एक जैसे विफल होगा। OpenConnect ने पुराने vpnc क्लाइंट को किसी कारण से बदला, और कार्ड समर्थन असंगत गेटवे प्रोटोकॉल को संगत नहीं बनाता। वस्तु की विशेषताओं पर एक और घंटा लगाने से पहले सर्वर का अपेक्षित प्रोटोकॉल और प्रमाणीकरण की व्यवस्था की पुष्टि करें।

सर्वर की पहचान का सत्यापन भी अलग परत है। क्लाइंट गेटवे के प्रमाणपत्र को अपने भरोसा भंडार के विरुद्ध सत्यापित करता है, और यह जाँच कार्ड अपना हिस्सा पूरा करने के बाद चलती है। रीडर अनुमतियाँ और बंद pcscd सेवा एक ही बाहरी लक्षण पैदा करती हैं, अपठनीय टोकन, पर समाधान कहीं आसान है।

वस्तु से बाहर की ओर काम करें: क्या p11tool टोकन देखता है, क्या वह प्रमाणपत्र और कुंजी देखता है, क्या OpenConnect URI स्वीकार करता है, और तभी पूछें कि गेटवे पहचान स्वीकार करता है या नहीं। हर चरण का अपना त्रुटि संदेश है, और हर एक अगले से जाँचने में सस्ता है।