प्रत्येक उपकरणासाठी एक प्रमाणपत्र असल्याने की उपकरणाशी बांधली जात नाही
प्रत्येक उपकरणासाठी प्रमाणपत्र ही प्रशासकीय निवड आहे, उपकरणाशी बांधणी नाही। बांधणी काय ठरवते ते म्हणजे खाजगी की कुठे राहते, प्रत करता येणाऱ्या फाइलपासून TPM पर्यंत।
तुम्ही प्रत्येक लॅपटॉपसाठी वेगळे प्रमाणपत्र देता, म्हणून VPN त्यांना वेगळे ओळखू शकेल असे गृहीत धरता। ते ओळखू शकत नाही। क्लायंट प्रमाणपत्र सिद्ध करते की जो जोडतो त्याच्याकडे जुळणारी खाजगी की आहे, आणि प्रत केलेल्या प्रोफाइलकडेही ती असते।
प्रत्येक उपकरणासाठी प्रमाणपत्र अजूनही चांगली कल्पना आहे। ते फक्त बहुतेक लोक अपेक्षा करतात त्यापेक्षा वेगळे काम करते।
क्लायंट प्रमाणपत्र प्रत्यक्षात काय सिद्ध करते
हँडशेक दरम्यान क्लायंट त्याच्या प्रमाणपत्राशी जुळणाऱ्या खाजगी कीने स्वाक्षरी करतो, आणि सर्व्हर ती स्वाक्षरी आपण विश्वास ठेवतो त्या CA विरुद्ध तपासतो। त्या देवाणघेवाणीत मशीनचे कोणतेही वर्णन नाही। प्रमाणपत्र आणि की दोन्ही असलेले कोणतेही उपकरण एकसारखी स्वाक्षरी तयार करते, म्हणून दुसऱ्या लॅपटॉपवर प्रत केलेले प्रोफाइल मूळसारखेच दिसते। प्रमाणपत्र ओळखीचे नाव देते; हार्डवेअरचे नाव देत नाही।
प्रत्येक उपकरणासाठी वेगळेपण अजूनही उपयुक्त आहे, कारण ते रद्द करणे अचूक करते। हा प्रशासकीय गुणधर्म आहे, तांत्रिक कुलूप नाही।
की साठवणीचे तीन स्तर
पहिला स्तर डिस्कवरची की फाइल आहे। ती रचनेनुसारच वाहून नेण्यायोग्य आहे, आणि बहुतेक OpenVPN प्रोफाइल तिथेच राहतात।
दुसरा स्तर अशी की आहे जी ऑपरेटिंग सिस्टम निर्यात-अयोग्य म्हणून चिन्हांकित करते। Windows आपल्या प्रमाणपत्र संग्रहात उपकरणाची की तयार करू शकते आणि सामान्य निर्यात नाकारू शकते, ज्यामुळे अचानक प्रत रद्द होते। ती हार्डवेअर-आधारित नाही, आणि मशीनपर्यंत पुरेसा प्रवेश असल्यास अशा की परत मिळवता येतात, म्हणून ती भिंत बांधण्याऐवजी कष्ट वाढवते।
तिसरा स्तर सुरक्षा हार्डवेअरच्या आत तयार होणारी की आहे: TPM, स्मार्ट कार्ड, SIM किंवा PIV टोकन। त्या मॉड्यूलमध्ये स्वतः तयार केलेली की निर्यात करण्याचे परिपथ नाही, आणि स्वाक्षरी मॉड्यूलच्या आतच होते। की कधीही कोणीही प्रत करू शकेल अशी फाइल बनत नाही।
| Where the key lives | Copyable | What it buys you |
|---|---|---|
| Key file inside the profile | Trivially | Revocation granularity, nothing more |
| OS non-exportable key store | Hard, not impossible | Stops casual profile sharing |
| TPM or PIV token | No | Binding the server can rely on |
ते तक्ते तीन ओळींतले संपूर्ण युक्तिवाद आहे।
easy-rsa काय करू शकते आणि काय करू शकत नाही
प्रत्येक उपकरणासाठी प्रमाणपत्र देणे सोपे आहे। त्याच CA विरुद्ध प्रत्येक उपकरणासाठी वेगळे सामान्य नाव तयार करा, उदाहरणार्थ ./easyrsa build-client-full laptop-a nopass, आणि प्रत्येक उपकरणासाठी पुन्हा करा। कोणते सामान्य नाव कोणत्या व्यक्ती व मशीनचे आहे ते नोंदवा।
रद्द करणेही तितकेच सरळ आहे: ./easyrsa revoke laptop-a, ./easyrsa gen-crl ने CRL पुन्हा तयार करा, आणि सर्व्हर खरोखर crl-verify द्वारे ते वाचतो याची खात्री करा।
CA जे करू शकत नाही ते म्हणजे नंतर खाजगी की कुठे राहते याची पडताळणी करणे। तुम्ही CA होस्टवर की तयार करून उपकरणावर प्रत केली, तर देण्याच्या वेळी दुसरी प्रत तयार केली। निर्यात-अयोग्य की उपकरणावरच तयार करावी लागते, किंवा ती सोडणार नाही अशा हार्डवेअरमध्ये आयात करावी लागते।
प्रत केलेल्या प्रोफाइलवर टिकणारे नियंत्रण
प्रोफाइलची प्रत होऊ शकते असे गृहीत धरा आणि त्यानुसार रचना करा। खाते दुसऱ्या घटकाशी जोडा जेणेकरून फक्त प्रमाणपत्र पुरेसे होणार नाही। प्रत्येक उपकरणाला त्याचे स्वतःचे धोरण द्या जेणेकरून एका ओळखीची व्याप्ती मर्यादित राहील। आणि तेच सामान्य नाव एकाच वेळी दोन पत्त्यांवरून जोडत आहे का ते पहा, कारण कनेक्शन लॉगमध्ये सामायिक प्रोफाइल असेच दिसते।
वेगवान आणि नोंदवलेले रद्द करणे हेच नियंत्रण आहे जे प्रत झाल्यानंतरही काम करते। बाकी सर्व प्रतिबंध आहे।
सर्व्हर खरोखर ज्यावर अवलंबून राहू शकतो तो दावा
वेगळेपण CA कडून येते। उपकरणाशी बांधणी की साठवणीतून येते। फक्त जे हार्डवेअर स्वतःची की निर्यात करू शकत नाही तेच प्रत्येक उपकरणासाठीच्या एका प्रमाणपत्राचे, सर्वांनी मान्य केलेल्या धोरणाऐवजी, सर्व्हर लागू करतो असा दावा करते।