अपने VPN रूट CA को ऑफ़लाइन रखें और फिर भी प्रमाणपत्र जारी करें

आपका VPN रात 3 बजे कनेक्शनों का उत्तर देता है, जबकि उसके प्रमाणपत्र हस्ताक्षरित करने वाली मशीन दराज़ में बंद पड़ी रहती है। सर्वर प्रमाणपत्र का सत्यापन करने वाला क्लाइंट कभी आपके CA से संपर्क नहीं करता, इसलिए किसी भी कनेक्शन के लिए CA का पहुँच योग्य होना आवश्यक नहीं है। जिस भाग के लिए योजना चाहिए वह है वह दिन जब प्रमाणपत्र जारी, नवीनीकृत या निरस्त करना हो जबकि रूट कुंजी ताले में रहती है।

कनेक्शन वास्तव में क्या सत्यापित करता है

जब OpenVPN क्लाइंट जुड़ता है, तो वह सर्वर के लीफ़ प्रमाणपत्र से ऊपर उस CA प्रमाणपत्र तक हस्ताक्षर शृंखला पर चलता है जिस पर उसे पहले से भरोसा है, वैधता अवधि जाँचता है और यदि प्रोफ़ाइल कहे तो निरसन सूची देखता है। वह कभी आपके रूट CA को नहीं खोजता। सर्वर क्लाइंट प्रमाणपत्रों के लिए प्रतिबिंब कार्य करता है। जुड़ने के समय केवल लीफ़, मध्यवर्ती और पहले वितरित किया गया भरोसा बंडल मौजूद होते हैं।

वास्तव में विफल होता है तीन में से एक: जारी करते समय हस्ताक्षर कुंजी उपलब्ध नहीं है, निरसन सूची पुरानी हो गई है, या क्लाइंट का भरोसा बंडल सर्वर द्वारा प्रस्तुत शृंखला से पुराना है। पहला प्रक्रिया की समस्या है; अन्य दो वितरण की समस्याएँ हैं। इनमें से कोई भी रूट कुंजी के ऑनलाइन होने की माँग नहीं करता, और टनल प्रमाणीकरण के लिए निजी प्रमाणपत्र माँगने वाली प्रबंधित VPN सेवा केवल हस्ताक्षर अधिकार प्रदाता को स्थानांतरित करती है। Azure पॉइंट-टू-साइट उल्टा काम करता है: आप रूट प्रमाणपत्र अपलोड करते हैं और उसके नीचे हस्ताक्षरित प्रमाणपत्र भरोसेमंद माने जाते हैं, इसलिए पूछें कि कौन हस्ताक्षर करता है, कौन सत्यापित करता है और प्रमाणपत्र समय से पहले कैसे वापस लिया जाता है।

रूट को ऐसे होस्ट पर बनाएँ जिसे कभी पता नहीं मिलता

ऑफ़लाइन रूट का उपयोग कभी-कभार होता है: मध्यवर्ती CA प्रमाणपत्र पर हस्ताक्षर करने के लिए, और बाद में उसे नवीनीकृत या निरस्त करने के लिए। बाकी सब कुछ एक स्तर नीचे होता है। रूट का काम ऐसी मशीन पर करें जिसे नेटवर्क से दूर रखा गया हो, यदि संभव हो तो जीवित सिस्टम से, और लिख लें कि कमरे में कौन था। कमांड OpenSSL 1.1.1 या नया मानते हैं, क्योंकि पुराने बिल्ड में -addext नहीं है।

openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out root.key
openssl req -x509 -new -key root.key -sha256 -days 7300 \
  -subj "/CN=Example VPN Root CA" -out root.crt \
  -addext "basicConstraints=critical,CA:TRUE" \
  -addext "keyUsage=critical,keyCertSign,cRLSign"

हस्ताक्षर होस्ट पर मध्यवर्ती बनाएँ और केवल उसका अनुरोध ऑफ़लाइन मशीन तक ले जाएँ। रूट उस अनुरोध पर शून्य पथ लंबाई के साथ हस्ताक्षर करता है, इसलिए मध्यवर्ती CA अंतिम बिंदु प्रमाणपत्रों पर हस्ताक्षर कर सकता है परंतु अपने नीचे दूसरा CA नहीं बना सकता। यही एक एक्सटेंशन समझौता किए गए हस्ताक्षर होस्ट को रूट के बराबर अधिकार बनाने से रोकता है। ECDSA का उपयोग केवल तब करें जब हर क्लाइंट OpenVPN 2.4 या नया चलाता हो; अन्यथा RSA कुंजियाँ बनाएँ और प्रवाह समान रखें।

openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out intermediate.key
openssl req -new -key intermediate.key -subj "/CN=Example VPN Intermediate CA" -out intermediate.csr
openssl x509 -req -in intermediate.csr -CA root.crt -CAkey root.key \
  -CAcreateserial -days 3650 -sha256 -extfile intermediate.ext -out intermediate.crt

intermediate.ext में basicConstraints=critical,CA:TRUE,pathlen:0, keyUsage=critical,keyCertSign,cRLSign और authorityKeyIdentifier=keyid:always हैं। हस्ताक्षर होस्ट के फिर से जुड़ने से पहले रूट कुंजी उसकी तिजोरी में लौटा दें। यदि रूट को मध्यवर्ती निरस्त करने की क्षमता चाहिए, तो उसे openssl x509 -req के बजाय रूट-स्तरीय index.txt के विरुद्ध openssl ca -config root.cnf -extensions intermediate_ca से हस्ताक्षरित करें, जिससे क्रमांक दर्ज हो; फिर परिणामी रूट सूची क्लाइंट प्रोफ़ाइल के अंदर भेजें, जहाँ फ़ाइल-आधारित crl-verify उसे प्रारंभ पर पढ़ता है। क्लाइंट को दोनों CA प्रमाणपत्रों वाला बंडल भेजें; अकेला लीफ़ रूट के विरुद्ध सत्यापित नहीं होगा।

मध्यवर्ती से लीफ़ जारी करें, डेटाबेस के साथ

openssl x509 -req से हस्ताक्षर करना तब तक काम करता है जब तक निरसन की आवश्यकता न हो, क्योंकि कुछ भी क्रमांक दर्ज नहीं करता। पहले प्रमाणपत्र से ही openssl ca का उपयोग करें ताकि क्रमांक, समाप्ति और निरसन स्थिति एक ही डेटाबेस में रहें। डेटाबेस फ़ाइलें एक बार बनाएँ, फिर कॉन्फ़िगरेशन को उनकी ओर इंगित करें:

mkdir -p /etc/vpn-ca/intermediate/newcerts
touch /etc/vpn-ca/intermediate/index.txt
echo 1000 > /etc/vpn-ca/intermediate/serial
echo 1000 > /etc/vpn-ca/intermediate/crlnumber

[ ca ]
default_ca = CA_default
[ CA_default ]
dir = /etc/vpn-ca/intermediate
database = $dir/index.txt
new_certs_dir = $dir/newcerts
serial = $dir/serial
crlnumber = $dir/crlnumber
certificate = $dir/intermediate.crt
private_key = $dir/intermediate.key
default_md = sha256
default_days = 365
default_crl_days = 30
unique_subject = no
policy = policy_any
[ policy_any ]
commonName = supplied
[ server_cert ]
basicConstraints = CA:FALSE
keyUsage = critical, digitalSignature
extendedKeyUsage = serverAuth
subjectAltName = @server_names
[ client_cert ]
basicConstraints = CA:FALSE
keyUsage = critical, digitalSignature
extendedKeyUsage = clientAuth
[ server_names ]
DNS.1 = vpn.example.com

कुंजी उपयोग की पंक्ति ECDSA कुंजी मानती है; RSA के लिए keyEncipherment जोड़ें। हर क्लाइंट को उसका अपना सामान्य नाम दें, क्योंकि OpenVPN उस फ़ील्ड से कनेक्शन पहचानता है, और CN=vpn-client साझा करने वाले दो लैपटॉप लॉग में, client-config-dir नियमों में या किसी भी प्रति-उपयोगकर्ता पुश में अलग नहीं किए जा सकते, और आप वह एट्रिब्यूशन खो देते हैं जो निरसन निर्णय को रक्षात्मक बनाता है। लीफ़ इस तरह जारी और सत्यापित करें:

openssl req -new -key alice.key -subj "/CN=alice-laptop" -out alice.csr
openssl ca -config intermediate.cnf -extensions client_cert -in alice.csr -out alice.crt -batch
openssl verify -CAfile ca-bundle.crt -untrusted intermediate.crt alice.crt

हस्ताक्षर कुंजी को VPN होस्ट पर प्रतिलिपि करने के बजाय नीति सीमा के पीछे रखें: एक छोटी सेवा जो अनुरोध का प्रमाणीकरण करती है, सामान्य नाम को अनुमति सूची के विरुद्ध जाँचती है और केवल प्रमाणपत्र लौटाती है। हर क्रमांक दर्ज करें; लॉग ही प्रमाणपत्र और उसे माँगने वाले व्यक्ति के बीच एकमात्र कड़ी है।

रूट को जगाए बिना निरसन प्रकाशित करें

क्लाइंट प्रमाणपत्र मध्यवर्ती निरस्त करता है, कभी रूट नहीं। रूट सूची का महत्व केवल तब है जब कोई मध्यवर्ती जल गया हो। सर्वर को crl-verify से मध्यवर्ती सूची की ओर इंगित करें। फ़ाइल-आधारित CRL सेवा शुरू होने पर लोड होता है, इसलिए हर पुनर्जनन के बाद फिर से लोड करें; निर्देशिका रूप जुड़ने के समय स्थिति पढ़ता है और प्रति क्रमांक एक फ़ाइल खर्च करता है।

उसी डेटाबेस से दो कमांडों से निरस्त करें और पुनर्जनन करें:

openssl ca -config intermediate.cnf -revoke /etc/vpn-ca/intermediate/newcerts/1001.pem
openssl ca -config intermediate.cnf -gencrl -out /etc/openvpn/crl.pem

फिर घड़ी पर ध्यान दें। CRL अगले अद्यतन का फ़ील्ड रखता है, और वह तिथि बीत जाने पर सत्यापन करने वाला साथी सूची को अनदेखा करने के बजाय अस्वीकार करता है। default_crl_days = 30 के साथ मासिक पुनर्जनन गुंजाइश छोड़ता है; वार्षिक नहीं। छोटी लीफ़ आयु अधिक भरोसेमंद नियंत्रण है, क्योंकि निरसन केवल वहीं लागू होता है जहाँ सूची देखी जाती है।

शृंखला की जाँच करें, फिर समारोह लिख लें

डिज़ाइन पर भरोसा करने से पहले चार विफलताएँ पुन: उत्पन्न करें। openssl verify -CAfile ca-bundle.crt -untrusted intermediate.crt server.crt से शृंखला सत्यापित करें। समाप्त क्लाइंट प्रमाणपत्र के साथ जुड़ें और पुष्टि करें कि सर्वर उसे अस्वीकार करता है। परीक्षण क्लाइंट निरस्त करें, पुनः लोड करें और पुष्टि करें कि सूची प्रभावी होती है। होस्ट की घड़ी एक दिन आगे बढ़ाएँ, क्योंकि गलत घड़ी ऐसे प्रमाणपत्र जारी और अस्वीकार कर सकती है जो कहीं और वैध दिखते हैं।

ऑफ़लाइन रूट केवल तभी नियंत्रण है जब कागज़ात मौजूद हों: समारोह के लिए दो नामित लोग, हर हस्ताक्षरित क्रमांक का रिकॉर्ड, मशीन से अलग रखा एन्क्रिप्टेड बैकअप, और अलग किए गए होस्ट पर पुनर्स्थापन परीक्षण। उसी समारोह में एक अतिरिक्त मध्यवर्ती पर हस्ताक्षर करें ताकि मृत हस्ताक्षर होस्ट आपको आधी रात को रूट खोलने के लिए विवश न करे।

इसे पूर्ण कहने से पहले पाँच बातों की पुष्टि करें: रूट कुंजी नेटवर्क वाले होस्ट पर नहीं है, मध्यवर्ती कुंजी केवल हस्ताक्षर होस्ट पर रहती है, क्लाइंट बंडल दोनों CA प्रमाणपत्र रखता है, CRL में भविष्य का अगला अद्यतन है, और शृंखला की हर समाप्ति के लिए किसी के पास कैलेंडर प्रविष्टि है। यदि एक भी गायब हो, तो ऑफ़लाइन दिखने वाला सेटअप केवल अप्रलेखित है।