प्रमाणपत्र बदलने के बाद OpenConnect गेटवे को क्यों अस्वीकार करता है?
गेटवे का प्रमाणपत्र बदलने के बाद सत्यापन विफलता विश्वास का निर्णय है, टूटी सुरंग नहीं। जारीकर्ता CA और एक ही कुंजी को पिन करने के बीच चुनें।
गेटवे प्रमाणपत्र बदलते हैं, और कल तक जुड़ा क्लाइंट पहले TLS आदान-प्रदान पर रुकने लगता है। संदेश नेटवर्क खराबी के बजाय सत्यापन का कारण बताता है, और मशीन खुद नहीं बदली, यही उपयोगी सुराग है। जो टूटा है वह अब प्रस्तुत प्रमाणपत्र और उन मूलों के बीच का संबंध है जिन्हें क्लाइंट स्वीकार करने को तैयार है। इसे ठीक करना विश्वास का निर्णय है, इसलिए कोई विकल्प लिखने से पहले वह निर्णय लें।
कोई भी विश्वास सेटिंग बदलने से पहले विफलता पढ़ें
अनुपस्थित हस्ताक्षरकर्ता जैसी त्रुटि का अर्थ है कि श्रृंखला किसी ऐसी चीज़ पर समाप्त होती है जिसे क्लाइंट स्वीकार नहीं करता। यह आंतरिक प्राधिकरण का नवीनीकृत प्रमाणपत्र, किसी सार्वजनिक प्राधिकरण का प्रतिस्थापन, या बीच में रखा कोई उपकरण हो सकता है जो अपना प्रमाणपत्र प्रस्तुत करता है। केवल शब्दावली उन मामलों में भेद नहीं कर सकती, इसलिए निर्णय से पहले जारीकर्ता को देखें।
कनेक्शन को एक बार अग्रभूमि में चलाएँ और उसे विफल होने दें, क्योंकि इंटरैक्टिव आउटपुट में सर्वर नाम, जारीकर्ता श्रृंखला और क्लाइंट द्वारा गणना की गई फ़िंगरप्रिंट होती है। उस जारीकर्ता की तुलना ऐसे प्राधिकरण से करें जिसे आपका संगठन वास्तव में संचालित करता है। यदि फ़िंगरप्रिंट बदला और जारीकर्ता नहीं, तो इसे संदिग्ध मानें जब तक कि आपके द्वारा पहले से भरोसेमंद किसी माध्यम से नवीनीकरण की पुष्टि न हो जाए। इस समय अनुमान लगाना ही वह रास्ता है जिससे कोई अंततः बीच में आने वाले की कुंजी पिन कर देता है।
उसी नोट में क्लाइंट संस्करण लिखें। विश्वास की समस्या जैसी दिखने वाली कई विफलताएँ पुराने क्लाइंट के नए गेटवे आदान-प्रदान से टकराने से आती हैं।
जारीकर्ता पर भरोसा करने और एक कुंजी पिन करने के बीच चुनें
दोनों विकल्प कनेक्शन सफल बनाते हैं। बाद में वे विपरीत तरीकों से टूटते हैं, इसलिए चुनाव उस विफलता का है जिसे आप सह सकते हैं।
| Approach | Good fit | What breaks it |
|---|---|---|
Trust the issuing CA with --cafile | Internal PKI you can obtain over an already trusted channel | CA rotation, or a client that still falls back to public roots |
Pin one key with --servercert | No CA relationship, or exactly one key should ever be accepted | Any reissue that generates a new key pair |
CA फ़ाइल की ओर जाएँ जब प्रमाणपत्र ऐसे प्राधिकरण से आता है जिसे आप स्वतंत्र रूप से सत्यापित कर सकते हैं, क्योंकि तब नवीनीकरण क्लाइंट आर्गुमेंट छुए बिना काम करते रहते हैं। इसे उस स्विच के साथ जोड़ें जो सिस्टम मूलों को अक्षम करता है, अन्यथा कोई सार्वजनिक प्राधिकरण आपकी ओर से जाँच पूरी कर सकता है। इसके बजाय पिन करें जब गेटवे के पास ऐसा CA न हो जो आप प्राप्त कर सकें, या जब लक्ष्य सबसे संकीर्ण संभव अपवाद हो। कोई भी मार्ग अमूर्त रूप से अधिक सुरक्षित नहीं है: CA नवीनीकरणों में विस्तारित होता है, पिन की समीक्षा आसान है।
आप जो भी चुनें, भरोसेमंद मूल्य ऐसे माध्यम से आना चाहिए जो परिवर्तन से पहले भरोसेमंद था। प्रशासक, गेटवे पर कंसोल सत्र, या पहले से ली गई प्रति सभी योग्य हैं। प्रॉम्प्ट जो भी फ़िंगरप्रिंट दिखाए उसे कॉपी करना सुविधाजनक है और ठीक वही है जिसकी बीच में आने वाला आशा करता है।
मान को उसी कमांड में रखें जिसे आप वास्तव में चलाते हैं
पिन सर्वर-प्रमाणपत्र विकल्प में जाता है, और उसका उपसर्ग एन्कोडिंग तय करता है: sha1 या sha256 के अंतर्गत हेक्साडेसिमल सार्वजनिक-कुंजी डाइजेस्ट, और pin-sha256 के अंतर्गत base64 कुंजी पिन। इसे देने से उस रन के लिए सिस्टम भरोसा भी अक्षम हो जाता है, इसलिए पिन की गई कुंजी ही पूरा निर्णय बन जाती है।
sudo openconnect --protocol=gp vpn.example.com --user alice \
--servercert pin-sha256:AbCdEf... # single key pin
sudo openconnect vpn.example.com --cafile /etc/ssl/internal-ca.pem --no-system-trustक्लाइंट कटे हुए डाइजेस्ट का मिलान करता है, उपसर्ग के बाद केवल चार वर्ण भी स्वीकार करता है, जो सुविधा नहीं बल्कि जाल है। छोटा मान स्थानीय रूप से पास हो जाता है और फिर भी उस गेटवे की पहचान नहीं करता जिसका आपने इरादा किया था। संदेश से दोबारा टाइप करने के बजाय पहले प्रयास में क्लाइंट द्वारा छापी गई पूरी स्ट्रिंग कॉपी करें। फिर तैयार विकल्प को उस रैपर स्क्रिप्ट, यूनिट फ़ाइल या प्रोफ़ाइल में ले जाएँ जो कनेक्शन शुरू करती है, ताकि विश्वास का निर्णय समीक्षायोग्य रहे और बाद के संपादन जानबूझकर हों।
डेस्कटॉप लॉन्चर और NetworkManager प्लगइन कनेक्शन आर्गुमेंट की अपनी प्रति रखते हैं। डिस्क पर संपादित स्क्रिप्ट पहले आयातित प्रोफ़ाइल तक नहीं पहुँचती, इसलिए संग्रहीत मान जीतता रहता है।
खुद को बाहर बंद किए बिना रोलओवर संभालें
विकल्प एक से अधिक बार दिया जा सकता है, इसलिए नियोजित परिवर्तन बाहर जाती और अंदर आती कुंजियों को साथ स्वीकार कर सकता है। गेटवे बदलने से पहले नया पिन जोड़ें, सत्रों के स्थानांतरण के दौरान दोनों को सूचीबद्ध रखें, और पुरानी कुंजी जाने पर सेवानिवृत्त को हटा दें। उस खिड़की को एक मालिक चाहिए, क्योंकि भूला हुआ दोहरा पिन किसी कुंजी को बिना किसी निगरानी के भरोसेमंद छोड़ देता है। नई कुंजी-जोड़ी बनाने वाला पुनर्निर्माण शुद्ध पिन को तोड़ता है, और पुनर्प्राप्ति दूसरी दिशा में वही प्रक्रिया है।
पिन के बगल में परिवर्तन की तारीख लिखें। समीक्षा तिथि के बिना पिन भ्रमित करने वाले त्रुटि संदेश वाला भविष्य का व्यवधान है।
विश्वास संपादित करने से पहले क्लाइंट संस्करण को बाहर रखें
पुराना क्लाइंट गेटवे द्वारा बाद में बदले गए प्रमाणीकरण उत्तर को पार्स करते समय विफल हो सकता है, और सतही संदेश अब भी पार्सर के बजाय कनेक्शन की बात करता है। स्थापित संस्करण की तुलना उससे करें जो गेटवे दस्तावेज़ित करता है, और कोई भी विश्वास सेटिंग बदलने से पहले मौजूदा पैकेज को एकबारगी प्रोफ़ाइल में परखें।
openconnect --versionमरम्मत के बाद एक नहीं, दो चीज़ें सत्यापित करें: पोर्टल सुरंग से लोड होता है, और एक सामान्य आंतरिक पता उत्तर देता है। पूरा हुआ हैंडशेक केवल यह सिद्ध करता है कि विश्वास का निर्णय स्वीकार किया गया।