VPN ક્લાયન્ટ કી કેવી રીતે બનાવવી અને સહી માટે CSR કેવી રીતે સબમિટ કરવો

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

પગલું 1: કી જ્યાં રહેશે ત્યાં જ બનાવો

જે મશીન કી રાખશે ત્યાં જ બનાવો અને ત્યાં જ રાખો. સોફ્ટવેર કી કડક પરવાનગીઓવાળી ફાઇલમાં જાય છે; હાર્ડવેર-આધારિત કી અથવા સંચાલિત સ્ટોરમાં રહેલી કી ક્યારેય ફાઇલ બનતી નથી, અને તેનો નોંધણી માર્ગ સામાન્ય રીતે OpenSSL આદેશ નહીં પણ અલગ સાધન હોય છે. કોઈપણ રીતે, ખાનગી અડધું કોઈએ જોવાની જરૂર નથી.

સોફ્ટવેર પ્રવાહ આવો દેખાય છે, કી અને વિનંતી એક જ સત્રમાં બનાવવામાં આવે છે:

umask 077
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out client.key
openssl req -new -key client.key -out client.csr -subj "/CN=alice-vpn/O=Example"

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

પગલું 2: ઓળખ વિનંતીમાં મૂકો, ઈમેલમાં નહીં

વિનંતી બનતા પહેલાં નક્કી કરો કે VPN ખરેખર શું પ્રમાણિત કરે છે, કારણ કે તે જવાબ CSR ની અંદર આવે છે. OpenVPN પરંપરાગત રીતે ક્લાયન્ટ ઓળખને પ્રમાણપત્રના સામાન્ય નામ સાથે જોડે છે, અને strongSwan જેવા સાધનો ઓળખ શબ્દમાળાને વિષય અથવા વિષયના વૈકલ્પિક નામ સાથે મેળવે છે. જે ઈમેલ કહે છે કે મારું નામ alice છે તે પુરાવો નથી, અને જે વિનંતીનો વિષય એ જ કહે છે તે ફક્ત થોડી સારી છે.

જ્યારે તમારો ચકાસનાર એક ચકાસે ત્યારે વિષયનું વૈકલ્પિક નામ ઉમેરો, કારણ કે આધુનિક મેળ ઘણી વાર જૂનું CN અવગણે છે:

openssl req -new -key client.key -out client.csr \
  -subj "/CN=alice-vpn/O=Example" \
  -addext "subjectAltName=DNS:alice-vpn"

CN ને ટૂંકું, સ્થિર અને લેપટોપ મોડેલને બદલે ખાતા સાથે જોડાયેલું રાખો. જે નામમાં વપરાશકર્તાના ઉપકરણનો સીરિયલ નંબર હોય તે પ્રથમ હાર્ડવેર બદલીની રાહ જોતી સપોર્ટ સમસ્યા છે.

પગલું 3: સહી કરતા પહેલાં વિનંતી ચકાસો

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

યાંત્રિક ભાગ એક આદેશ છે, અને તેણે વિષય સાથે ચકાસણીનું પરિણામ છાપવું જોઈએ:

openssl req -in client.csr -noout -verify -subject
openssl req -in client.csr -noout -pubkey | openssl pkey -pubin -noout -text

ધ્યાન આપો કે તે શું સાબિત કરે છે. ચકાસાયેલી વિનંતી ફક્ત એ બતાવે છે કે મોકલનાર પાસે સબમિટ કરવાના સમયે મેળ ખાતી ખાનગી કી હતી; તે સાબિત કરતું નથી કે મોકલનાર વિષયમાં નામ આપેલ વ્યક્તિ છે, અને તે માંગાયેલા જૂથ કે માર્ગ ઍક્સેસને અધિકૃત કરતું નથી. નોંધણી સમીક્ષા અલગ દરવાજો છે, અને જે વિનંતી એવા જૂથની માંગ કરે છે જેને કોઈએ મંજૂર કર્યું નથી તેને ચૂપચાપ સંપાદિત કરવાને બદલે નકારવી જોઈએ.

પગલું 4: અધિકૃત કરો, પછી સ્પષ્ટ એક્સ્ટેન્શન સાથે સહી કરો

સહી એ જગ્યા છે જ્યાં CA વિનંતીને શબ્દશઃ સ્વીકારવાને બદલે નીતિ નક્કી કરે છે. માન્યતા, કી વપરાશ અને ભૂમિકા એક્સ્ટેન્શન એક્સ્ટેન્શન ફાઇલમાં આવે છે, એવા ડિફોલ્ટમાં નહીં જે છ મહિના પછી તમને યાદ ન રહે. VPN પ્રમાણીકરણ માટેના ક્લાયન્ટ પ્રમાણપત્રને તેના હેતુ તરીકે ક્લાયન્ટ પ્રમાણીકરણની જરૂર છે.

cat > client.ext <<'EOF'
basicConstraints = CA:FALSE
keyUsage = digitalSignature
extendedKeyUsage = clientAuth
EOF
openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -days 365 -extfile client.ext -out client.crt

જો એક પહેલેથી વપરાશમાં હોય તો હાલની સીરિયલ ફાઇલ સાથે -CAserial વાપરો, અને CA કી ઑફલાઇન અથવા તમારી નીતિ જે સુરક્ષિત સ્ટોર કહે તેમાં રાખો. પ્રમાણપત્ર સીરિયલ નંબર દરેક જારીકર્તા માટે અનન્ય હોવા જોઈએ; સીરિયલ ફાઇલ શૂન્યથી ફરી બનાવવાથી અથડામણનું જોખમ રહે છે જે રદ કરવાને અસ્પષ્ટ બનાવે છે.

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

પગલું 5: તેને મેળ ખાતી કીની બાજુમાં સ્થાપિત કરો અને જોડી સાબિત કરો

ક્લાયન્ટ પ્રમાણપત્ર અને જારીકર્તાની સાંકળ મેળવે છે, ક્યારેય કી નહીં. કનેક્ટ કરતા પહેલાં ખાતરી કરો કે પ્રમાણપત્ર ડિસ્ક પર પહેલેથી રહેલી કી સાથે ખરેખર જોડાય છે, કારણ કે મેળ ન ખાતી જોડી ઘણી મોડી હેન્ડશેક નિષ્ફળતા ઉત્પન્ન કરે છે:

openssl x509 -in client.crt -noout -pubkey | openssl pkey -pubin -outform DER | openssl sha256
openssl pkey -in client.key -pubout -outform DER | openssl sha256

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