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