CA ફરી ન બનાવતાં VPN ક્લાયન્ટ ઉમેરવો

બીજા લેપટોપ માટે બીજું પ્રમાણપત્ર જોઈએ છે, પણ શોધ પરિણામોનું પહેલું ટ્યુટોરિયલ PKI ડિરેક્ટરી ભૂંસી નાખતા આદેશથી શરૂ થાય છે. એ આદેશ પ્રથમ સેટઅપનો છે, નોંધણીનો નહીં; તેને ચલાવવાથી CA, ઇશ્યુ ઇતિહાસ અને જૂના ઇશ્યુઅર પર ભરોસો કરતી દરેક ક્લાયન્ટ પ્રોફાઇલ જાય છે. નિર્ણય સાંકડો છે: ઇશ્યુઅર પાસે હજી વપરાય તેવી સ્થિતિ છે અને નવું ઉપકરણ તમારી નોંધણી નીતિમાં બંધ બેસે છે? ત્રણ શરતો નક્કી કરે છે, માત્ર એક જ ફરી બાંધકામને ન્યાય આપે છે.

ફરી બાંધકામ ખરેખર શું નષ્ટ કરે

PKI ફરી શરૂ કરવાથી ડિરેક્ટરી ખાલી માળખાથી બદલાય: નવી CA કી અને પ્રમાણપત્ર, ખાલી ઇશ્યુ ડેટાબેઝ, નવું ક્રમિક કાઉન્ટર. ક્લાયન્ટ પોતાની રીતે અનુસરતા નથી; તેમની પ્રોફાઇલ જૂની CA પિન કરે છે, તેથી દરેક ઉપકરણ ફરી નોંધણી કરાવવી પડે.

શાંત નુકસાન હિસાબનું છે. રદ કરવું એ જાણવા પર આધારિત છે કે કયા ક્રમિક નંબર કોને આપ્યા. ઇન્ડેક્સ ભૂંસો તો હજી સહી કરી શકાય, પણ કયા પ્રમાણપત્રો રદ કરવા હતા તે નિશ્ચિત કહી શકાય નહીં.

CA ની ખાનગી કી ચાલતા સર્વર પાસે કોપી કરવી એ બીજો ટાળવા જેવો શોર્ટકટ છે: ઓફલાઇન રહેવા જોઈતું સહી સત્તા અવિશ્વસનીય ટ્રાફિકવાળા હોસ્ટ પરની બીજી ફાઇલ બની જાય છે.

પહેલી શરત: ઇશ્યુઅરની સ્થિતિ હજી પહોંચમાં છે?

નિર્ણય પહેલાં સર્વર ખરેખર જે ડિરેક્ટરી પર ભરોસો કરે તે શોધો. સર્વર CA તરીકે આપતું પ્રમાણપત્ર તમારી PKI ડિરેક્ટરીના પ્રમાણપત્ર સાથે ફિંગરપ્રિન્ટથી સરખાવો, ફાઇલ નામથી નહીં:

openssl x509 -in ca.crt -noout -fingerprint -sha256
openssl x509 -in /etc/openvpn/ca.crt -noout -fingerprint -sha256

ફિંગરપ્રિન્ટ મળે તો નોંધણી ઉમેરાતી છે અને ફરી કંઈ ન બાંધો. ન મળે તો સર્વર ન ભરોસો કરતા CA સાથે સહી થશે: પ્રમાણપત્ર સ્વચ્છ રીતે બેસે પણ હેન્ડશેકમાં નિષ્ફળ જાય, અને એ ભૂલ કલાકો સુધી ક્લાયન્ટ બગ તરીકે ગણાય.

પછી ઇશ્યુ સ્થિતિ જુઓ: ઇન્ડેક્સ ફાઇલ, ક્રમિક કાઉન્ટર અને CRL નંબર ફાઇલ. ઇન્ડેક્સ ન હોય પણ કી હોય તો ઇશ્યુ કરી શકાય, પણ રદની નોંધની સમસ્યા વારસામાં આવે. તેને ફેરફાર રેકોર્ડમાં લખો.

બીજી શરત: નવી ખાનગી કી કોની પાસે?

આ નિર્ણય વપરાશકર્તા અનુભવે છે, તેથી સ્પષ્ટ કરો. ક્લાયન્ટે બનાવેલી કી વિનંતી તરીકે મોકલાય તો ખાનગી ભાગ ઉપકરણ પર જ રહે અને એડમિન તેને ક્યારેય અડે નહીં. સર્વરે બનાવેલી કી સરળ છે પણ એડમિનને દરેક કીનો સંભાળનાર બનાવે અને સર્વર ભંગની અસર વધારે.

હાલની CA સામે Easy-RSA 3 સાથે વિનંતી આયાત અને સહી બે આદેશ છે:

./easyrsa import-req /tmp/alice.req alice
./easyrsa sign-req client alice

પ્રમાણપત્રનો પ્રકાર જાણી જોઈને પસંદ કરો. ક્લાયન્ટને બદલે સર્વર પ્રમાણપત્ર તરીકે સહી કરેલી વિનંતી સારી દેખાતી પણ સામેવાળા દ્વારા નકારાતી ફાઇલ આપે છે. openssl ca સાથે એ જ પસંદગી એક્સ્ટેન્શનમાં હોય છે.

ત્રીજી શરત: સર્વરને પ્રમાણપત્રથી વધુ જોઈએ?

પ્રમાણપત્ર પ્રમાણીકરણવાળા સામાન્ય OpenVPN સર્વર માટે પ્રમાણપત્ર જ નોંધણી છે: સામાન્ય નામ ક્લાયન્ટ ઓળખ બને છે અને દરેક ડિરેક્ટરી, રૂટ કે સ્થિર સરનામું તે નામ પર ટકે છે. પ્રમાણપત્ર ઉમેરી કન્ફિગ ભૂલો તો ટનલ જોડાય પણ જરૂરી રૂટ આવે નહીં.

પ્લેટફોર્મ આ બદલે છે. OpenVPN Access Server પોતાનો વપરાશકર્તા ડેટાબેઝ રાખે છે, તેથી સહી કરેલું પ્રમાણપત્ર ખાતું નથી; ખાતું હોવું અને મંજૂર હોવું જોઈએ. એક ઉપકરણની નોંધણી સામાન્ય રીતે બે સિસ્ટમને અડે છે.

ઉમેરાતી પ્રક્રિયા અને ક્યારે ફરી બાંધવું

નુકસાન વિના એક ઉપકરણ ઉમેરવાનો ક્રમ: ફિંગરપ્રિન્ટથી ઇશ્યુઅર ખાતરી કરો, PKI ડિરેક્ટરીનો તાજો બેકઅપ લો, ક્લાયન્ટ ભૂમિકા માટે વિનંતી આયાત કરી સહી કરો, મંજૂર માર્ગે પ્રમાણપત્ર તેની ચેઇન સાથે આપો, અને જોડાણ પહેલાં ચકાસો:

openssl verify -CAfile ca.crt alice.crt
openssl x509 -in alice.crt -noout -subject -issuer -dates -purpose

હેતુ લાઇનમાં SSL client દેખાવું જોઈએ. ઇશ્યુ પછી CA બેકઅપ અપડેટ કરો, કારણ કે નવા ક્રમિક નંબર પહેલાંનો બેકઅપ નવું ઉપકરણ વગરની સ્થિતિ પાછી લાવે.

CA કી ભંગાયેલી, ઇશ્યુ સ્થિતિ કાયમ માટે ગુમ, અથવા જાણી જોઈને અલ્ગોરિધમ કે નીતિ બદલાય તો ફરી બાંધવું યોગ્ય છે. ત્રણેય યોજનાઓ છે, એક ઉપકરણની વિનંતીનાં પગલાં નહીં.