रूपान्तरण गर्नु अघि: SSH कुञ्जी बनाम OpenVPN प्रमाणपत्र

प्रमाणपत्र त्रुटिले आयात असफल हुन्छ, त्यसैले स्पष्ट कदम रूपान्तरणजस्तो देखिन्छ। त्यो प्रवृत्तिले मानिसहरूलाई फाइलको एक्सटेन्सन बदलिने तर अस्वीकृति ठ्याक्कै उही रहने बाटोमा लैजान्छ। authorized_keys मा रहेको ssh-ed25519 लाइन र OpenVPN क्लाइन्ट प्रमाणपत्र अलग अलग प्रमाणहरू हुन्, जसका जारीकर्ता, इन्कोडिङ र रद्द गर्ने बाटो फरक छन्। यी जाँचहरू क्रममा गरे एक मिनेटमै थाहा हुन्छ कि रूपान्तरणले केही मद्दत गर्न सक्छ कि सक्दैन।

वास्तवमा कुन वस्तु तपाईंसँग छ?

मानिसहरूले कुञ्जी भन्ने पाँच कुरा छन्, र तीमध्ये एउटा मात्र TLS प्रोफाइलले चाहने कुरा हो। SSH सार्वजनिक कुञ्जी भनेको प्रकार-उपसर्ग र base64 पेलोड भएको एक लाइनको पाठ हो। OpenSSH प्रमाणपत्र भनेको त्यो कुञ्जीमा हस्ताक्षर, principals र विकल्पहरू थपिएको हो, जुन ssh-keygen ले आफ्नै सानो CA का रूपमा काम गरी बनाउँछ। X.509 प्रमाणपत्र पूर्ण फरक संरचना हो, जसले विषय, वैधता अवधि, विस्तार र प्रमाणपत्र प्राधिकरणको हस्ताक्षर बोक्छ। निजी कुञ्जी गोप्य आधा हो, र जारी गरिएको बन्डल सामान्यतया एउटै फाइलमा प्रमाणपत्र, त्यसको शृंखला र निजी कुञ्जी हुन्छ।

पहिलो परीक्षणमा एउटा मात्र आदेश लाग्छ। openssl लाई फाइलतिर देखाउनुहोस् र प्रमाणपत्रको संरचना विश्लेषण गर्न भन्नुहोस्:

openssl x509 -in client.crt -noout -subject -issuer

त्यो unable-to-load वा PEM त्रुटिले असफल भयो भने, तपाईंले जे नाम दिए पनि त्यो फाइल X.509 प्रमाणपत्र होइन। नाम बदल्दा भित्रको ASN.1 पुनः लेखिँदैन, र सार्वजनिक कुञ्जीको लाइन PEM हेडर पाठमा बेर्दा पनि हुँदैन।

के प्रोफाइलले प्रमाणपत्र नै माग्छ?

क्लाइन्ट प्रमाणपत्र धेरै प्रमाणीकरण विधिमध्ये एक हो, र काम गर्ने धेरै TLS प्रोफाइलले कहिल्यै एउटा पनि माग्दैनन्। सर्भरले प्रयोगकर्ताहरूलाई प्लगइन, प्रयोगकर्ता नाम र पासवर्ड, वा टोकन ब्याकएन्डमार्फत प्रमाणीकरण गर्न सक्छ, तर पनि क्लाइन्टलाई सर्भरको पहिचान प्रमाणित गर्न भन्न सक्छ। प्रोफाइलमा क्लाइन्ट-प्रमाणपत्र निर्देशन नभए कहिल्यै प्रमाणपत्र मागिने छैन, र कुनै रूपान्तरणले गेटवेलाई एउटा माग्न बाध्य पार्ने छैन।

पुराना स्थिर-कुञ्जी कन्फिगरेसन तेस्रो अवस्था हुन्। ती TLS ह्यान्डशेकभन्दा अघिका हुन् र पहिले नै साझा गरिएको गोप्य फाइल अपेक्षा गर्छन्, त्यसैले त्यो फिल्डमा सार्वजनिक कुञ्जी टाँस्दा पनि काम हुँदैन। प्रमाण गलत छ भनी निर्णय गर्नु अघि प्रोफाइलले वास्तवमा के माग्छ त्यो पढ्नुहोस्।

पुनः इन्कोडिङले के गर्न सक्छ र के सक्दैन

निजी कुञ्जीहरूसँग साँच्चै वैध वैकल्पिक कन्टेनरहरू हुन्छन्। त्यही RSA वा EC कुञ्जीलाई परम्परागत PEM, PKCS#8, वा PKCS#12 बन्डलभित्र लेख्न सकिन्छ, र उपकरणहरू खुसीसाथ तिनीहरूबीच रूपान्तरण गर्छन्। सार्वजनिक कुञ्जीहरूको पनि उस्तै कथा छ: ssh-keygen ले SSH कुञ्जीको RFC 4716 रूप निकाल्न सक्छ, र OpenSSH ले आफ्नै प्रमाणपत्र ढाँचा पनि बुझ्छ। यी सबै प्रस्तुति हुन्, र प्रस्तुति विश्वास होइन।

रूपान्तरणले गर्न नसक्ने कुरा भनेको तपाईंको कुञ्जी कहिल्यै नदेखेको प्रमाणपत्र प्राधिकरणबाट हस्ताक्षर सिर्जना गर्नु हो। प्रमाणपत्र भनेको कुनै खास सार्वजनिक कुञ्जी कुनै खास उद्देश्यका लागि कुनै खास विषयको हो भन्ने जारीकर्ताको दाबी हो। पुनः इन्कोडिङले कुञ्जीका बाइटहरू जोगाउँछ र दाबी अनुपस्थित छोड्छ, त्यसैले गेटवेसँग आफ्नो विश्वास-भण्डारसँग जाँच्न केही हुँदैन।

अधिकांश प्रयास चुपचाप असफल हुने चरण यही हो: फाइल अब .crt मा अन्त्य हुन्छ, क्लाइन्टले त्यो उजुरीविना पढ्छ, र ह्यान्डशेक तैपनि रोकिन्छ किनकि सामु पक्षले विश्वसनीय जारीकर्तासम्म शृंखला बनाउन सक्दैन।

प्रमाणपत्र प्राधिकरण चित्रमा कहाँ आउँछ

साँचो दर्ता तपाईंको नियन्त्रणको कुञ्जी-जोडी र अपरेटरले अपेक्षा गर्ने विषय बोक्ने प्रमाणपत्र हस्ताक्षर अनुरोधबाट सुरु हुन्छ। अपरेटरले हक जाँच्छ, CA कुञ्जीले अनुरोधमा हस्ताक्षर गर्छ, र जारी गरिएको प्रमाणपत्र क्लाइन्टले प्रस्तुत गर्नुपर्ने कुनै पनि मध्यस्थ शृंखलासँग फर्काउँछ। त्यसपछि क्लाइन्टलाई त्यसमा हस्ताक्षर गर्ने CA प्रमाणपत्र चाहिन्छ, किनकि आफू बोलिरहेको सर्भर त्यही परिनियोजनको हो भनी पुष्टि गर्न त्यसैले दिन्छ।

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

SSH कुञ्जी पुनः प्रयोग गर्दा लाग्ने मूल्य

मान्नुहोस् कुनै रूपान्तरणले साँच्चै स्वीकार्य केही बनायो। SSH पहुँच र VPN प्रमाणीकरणका लागि एउटै कुञ्जी-जोडी पुनः प्रयोग गर्दा अझै दुई स्वतन्त्र सुरक्षा निर्णय जोडिन्छन्। authorized_keys बाट एक लाइन हटाउँदा SSH लगइन रोकिन्छ, र त्यही सार्वजनिक कुञ्जीका लागि VPN CA ले पहिले नै जारी गरेको प्रमाणपत्रमा केही हुँदैन। VPN पक्ष आफ्नै संयन्त्रबाट रद्द हुन्छ, अर्थात् प्रमाणपत्र रद्दीकरण सूची वा अपरेटरको दर्ता अभिलेख।

त्यसैले चेकलिस्ट कुनै चलाखीले होइन, रोकिने सर्तले अन्त्य हुन्छ। openssl ले फाइललाई प्रमाणपत्रका रूपमा विश्लेषण गर्दैन भने रूपान्तरण रोक्नुहोस् र तपाईंसँग के छ भन्नुहोस्: SSH कुञ्जी, SSH प्रमाणपत्र, X.509 प्रमाणपत्र, निजी कुञ्जी वा बन्डल। प्रोफाइलले क्लाइन्ट प्रमाणपत्र माग्दैन भने रोक्नुहोस् र सर्भरले कुन प्रमाणीकरण विधि अपेक्षा गर्छ सोध्नुहोस्। दुवै उत्तरले X.509 देखाए मात्र दर्ता अर्को चरण बन्छ, र पहिलो वाक्यमा सही नाम भए त्यो कुराकानी धेरै छिटो हुन्छ।