बदलने से पहले: 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 की ओर इशारा करें तभी नामांकन अगला कदम बनता है, और पहले वाक्य में सही संज्ञा होने पर वह बातचीत कहीं अधिक तेज़ होती है।