आफ्नो 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 मा भविष्यको अर्को अद्यावधिक छ, र शृंखलाको प्रत्येक म्यादका लागि कसैसँग क्यालेन्डर प्रविष्टि छ। एउटा पनि छैन भने, अफलाइन देखिने सेटअप अभिलेख नगरिएको मात्र हो।