प्रमाणपत्र त्रुटीमुळे आयात अयशस्वी होते, म्हणून स्पष्ट पाऊल रूपांतरासारखे दिसते। ही प्रवृत्ती लोकांना अशा मार्गावर नेते जिथे फाइलचा विस्तार बदलतो पण नाकारणे अगदी तसेच राहते। 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 कडे निर्देश करतात तेव्हाच नोंदणी पुढचे पाऊल बनते, आणि पहिल्या वाक्यात योग्य नाम असल्यास तो संवाद खूप वेगाने होतो।

संबंधित लेख