તમારું 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 પ્રમાણપત્રોવાળું બંડલ મોકલો; એકલું લીફ રૂટ સામે ચકાસાશે નહીં.

વચ્ચેના 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 હોસ્ટ પર કૉપી કરવાને બદલે નીતિ સીમા પાછળ રાખો: એક નાની સેવા જે વિનંતીની પ્રમાણિકતા ચકાસે, સામાન્ય નામને મંજૂર યાદી સામે તપાસે અને ફક્ત પ્રમાણપત્ર પાછું આપે. દરેક સીરિયલ નંબર નોંધો; લોગ એ પ્રમાણપત્ર અને તેને માંગનાર વ્યક્તિ વચ્ચેની એકમાત્ર કડી છે.

રૂટને જગાડ્યા વિના રદ કરવાનું પ્રકાશિત કરો

ક્લાયન્ટ પ્રમાણપત્રો વચ્ચેનું CA રદ કરે છે, ક્યારેય રૂટ નહીં. રૂટ યાદી ફક્ત ત્યારે મહત્ત્વની છે જ્યારે કોઈ વચ્ચેનું CA બળી જાય. સર્વરને 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માં ભવિષ્યનું આગલું અપડેટ છે, અને સાંકળના દરેક સમાપ્તિ માટે કોઈકની પાસે કૅલેન્ડર એન્ટ્રી છે. જો એક પણ ખૂટે, તો ઑફલાઇન દેખાતું સેટઅપ ફક્ત અનડોક્યુમેન્ટેડ છે.