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 प्रमाणीकरण पद्धत. शेवटी कनेक्ट करा आणि हँडशेक कुठे थांबतो ते वाचा. ओळखीच्या देवाणघेवाणीपूर्वीची अयशस्वीता या सेटिंगपासून दूर निर्देश करते; पीअर सत्यापनातील अयशस्वीता गेटवे बाजूकडे निर्देश करते.
निवडलेला प्रकार, ओळख संदर्भ आणि गेटवे प्रमाणपत्राचा विषय तैनाती नोंदींमध्ये लिहा. पुढील प्रोफाइल अद्यतन त्यातील कोणतेही बदलू शकते, आणि तीन नामनिर्देशित मूल्ये सेटिंग्ज पॅनेलच्या स्क्रीनशॉटपेक्षा वेगाने तुलना करता येतात.