Android પર VPN સર્ટિફિકેટ આયાત કરવાની અને કી ચકાસવાની રીત

Android પર VPN ક્લાયન્ટ સર્ટિફિકેટ આયાત કરવામાં થોડી મિનિટો લાગે છે। તે યોગ્ય જગ્યાએ પહોંચ્યું છે તે ચકાસવામાં વધુ સમય લાગે છે, અને ઇન્સ્ટોલ સંવાદ સફળતા કહે પછી મોટાભાગના લોકો ઠીક આ ભાગ છોડી દે છે। સફળતાનો સંદેશ ફક્ત એટલું જ કહે છે કે ફાઇલ પાર્સ થઈ ગઈ છે। ખાનગી કી કયા પ્રદાતા પાસે છે અથવા Downloads ફોલ્ડરમાં હજી કોઈ નકલ પડી છે કે નહીં, તે વિશે તે કંઈ કહેતું નથી।

પગલું 1: ફાઇલ તમારી મશીન છોડે તે પહેલાં P12 વાંચો

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

PKCS#12 બંડલ સામાન્ય રીતે ક્લાયન્ટ સર્ટિફિકેટ, તેની ખાનગી કી અને ઇશ્યુઅર ચેઇન ધરાવે છે। openssl pkcs12 -in client.p12 -info -noout કી સામગ્રી બહાર કાઢ્યા વિના MAC અને એન્ક્રિપ્શન અલ્ગોરિધમ છાપે છે, જેથી તમે જોઈ શકો કે બંડલ પાસવર્ડથી સુરક્ષિત છે કે નહીં અને કયા સાઇફરથી। તેની પછી keytool -list -v -keystore client.p12 -storetype PKCS12 ચલાવો જેથી એલિયાસ, SHA-256 ફિંગરપ્રિન્ટ અને ફોન સાથે સરખાવવાની માન્યતા અવધિ મળે।

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

પગલું 2: VPN એપ ખરેખર જે સ્લોટ વાંચે છે તેમાં તેને ઇન્સ્ટોલ કરો

સ્ટોક Android 11 થી 14 પર માર્ગ સેટિંગ્સ, સુરક્ષા, એન્ક્રિપ્શન અને ઓળખપત્રો, સર્ટિફિકેટ ઇન્સ્ટોલ કરો, પછી VPN અને એપ વપરાશકર્તા સર્ટિફિકેટ થઈને જાય છે। શબ્દરચના અને નેસ્ટિંગ રિલીઝ અને ઉત્પાદકોની સ્કિન વચ્ચે બદલાય છે, તેથી યાદ રાખેલા મેનુ સ્થાનને બદલે ઓળખપત્ર પ્રકારના લેબલને અનુસરો। કાર્ય પ્રોફાઇલમાં કાર્ય બાજુની અંદરથી ઇન્સ્ટોલ કરો, કારણ કે ઓળખપત્રો પ્રોફાઇલ સીમા ઓળંગતા નથી।

ક્લાયન્ટ ઓળખને CA સર્ટિફિકેટ સ્લોટમાં ન મૂકો। તે સ્લોટ વપરાશકર્તાના વિશ્વાસ સ્ટોરને પોષે છે, અને Android 7 થી એપ્સ વપરાશકર્તાએ ઉમેરેલા CAને અવગણે છે સિવાય કે તેમની નેટવર્ક સુરક્ષા રૂપરેખા પરવાનગી આપે, તેથી ત્યાં રાખેલું ક્લાયન્ટ સર્ટિફિકેટ VPN કી પિકરમાં ક્યારેય દેખાતું નથી।

કેટલાક VPN ક્લાયન્ટ સિસ્ટમ સ્ટોરને ક્યારેય સ્પર્શતા નથી અને તેના બદલે P12ને પોતાની એપ ડિરેક્ટરીમાં આયાત કરે છે। તે કાયદેસર ડિઝાઇન છે, પરંતુ તે દરેક પછીના પગલાને બદલે છે: કી હવે એપ સેન્ડબોક્સ હેઠળ રહે છે અને એટલી જ મજબૂત છે જેટલી એ એપ પોતાનું સંગ્રહ સંભાળે છે। KeyChain રમતમાં છે એમ ધારવા પહેલાં ક્લાયન્ટનું દસ્તાવેજીકરણ તપાસો।

પગલું 3: કયો પ્રદાતા કી ધરાવે છે તે સાબિત કરો

આયાત પાર્સિંગની પુષ્ટિ કરે છે, હાર્ડવેર આધારની નહીં। Android 12 અને પછીના પર, KeyInfo.getSecurityLevel() જણાવે છે કે કી ટ્રસ્ટેડ એક્ઝિક્યુશન એન્વાયર્નમેન્ટમાં, StrongBoxમાં કે સોફ્ટવેરમાં છે, અને તે જૂની isInsideSecureHardware() કૉલનું સ્થાન લે છે। જો VPN ક્લાયન્ટ તે મૂલ્ય બતાવતું નથી, તો પગલું 1નું ફિંગરપ્રિન્ટ તમારો વિકલ્પ છે। આયાત દરમિયાન ફરીથી એન્કોડ કરેલું સર્ટિફિકેટ બાઇટ દીઠ બાઇટ મેળ ખાશે નહીં, પણ જાહેર કી અને સબ્જેક્ટ હજી મેળ ખાશે।

નિકાસ ન કરી શકાય તે નકામું હોવા જેવું નથી। જે કી ઉપકરણ છોડી શકતી નથી તેનો ઉપયોગ વપરાશકર્તા જે એપને તે એલિયાસ પસંદ કરવાની અધિકૃતિ આપે છે તે હજી કરી શકે છે, અને તેથી જ એલિયાસની વિનંતી ઔપચારિકતા નહીં પણ સાચું નિયંત્રણ છે। Android Keystore દસ્તાવેજીકરણ જો તમે એ ડિઝાઇન નિર્ણય લેતા હો તો એક વાર વાંચવા લાયક છે।

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

પગલું 4: સ્ક્રીન લૉકની આવશ્યકતા કોની છે તે શોધો

અહીં ત્રણ રહસ્યો ભળી જાય છે: ઉપકરણ અનલૉક PIN, ખાનગી કીનો પાસફ્રેઝ અને VPN એકાઉન્ટનો પાસવર્ડ। એક માટેની વિનંતી ક્યારેય બીજાને ફરી સેટ કરવાની વિનંતી નથી, અને ખોટાને ફરી સેટ કરવો એ જ રીત છે જેનાથી લોકો સારી રીતે ચાલતી પ્રોફાઇલની બહાર પોતાને લૉક કરી લે છે।

જ્યારે ઉપકરણ વ્યવસ્થાપક અથવા સંચાલિત પ્રોફાઇલ નીતિ લૉક માંગે છે, ત્યારે આવશ્યકતા તે નીતિની હોય છે, સર્ટિફિકેટની નહીં। adb shell dumpsys device_policy સક્રિય વ્યવસ્થાપકો અને તેઓ જે પાસવર્ડ ગુણવત્તા લાગુ કરે છે તેની યાદી આપે છે, જે જોવાની સૌથી ઝડપી રીત છે કે તમારા PIN નિયમો બદલવાનું કારણ MDM એજન્ટ છે કે નહીં। સર્ટિફિકેટ દૂર કરવાથી નીતિ નરમ નહીં પડે, અને નીતિ દૂર કરવી એ સેટિંગ્સનું ઝીણું સમાયોજન નહીં પણ વહીવટી નિર્ણય છે।

ઉપયોગિતાનો સમાધાન પણ ધારો। જો કીને વપરાશકર્તા અધિકૃતિની જરૂર હોય, તો પ્રથમ અનલૉક પહેલાં ટનલ ઉપર આવી શકતી નથી, તેથી નિર્ધારિત સિંક અને દૂરસ્થ જાગૃતિ ડિઝાઇન મુજબ નિષ્ફળ જાય છે। તે નિર્ણય જમાવટ પહેલાં લો, પછી નહીં।

locksettings.db ફેરવવાની અથવા જૂની ભૂલી ગયેલી પેટર્નનો ઉપાય ફરી ચલાવવાની શોર્ટકટ ટાળો। તે રૂટિન ચોક્કસ બિલ્ડ માટે લખાયા હતા, તે ઓળખપત્ર સ્ટોરને એવી સ્થિતિમાં છોડી શકે છે જેની ફ્રેમવર્ક હવે અપેક્ષા રાખતું નથી, અને તે લૉક માંગનારી નીતિને ક્યારેય બદલતા નથી।

પગલું 5: ઓળખ નિવૃત્ત કરો અને ઇનકાર ચકાસો

નિવૃત્તિના ત્રણ ભાગ છે અને ફક્ત પહેલો સ્થાનિક છે। VPN પ્રોફાઇલ દૂર કરો, સેટિંગ્સ, સુરક્ષા, એન્ક્રિપ્શન અને ઓળખપત્રો, વપરાશકર્તા ઓળખપત્રો હેઠળ વપરાશકર્તા સર્ટિફિકેટ કાઢી નાખો, પછી ઇશ્યુઅરને સર્ટિફિકેટનો સીરિયલ નંબર રદ કરવા કહો। ફક્ત સ્થાનિક કાઢી નાખવું એવું ઓળખપત્ર છોડે છે જે કોઈએ P12 રાખ્યું હોય તો સર્વર હજી સ્વીકારે છે।

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

જો તમે નિષ્ફળ આયાત પાછી વાળી રહ્યા છો, તો મૂળ એન્ક્રિપ્ટેડ બંડલમાંથી ફરી આયાત કરો અને ડિસ્ક પર છોડેલી ડિક્રિપ્ટ કરેલી કી ફાઇલ ફરી વાપરવાને બદલે ફિંગરપ્રિન્ટ ફરી ચકાસો।