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

ક્લાયન્ટ જે માંગે છે તે ઓળખ છે

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

ItemWhat it can doWhat it cannot do
CA or server certificateValidate the gateway's chainAuthenticate this client
Client certificate without keyNothing for authenticationProve possession of anything
Identity (cert plus key)Answer the authentication challengeGuarantee the gateway accepts it

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

પસંદ કરનાર ખાલી રહેવાના ત્રણ કારણો

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

security find-identity -v -p ssl-client

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

ખાનગી કી ક્યાં રહે છે, અને કોણ તેનો ઉપયોગ કરી શકે છે

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

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

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

પ્રોફાઇલ ઓળખપત્ર તરફ કેવી રીતે નિર્દેશ કરે છે

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

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

પસંદગી અને સ્વીકૃતિ અલગ માઇલસ્ટોન છે

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

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

સંબંધિત લેખો