VPN પ્રમાણપત્રની નકલ કરવાથી કીની નકલ થતી નથી

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

બે ક્લિક, બે તદ્દન જુદા આર્ટિફેક્ટ.

ફાઇલ એક્સ્ટેન્શન નહીં, નિકાસ સંવાદ વાંચો

DER અથવા PEM પ્રમાણપત્ર નિકાસમાં જાહેર કી અને સહી કરેલા ઓળખ દાવા રહે છે, જે સર્વરને તમારા પર ભરોસો રાખવા માટે અને ક્લાયન્ટને સર્વર ચકાસવા માટે જરૂરી છે. PKCS#12 બંડલ એ કન્ટેનર છે જે પ્રમાણપત્ર, તેની શૃંખલા અને તેને અનુરૂપ ખાનગી કી રાખી શકે છે, પાસવર્ડથી સુરક્ષિત, જોકે તે કી વગર પણ બનાવી શકાય છે.

PEM ફક્ત ટેક્સ્ટ એન્કોડિંગ છે, સામગ્રી વિશેનું વચન નહીં. એક જ એક્સ્ટેન્શન એક જ પ્રમાણપત્ર અથવા ઘણા લેબલવાળા બ્લોક ધરાવતી ફાઇલ વર્ણવી શકે છે, અને નિકાસ વિકલ્પો નક્કી કરે છે કે કઈ.

તેથી ઉપયોગી પ્રશ્ન ક્યારેય એ નથી કે તમને કયું એક્સ્ટેન્શન મળ્યું, પણ એ છે કે ફાઇલમાં કયા બ્લોક છે. કી વગર નિકાસ કરેલું બંડલ પણ બંડલ જ રહે છે. ફોર્મેટની લોકપ્રિયતા નહીં, સામગ્રી તપાસો.

તમે ખરેખર શું મેળવ્યું તે તપાસો

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

grep -E 'BEGIN (CERTIFICATE|PRIVATE KEY|ENCRYPTED PRIVATE KEY)' bundle.pem
openssl x509 -in client.crt -noout -subject -issuer -dates
openssl pkey -in client.key -noout -text | head -5
openssl pkcs12 -info -in client.p12 -noout

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

ખાનગી કી ધરાવતી ફાઇલ કદી પણ સપોર્ટ થ્રેડ, ઇશ્યુ ટ્રેકર કે ચેટમાં પેસ્ટ કરશો નહીં, જ્યારે તે તમે પહેલેથી શેર કરેલા પ્રમાણપત્ર જેવી લાગે ત્યારે પણ. કી પેનલનાં સ્ક્રીનશોટ પણ એટલી જ સાવધાની માગે છે.

કી એવી જગ્યાએ હોઈ શકે જ્યાંથી તમે નકલ કરી શકતા નથી

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

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

નકલ કરવાને બદલે નવી ઓળખ નોંધો

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

આયાત કરેલી ઓળખ સાથે પ્રમાણીકરણ કરીને ચકાસો, આયાત સફળ થઈ તે જોઈને નહીં. જે ક્લાયન્ટ પોતાના સ્ટોરમાં જાહેર પ્રમાણપત્ર સ્વીકારે છે તેણે કી વિશે કંઈ સાબિત કર્યું નથી.

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