VPN कुंजी फ़ाइल में RSA के n, e, d, p और q कहाँ रहते हैं
n, e, d, p और q एक ही संरचना के भीतर हैं, फ़ाइल नामों में नहीं। OpenSSL से RSA VPN कुंजी पढ़ें और बिना कोई रहस्य छापे उसे उसके प्रमाणपत्र से मिलाएँ।
RSA की व्याख्या में अक्षर एक ही वस्तु के भीतर के क्षेत्रों के नाम हैं, PKI औज़ार जो फ़ाइलें देता है उनके नहीं। निजी कुंजी फ़ाइल ऐसी संरचना रखती है जिसके पहले क्षेत्र सार्वजनिक हैं और बाद के क्षेत्र उस मशीन से कभी बाहर नहीं जाने चाहिए जो सुरंग समाप्त करती है। इन दो तथ्यों के बीच कौन-सी फ़ाइल किस प्रश्न का उत्तर देती है, इस पर अधिकांश व्यावहारिक प्रश्न हैं। यह पुस्तिका पहले संरचना पढ़ती है, फिर उन आदेशों को जो उसे बिना बहाए जाँचते हैं।
अभाज्य संख्याएँ खोजने से पहले पुष्टि करें कि कुंजी RSA है
प्रमाणपत्र साबित करता है कि कोई कुंजी मौजूद है और हस्ताक्षरित हुई; यह साबित नहीं करता कि कुंजी RSA है। तंत्र दीर्घवृत्तीय वक्रों या Ed25519 पर बनाए जा सकते हैं, और वही निर्देशिका विन्यास उन सबकी सेवा करता है। उन अभाज्य गुणनखंडों को खोजने से पहले एल्गोरिद्म जाँचें जो कभी थे ही नहीं।
ये तीन केवल-पढ़ने वाले आदेश प्रश्न का उत्तर देते हैं और औज़ार का संस्करण दर्ज करते हैं।
openssl version
openssl x509 -in vpn-client.crt -noout -text
openssl pkey -in vpn-client.key -noout -text
संस्करण मायने रखता है क्योंकि विकल्पों के नाम प्रमुख संस्करणों के बीच खिसके हैं। प्रमाणपत्र के आउटपुट में सार्वजनिक कुंजी एल्गोरिद्म की पंक्ति और कुंजी का आकार खोजें; कुंजी के आउटपुट में RSA कुंजी एक मापांक और एक सार्वजनिक घातांक छापती है। दीर्घवृत्तीय वक्र की कुंजी इसके बजाय एक नामित वक्र छापती है, और कोई भी खोज उससे n या q नहीं निकालेगी।
base64 के बजाय संरचना पढ़ें
PEM हेडर पंक्तियों में लिपटा base64 है, और उसे डिकोड करने पर DER मिलता है, अर्थात क्रमबद्ध संरचना, कोई विशाल पूर्णांक नहीं। RSA निजी कुंजियाँ दो सामान्य कंटेनरों में यात्रा करती हैं, PKCS#1 और PKCS#8, और दोनों उन्हीं संख्याओं के समुच्चय पर पहुँचती हैं।
दो अभाज्य संख्याओं के मामले में निजी संरचना नौ क्षेत्र रखती है: एक संस्करण, मापांक n, सार्वजनिक घातांक e, निजी घातांक d, अभाज्य संख्याएँ p और q, दो CRT घातांक और एक CRT गुणांक। RFC 8017 अनुच्छेद A.1 उन घटकों और ASN.1 विन्यास को परिभाषित करता है, और दो से अधिक अभाज्य संख्याओं की भी अनुमति देता है, इसलिए एक सामान्य पार्सर अतिरिक्त अभाज्य प्रविष्टियाँ छाप सकता है। क्रम पर ध्यान दें, क्योंकि यह एक आम भूल समझाता है: सार्वजनिक आधा भाग निजी फ़ाइल के भीतर संग्रहित होता है, इसलिए सार्वजनिक क्षेत्र की उपस्थिति उस फ़ाइल को साझा करने योग्य सुरक्षित नहीं बनाती। इसके बाद जो कुछ है वही वह सामग्री है जो होस्ट पर ही रहनी चाहिए।
एन्कोडिंग ऐसी परत जोड़ती है जिसे सामग्री से भ्रमित करना आसान है। openssl asn1parse संरचना को वृक्ष की तरह खींचता है ताकि क्षेत्रों का क्रम दिखाई दे, और यह कुछ भी डिक्रिप्ट नहीं करता और यह भी नहीं बताता कि कुंजी उपयोगी है या नहीं।
कुंजी छापे बिना प्रमाणपत्र को कुंजी से मिलाएँ
इसके बाद का प्रश्न आमतौर पर यह होता है कि प्रमाणपत्र और कुंजी एक साथ हैं या नहीं। मापांकों की तुलना इसका उत्तर देती है, पर वह निजी के निकट की सामग्री टर्मिनल प्रतिलिपि में भी कॉपी करती है जो टिकट में पहुँच सकती है। सार्वजनिक अर्धभागों की तुलना उसी प्रश्न का उत्तर स्क्रीन पर कुछ भी संवेदनशील रखे बिना देती है।
openssl pkey -in vpn-client.key -pubout -out /tmp/key.pub
openssl x509 -in vpn-client.crt -pubkey -noout > /tmp/cert.pub
cmp /tmp/key.pub /tmp/cert.pub && echo MATCH
समान फ़ाइलों का अर्थ है कि प्रमाणपत्र उस कुंजी का सार्वजनिक आधा भाग रखता है, और अंतर का अर्थ है कि आपके पास गलत जोड़ी है। यही असंगति उस सुरंग का सबसे आम कारण है जो खुशी से बातचीत करती है और फिर प्रमाणीकरण से इनकार कर देती है। इसके बाद दो अस्थायी फ़ाइलें हटा दें; उनमें कुछ भी गुप्त नहीं है, पर घटना के बीच में साफ़ कार्य निर्देशिका पर विचार करना आसान है।
जानें पड़ोसी फ़ाइलें क्या नहीं हैं
प्रमाणपत्र वह एन्क्रिप्टेड सार्वजनिक कुंजी नहीं है जिसे साथी CA प्रमाणपत्र से खोलता है; यह सार्वजनिक कुंजी और पहचान डेटा के बीच हस्ताक्षरित बंधन है। CA की निजी हस्ताक्षर कुंजी अपने ही प्रमाणपत्र और हर क्लायंट कुंजी से अलग रहती है। अनुरोध भी प्रमाणपत्र नहीं है: वह अनुरोधित जानकारी और सार्वजनिक कुंजी के साथ अनुरोध पर हस्ताक्षर रखता है, जो उसे नामांकन इनपुट बनाता है, अधिकार का प्रमाण नहीं।
| File | Answers | Does not prove |
|---|---|---|
| vpn-client.key | Possession of the private key | That the identity is enrolled |
| vpn-client.crt | A signed binding of public key to identity | That the client holds the matching key |
| vpn-client.csr | The requested binding and public key | That access was granted |
| dh2048.pem | Group parameters for key exchange | Any RSA component |
| crl.pem | Revocation status for certificates | Anything about a private key |
इनमें से दो प्रविष्टियाँ RSA पैरामीटरों से इतनी बार भ्रमित होती हैं कि उन्हें दो बार नाम देना पड़ता है। Diffie-Hellman पैरामीटर फ़ाइल में कुंजी स्थापना के लिए समूह पैरामीटर होते हैं और कोई RSA अभाज्य संख्या नहीं, हालाँकि वह भी बड़ी अभाज्य संख्या के रूप में छपती है। निरसन सूची प्रमाणपत्रों की स्थिति प्रकाशित करती है और ऐसा स्थान नहीं है जहाँ निजी घातांक छिप सके।
इसलिए हर सूची पंक्ति को चार बातें दर्ज करनी चाहिए: वस्तु का प्रकार, स्वामी, उद्देश्य और क्या निजी सामग्री शामिल है। अंतिम स्तंभ तय करता है कि फ़ाइल कहाँ कॉपी की जा सकती है, और लोग उसी को छोड़ देते हैं।
जोड़ी दर्ज करें, फिर हैंडशेक सत्यापित करें
कुछ भी बदलने से पहले सत्यापन का आउटपुट तारीख और OpenSSL संस्करण के साथ सहेजें। तब बाद का रोटेशन स्मृति के बजाय प्रमाण से तुलना किया जा सकेगा।
openssl verify -CAfile ca.crt vpn-client.crt
openssl x509 -in vpn-client.crt -noout -subject -issuer -dates
सार्वजनिक कुंजी की तुलना के बाद उस पथ को चलाएँ जो जोड़ी का उपभोग करता है: सुरंग ऊपर लाएँ, पुष्टि करें कि प्रमाणपत्र प्रस्तुत और स्वीकृत होता है, और देखें कि गेटवे ने कौन-सी पहचान दर्ज की। यदि कुंजी और प्रमाणपत्र मेल खाते हैं और प्रमाणीकरण फिर भी विफल होता है, तो दोष जोड़ी में नहीं, विश्वास, पहचान मैपिंग या पहुँच नीति में है।
वापसी के लिए पिछली कुंजी और प्रमाणपत्र को तारीखवाली निर्देशिका में रखें और दोनों को साथ बहाल करें, कभी एक को नहीं। प्रमाणपत्र के बिना कुंजी और कुंजी के बिना प्रमाणपत्र बाहर से एक जैसे विफल होते हैं, जिससे आधी बहाल जोड़ियों को रात दो बजे सुलझाना महँगा हो जाता है।