Mac IKEv2 ECDSA: कौन-सा प्रमाणपत्र प्रकार क्लाइंट का है?
Mac पर, IKEv2 सेटिंग्स में ECDSA256 स्थानीय पहचान प्रमाणपत्र बताता है, गेटवे या जारीकर्ता की हस्ताक्षर नहीं। चुनने से पहले हर भूमिका पढ़ें।
macOS पर, IKEv2 क्लाइंट सेटिंग में ECDSA का चुनाव एक संकीर्ण प्रश्न का उत्तर देता है: कौन-सा प्रमाणपत्र Mac की पहचान सिद्ध करता है। यह गेटवे प्रमाणपत्र, क्लाइंट प्रमाणपत्र जारी करने वाली हस्ताक्षर, या टनल के लिए एन्क्रिप्शन प्रस्ताव का वर्णन नहीं करता। इन चार भूमिकाओं को एक ही अनुकूलता प्रश्न मानना वह तरीका है जिससे सही स्थानीय सेटिंग पर सर्वर-पक्ष की असंगति का दोष आ जाता है। निर्णय छोटा है, परंतु इसे लेने के लिए प्रयुक्त साक्ष्य सटीक होना चाहिए।
यह फ़ील्ड एक प्रमाणपत्र का नाम देता है: स्थानीय पहचान
Apple का Network Extension API क्लाइंट क्रेडेंशियल के लिए प्रमाणपत्र प्रकार प्रदान करता है, जिसमें NEVPNIKEv2CertificateType.ECDSA256 भी शामिल है, जिसे ECDSA p-256 प्रमाणपत्र प्रकार के रूप में प्रलेखित किया गया है। यह गुण identityReference या identityData के माध्यम से दिए गए प्रमाणपत्र पर लागू होता है।
इसका अर्थ है कि निर्णय उस प्रमाणपत्र के बारे में है जो Mac प्रस्तुत करता है, साथ में उसके साथ जाने वाली निजी कुंजी। उस लीफ़ प्रमाणपत्र की सार्वजनिक कुंजी से मेल खाने वाला प्रकार चुनें और समर्थित तंत्र के माध्यम से पहचान दें। यदि Mac के पास पहचान के लिए उपयोगी निजी कुंजी नहीं है, तो प्रकार का चुनाव कनेक्शन को नहीं बचा सकता।
प्रबंधित प्रोफ़ाइल IKEv2 पेलोड के CertificateType के माध्यम से वही निर्णय लेते हैं, साथ में PayloadCertificateUUID जैसे प्रमाणपत्र संदर्भ के साथ। उन फ़ील्डों में लक्षित OS संस्करण के लिए पूर्वापेक्षाएँ और स्कीमा हैं; प्रोफ़ाइल में नकल किया गया नंगा प्रकार-मान स्थापित नहीं होता, और सेटिंग्स विंडो हर API विकल्प न दिखा सके। परिनियोजन से पहले उस संस्करण के लिए पेलोड की पूर्वापेक्षाएँ जाँचें।
प्रमाणपत्र के लेबल से नहीं, भूमिका से तय करें
जिस फ़ील्ड को आप बदलने वाले हैं उसे पढ़ें और पूछें कि वह किस प्रमाणपत्र की ओर संकेत करता है। प्रमाणपत्र दर्शक में लेबल विषय, जारीकर्ता और हस्ताक्षर एल्गोरिद्म को मिला देते हैं, और उनमें से केवल एक ही क्लाइंट पहचान के चुनाव से संबंधित है।
| What you inspected | What it controls | Does it choose the Mac certificate type? |
|---|---|---|
| Client leaf public key | The identity the Mac presents | Yes, this is the field's subject |
| Issuer signature algorithm | How the client certificate was signed | No |
| Gateway certificate | What the Mac validates as the peer | No, check it separately |
| IKE and ESP proposals | Algorithms for the tunnel | No, separate proposal settings |
यदि प्रमाणपत्र दर्शक CA से ECDSA हस्ताक्षर दिखाता है, तो वह जारीकर्ता की हस्ताक्षर कुंजी बताता है। क्लाइंट की अपनी कुंजी अब भी RSA हो सकती है, और प्रकार-फ़ील्ड को हस्ताक्षर पंक्ति के बजाय क्लाइंट कुंजी का अनुसरण करना चाहिए। यही एक भ्रम "ECDSA कॉन्फ़िगर है पर कनेक्शन विफल होता है" वाली कई रिपोर्टों की व्याख्या करता है। कुछ भी बदलने से पहले लीफ़ की कुंजी-प्रकार की तुलना प्रोफ़ाइल में चुने गए प्रकार से करें।
लीफ़ की पहचान हो जाने पर निर्णय सरल हो जाता है: p-256 क्लाइंट कुंजी के लिए ECDSA256, भिन्न कुंजी के लिए दूसरा समर्थित प्रकार। यदि क्लाइंट प्रमाणपत्र और उसकी कुंजी मेल नहीं खाते, तो VPN प्रोफ़ाइल बदलने से पहले उस जोड़ी को ठीक करें।
गेटवे प्रमाणपत्र अलग निर्णय है
गेटवे अपना प्रमाणपत्र प्रस्तुत करता है और Mac उसे ट्रस्ट एंकर तथा अपेक्षित नाम के विरुद्ध सत्यापित करता है। वह प्रमाणपत्र ECDSA, RSA या कोई और कुंजी-प्रकार उपयोग करता है या नहीं, यह सर्वर का गुण है, क्लाइंट पहचान सेटिंग का नहीं।
ECDSA क्लाइंट प्रमाणपत्र के लिए स्थानीय समर्थन यह सिद्ध नहीं करता कि हर गेटवे प्रमाणपत्र, वक्र या सर्वर प्रमाणीकरण कॉन्फ़िगरेशन परस्पर काम करेगा। सर्वर की पहचान, उसकी श्रृंखला और IKE प्रमाणीकरण विधि को अलग इनपुट के रूप में जाँचें, और उसी प्रोफ़ाइल से परीक्षण करें जो वास्तव में परिनियोजित होगा।
यदि गेटवे प्रमाणपत्र ही समस्या है, तो लक्षण सामान्यतः पीयर सत्यापन के दौरान दिखता है, पहचान चुनाव के समय नहीं. क्लाइंट प्रकार बदलने से पहले विफलता का चरण पढ़ें, क्योंकि ट्रस्ट विफलता और क्लाइंट-कुंजी असंगति का उपाय एक नहीं है।
जारीकर्ता की हस्ताक्षर और कुंजी-सहमति समूह क्लाइंट का प्रकार नहीं हैं
X.509 विषय की सार्वजनिक कुंजी और जारीकर्ता की हस्ताक्षर को अलग-अलग फ़ील्ड में रखता है। विषय की सार्वजनिक कुंजी जानकारी प्रमाणपत्र में मौजूद कुंजी बताती है; हस्ताक्षर एल्गोरिद्म CA की कुंजी और हस्ताक्षर क्रिया बताता है। केवल पहला ही प्रमाणपत्र-प्रकार सेटिंग से मेल खाता है।
IKE और Child SA प्रस्ताव दूसरा अक्ष हैं। ECDSA प्रमाणपत्र प्रकार ESP एन्क्रिप्शन का चुनाव नहीं है, और कुंजी-सहमति समूह बदलने से प्रमाणपत्र प्रकार चयनित नहीं होता। प्रोफ़ाइल में वैध प्रस्ताव और गलत पहचान-प्रकार हो सकते हैं, या सही पहचान-प्रकार और ऐसा प्रस्ताव जिसे पीयर अस्वीकार करता है।
परिवर्तन रिकॉर्ड में तीन पंक्तियाँ अलग रखें: पहचान प्रमाणपत्र और कुंजी, गेटवे ट्रस्ट इनपुट, और प्रस्तावों के एल्गोरिद्म। इन्हें एक ही "क्रिप्टो सेटिंग्स" नोट में मिलाने से अगली विफलता का श्रेय देना असंभव हो जाता है।
जिन फ़ील्डों को आपने कॉन्फ़िगर किया उनसे निर्णय सत्यापित करें
प्रोफ़ाइल वास्तव में जिस पहचान का संदर्भ देती है उसे जाँचें, फिर पुष्टि करें कि उस संदर्भ के प्रमाणपत्र में अपेक्षित सार्वजनिक कुंजी और उपयोगी निजी कुंजी है। UI में दिखाया गया प्रकार, संदर्भित प्रमाणपत्र और डिवाइस पर मौजूद कुंजी—तीनों मेल खाने चाहिए।
इसके बाद गेटवे इनपुट की पुष्टि करें: अपेक्षित सर्वर नाम, ट्रस्ट एंकर और IKE प्रमाणीकरण विधि। अंत में कनेक्ट करें और देखें हैंडशेक कहाँ रुकता है। पहचान की अदला-बदली से पहले की विफलता इस सेटिंग से दूर संकेत करती है; पीयर सत्यापन में विफलता गेटवे पक्ष की ओर संकेत करती है।
चुना गया प्रकार, पहचान संदर्भ और गेटवे प्रमाणपत्र का विषय परिनियोजन नोट्स में दर्ज करें। अगला प्रोफ़ाइल अपडेट इनमें से कोई भी बदल सकता है, और तीन नामित मान सेटिंग्स पैनल के स्क्रीनशॉट की तुलना में तेज़ी से तुलना किए जा सकते हैं।