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सार्वजनिक कुञ्जीको तुलनापछि जोडी प्रयोग गर्ने बाटो चलाउनुहोस्: सुरुङ माथि उठाउनुहोस्, प्रमाणपत्र प्रस्तुत र स्वीकार हुन्छ भनी पुष्टि गर्नुहोस्, र गेटवेले कुन पहिचान दर्ता गर्यो हेर्नुहोस्। कुञ्जी र प्रमाणपत्र मिल्दा पनि प्रमाणीकरण असफल भइरहेमा, दोष जोडीमा होइन, विश्वास, पहिचान म्यापिङ वा पहुँच नीतिमा छ।
फर्काउनका लागि अघिल्लो कुञ्जी र प्रमाणपत्र मिति भएको निर्देशिकामा राख्नुहोस् र दुवै सँगै पुनर्स्थापित गर्नुहोस्, कहिल्यै एउटा मात्र होइन। प्रमाणपत्र नभएको कुञ्जी र कुञ्जी नभएको प्रमाणपत्र बाहिरबाट उस्तै असफल हुन्छन्, जसले आधा पुनर्स्थापित जोडीलाई राति दुई बजे छुट्याउन महँगो बनाउँछ।