Mac VPN प्रमाणपत्र: पहचान चयनकर्ता खाली क्यों रहता है
क्लाइंट को अपनी निजी कुंजी के साथ प्रमाणपत्र चाहिए, ऐसे भंडार में जिसे वह पढ़ता है। पहले पहचान जाँचें, फिर देखें कि गेटवे उसे स्वीकार करता है या नहीं।
आपने प्रमाणपत्र इंस्टॉल किया, यह Keychain Access में एक सुलभ नाम के साथ दिखता है, और VPN क्लाइंट का पहचान चयनकर्ता अब भी खाली है। क्लाइंट प्रमाणपत्र नहीं खोज रहा है। वह पहचान खोज रहा है: निजी कुंजी के साथ जुड़ा प्रमाणपत्र जो स्वामित्व साबित कर सके, वहाँ संग्रहीत जहाँ क्लाइंट को उसे पढ़ने की अनुमति है।
क्लाइंट जो माँगता है वह पहचान है
Apple का सुरक्षा ढाँचा प्रमाणपत्र और पहचान को अलग-अलग वस्तुओं के रूप में देखता है। प्रमाणपत्र सार्वजनिक डेटा है। पहचान वह प्रमाणपत्र और उसकी निजी कुंजी है, और केवल पहचान ही चुनौती पूरी कर सकती है। विश्वसनीय CA प्रमाणपत्र, दूसरी ओर, क्लाइंट को जारीकर्ता का मूल्यांकन करने देता है; यह मशीन को जारी किए गए क्लाइंट क्रेडेंशियल का धारक नहीं बनाता।
| Item | What it can do | What it cannot do |
|---|---|---|
| CA or server certificate | Validate the gateway's chain | Authenticate this client |
| Client certificate without key | Nothing for authentication | Prove possession of anything |
| Identity (cert plus key) | Answer the authentication challenge | Guarantee the gateway accepts it |
इसीलिए .cer फ़ाइल आयात करने से कभी उपयोगी क्लाइंट पहचान नहीं बनती। फ़ाइल में केवल सार्वजनिक सामग्री होती है। उसे कितना भी नाम बदलें या विश्वसनीय ठहराएँ, वह कुंजी-युग्म नहीं बनती।
चयनकर्ता खाली रहने के तीन कारण
पहला है अनुपस्थित निजी कुंजी, यानी नामांकन या आयात प्रक्रिया ने एक भी नहीं दी। दूसरा है ऐसा भंडार जिसे क्लाइंट नहीं देखता: उपयोगकर्ता-स्तरीय प्रोफ़ाइल उपयोगकर्ता के कीचेन में देखती है, और सिस्टम भंडार में रखी वस्तु उसे अदृश्य हो सकती है। तीसरा है उद्देश्य या नीति का बेमेल, जहाँ प्रमाणपत्र मौजूद है पर तैनाती के नियमों के तहत क्लाइंट प्रमाणीकरण के लिए वैध नहीं है।
security find-identity -v -p ssl-clientयह उन पहचानों की सूची देता है जिन्हें सिस्टम क्लाइंट प्रमाणीकरण के लिए वैध मानता है। यदि गिनती शून्य है, तो समस्या VPN क्लाइंट से पहले है और प्रोफ़ाइल में कोई भी संपादन उसे ठीक नहीं करेगा। यदि पहचान यहाँ दिखती है पर क्लाइंट में नहीं, तो अंतर क्लाइंट के भंडार या दायरे में है।
निजी कुंजी कहाँ रहती है, और कौन उसका उपयोग कर सकता है
जब आप Keychain Access के माध्यम से पहचान आयात करते हैं, तो आयात संवाद गंतव्य कीचेन प्रस्तावित करता है। कौन-सा गंतव्य सही है यह क्लाइंट पर और इस पर निर्भर करता है कि प्रोफ़ाइल उपयोगकर्ता-स्तरीय है या डिवाइस-स्तरीय। सिस्टम कीचेन की सिफ़ारिश करने वाला पुराना उत्तर सार्वभौमिक नियम नहीं है, और भंडारों के बीच वस्तुओं की नकल करना मरम्मत नहीं है।
System Roots एक विश्वास संग्रह है। वहाँ प्रमाणपत्र रखने से बदलता है कि सिस्टम किन जारीकर्ताओं पर भरोसा करता है; यह निजी कुंजी नहीं बनाता, और यह पहचान भंडार नहीं है। चयनकर्ता भरने के लिए असंबंधित प्रमाणपत्र इधर-उधर करना ऐसी मरम्मत है जो मशीन को स्थायी रूप से विस्तारित विश्वास समुच्चय के साथ छोड़ देती है।
निजी कुंजी तक पहुँच एक अलग नियंत्रण है। हर एप्लिकेशन को कुंजी उपयोग करने की अनुमति देना एक क्लाइंट की चयन समस्या हल करता है और वही क्षमता मशीन पर बाकी सबको दे देता है। इसे उस क्लाइंट को दें जिसे इसकी आवश्यकता है, और जाँचें कि कुंजी हार्डवेयर-समर्थित है या निर्यात-अयोग्य के रूप में चिह्नित है; यदि हाँ, तो निर्यातित प्रति के बजाय समर्थित प्रदाता का उपयोग करना होगा।
प्रोफ़ाइल क्रेडेंशियल की ओर कैसे संकेत करती है
प्रबंधित मूल IKEv2 कॉन्फ़िगरेशन में, प्रोफ़ाइल PayloadCertificateUUID के माध्यम से अपने क्रेडेंशियल पेलोड का संदर्भ देती है। संदर्भित पहचान और उसे कैसे प्रदान किया गया, यही मायने रखता है; प्रोफ़ाइल में प्रदर्शित नाम संपादित करने से ऐसा संदर्भ ठीक नहीं होता जो गलत पेलोड या ऐसे पेलोड की ओर इशारा करता है जिसने कभी कुंजी नहीं दी।
तृतीय-पक्ष प्रदाता पूरी तरह अलग चयन तंत्र का उपयोग कर सकता है, जैसे अपना भंडार या सिस्टम संकेत। मूल प्रोफ़ाइल की धारणाएँ स्थानांतरित करने के बजाय उस प्रदाता का दस्तावेज़ पढ़ें, और संदर्भ को वास्तव में इंस्टॉल प्रोफ़ाइल में सत्यापित करें, प्रबंधन कंसोल के मसौदे में नहीं।
चयन और स्वीकृति अलग-अलग पड़ाव हैं
भरा हुआ चयनकर्ता मतलब क्लाइंट पहचान खोज और उपयोग कर सकता है। यह नहीं बताता कि गेटवे उसे स्वीकार करेगा या नहीं। सर्वर अब भी जारीकर्ता, वैधता विंडो और निरसन स्थिति की जाँच करता है, तथा उस क्रेडेंशियल से खाते तक के मैपिंग।
दोनों चरणों को स्पष्ट रूप से, उसी क्रम में परखें। पुष्टि करें कि पहचान प्रस्तावित है, कनेक्ट करें, और फिर गेटवे के स्वामी से पुष्टि कराएँ कि कौन-सा क्रेडेंशियल प्रस्तुत हुआ और किस मैपिंग नियम ने उसे खपाया। यदि क्लाइंट पहचान प्रस्तावित करता है और सर्वर उसे अस्वीकार करता है, तो शेष काम सर्वर पक्ष पर है। Mac पर प्रमाणपत्र फिर से इंस्टॉल करने से वह परिणाम नहीं बदलेगा, चाहे इसे कितनी भी बार दोहराया जाए।