तुमचे 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 मध्ये भविष्यातील पुढील अद्यतन आहे, आणि साखळीतील प्रत्येक मुदतीसाठी कोणाकडे कॅलेंडर नोंद आहे। एकही गोष्ट नसल्यास, ऑफलाइन दिसणारे सेटअप फक्त अलेखित आहे।