Mac VPN സർട്ടിഫിക്കറ്റ്: ഐഡന്റിറ്റി തിരഞ്ഞെടുക്കൽ എന്തുകൊണ്ട് ശൂന്യമായി തുടരുന്നു
ക്ലയന്റിന് അതിന്റെ സ്വകാര്യ കീയോടുകൂടിയ സർട്ടിഫിക്കറ്റ്, അത് വായിക്കുന്ന സ്റ്റോറിൽ ആവശ്യമാണ്. ആദ്യം ഐഡന്റിറ്റി പരിശോധിക്കുക, പിന്നീട് ഗേറ്റ്വേ അത് സ്വീകരിക്കുന്നുണ്ടോ എന്ന് നോക്കുക.
നിങ്ങൾ സർട്ടിഫിക്കറ്റ് ഇൻസ്റ്റാൾ ചെയ്തു, അത് Keychain Access-ൽ സൗഹൃദപരമായ പേരോടെ കാണാം, എന്നിട്ടും VPN ക്ലയന്റിന്റെ ഐഡന്റിറ്റി തിരഞ്ഞെടുക്കൽ ശൂന്യമാണ്. ക്ലയന്റ് സർട്ടിഫിക്കറ്റ് തിരയുന്നില്ല. അത് ഐഡന്റിറ്റി തിരയുന്നു: ഉടമസ്ഥത തെളിയിക്കാൻ കഴിയുന്ന സ്വകാര്യ കീയുമായി ചേർന്ന സർട്ടിഫിക്കറ്റ്, ക്ലയന്റിന് വായിക്കാൻ അനുവാദമുള്ള ഇടത്ത് സൂക്ഷിച്ചിരിക്കുന്നു.
ക്ലയന്റ് ആവശ്യപ്പെടുന്നത് ഐഡന്റിറ്റിയാണ്
Apple-ന്റെ സുരക്ഷാ ചട്ടക്കൂട് സർട്ടിഫിക്കറ്റിനെയും ഐഡന്റിറ്റിയെയും വ്യത്യസ്ത വസ്തുക്കളായി കണക്കാക്കുന്നു. സർട്ടിഫിക്കറ്റ് പൊതു ഡാറ്റയാണ്. ഐഡന്റിറ്റി ആ സർട്ടിഫിക്കറ്റും അതിന്റെ സ്വകാര്യ കീയുമാണ്, വെല്ലുവിളി പൂർത്തിയാക്കാൻ ഐഡന്റിറ്റിക്ക് മാത്രമേ കഴിയൂ. വിശ്വസ്ത CA സർട്ടിഫിക്കറ്റ് ക്ലയന്റിന് ഇഷ്യൂവറെ വിലയിരുത്താൻ അനുവദിക്കുന്നു; അത് യന്ത്രത്തെ നൽകിയ ക്ലയന്റ് ക്രെഡൻഷ്യലിന്റെ ഉടമയാക്കുന്നില്ല.
| Item | What it can do | What it cannot do |
|---|---|---|
| CA or server certificate | Validate the gateway's chain | Authenticate this client |
| Client certificate without key | Nothing for authentication | Prove possession of anything |
| Identity (cert plus key) | Answer the authentication challenge | Guarantee the gateway accepts it |
അതുകൊണ്ട് .cer ഫയൽ ഇമ്പോർട്ട് ചെയ്താൽ ഉപയോഗയോഗ്യമായ ക്ലയന്റ് ഐഡന്റിറ്റി ഒരിക്കലും ഉണ്ടാകില്ല. ഫയലിൽ പൊതു വസ്തുവകകൾ മാത്രമാണ്, എത്ര പേരുമാറ്റിയാലും വിശ്വാസം നൽകിയാലും അത് കീ ജോടിയാകില്ല.
തിരഞ്ഞെടുക്കൽ ശൂന്യമായി തുടരാനുള്ള മൂന്ന് കാരണങ്ങൾ
ആദ്യത്തേത് സ്വകാര്യ കീയുടെ അഭാവമാണ്, അതായത് രജിസ്ട്രേഷൻ അല്ലെങ്കിൽ ഇമ്പോർട്ട് പ്രക്രിയ ഒന്നും നൽകിയിട്ടില്ല. രണ്ടാമത്തേത് ക്ലയന്റ് പരിശോധിക്കാത്ത സ്റ്റോർ ആണ്: ഉപയോക്തൃ പരിധിയിലുള്ള പ്രൊഫൈൽ ഉപയോക്താവിന്റെ കീചെയിനിൽ നോക്കുന്നു, സിസ്റ്റം സ്റ്റോറിൽ വച്ച ഇനം അതിന് അദൃശ്യമായേക്കാം. മൂന്നാമത്തേത് ഉദ്ദേശ്യത്തിലോ നയത്തിലോ ഉള്ള പൊരുത്തക്കേടാണ്, സർട്ടിഫിക്കറ്റ് ഉണ്ടെങ്കിലും വിന്യാസത്തിന്റെ നിയമങ്ങൾ പ്രകാരം ക്ലയന്റ് പ്രാമാണീകരണത്തിന് സാധുവല്ല.
security find-identity -v -p ssl-clientഇത് സിസ്റ്റം ക്ലയന്റ് പ്രാമാണീകരണത്തിന് സാധുവായി കണക്കാക്കുന്ന ഐഡന്റിറ്റികൾ പട്ടികപ്പെടുത്തുന്നു. എണ്ണം പൂജ്യമാണെങ്കിൽ, പ്രശ്നം VPN ക്ലയന്റിന് മുകളിലാണ്, പ്രൊഫൈൽ എഡിറ്റ് ചെയ്താൽ അത് ശരിയാകില്ല. ഐഡന്റിറ്റി ഇവിടെ കാണുകയും ക്ലയന്റിൽ കാണാതിരിക്കുകയും ചെയ്താൽ, വ്യത്യാസം ക്ലയന്റിന്റെ സ്റ്റോറിലോ പരിധിയിലോ ആണ്.
സ്വകാര്യ കീ എവിടെയാണ്, ആർക്ക് അത് ഉപയോഗിക്കാം
Keychain Access വഴി ഐഡന്റിറ്റി ഇമ്പോർട്ട് ചെയ്യുമ്പോൾ, ഇമ്പോർട്ട് ഡയലോഗ് ഒരു ലക്ഷ്യ കീചെയിൻ നൽകുന്നു. ഏത് ലക്ഷ്യമാണ് ശരി എന്നത് ക്ലയന്റിനെയും പ്രൊഫൈൽ ഉപയോക്തൃ പരിധിയാണോ ഉപകരണ പരിധിയാണോ എന്നതിനെയും ആശ്രയിച്ചിരിക്കുന്നു. സിസ്റ്റം കീചെയിൻ ശുപാർശ ചെയ്യുന്ന പഴയ ഉത്തരം സാർവത്രിക നിയമമല്ല, സ്റ്റോറുകൾക്കിടയിൽ ഇനങ്ങൾ പകർത്തുന്നത് അറ്റകുറ്റപ്പണിയുമല്ല.
System Roots ഒരു വിശ്വാസ ശേഖരമാണ്. അവിടെ സർട്ടിഫിക്കറ്റ് വയ്ക്കുന്നത് സിസ്റ്റം ഏത് ഇഷ്യൂവർമാരെ വിശ്വസിക്കുന്നു എന്നത് മാറ്റുന്നു; അത് സ്വകാര്യ കീ ഉണ്ടാക്കുന്നില്ല, ഐഡന്റിറ്റി സ്റ്റോറുമല്ല. തിരഞ്ഞെടുക്കൽ നിറയ്ക്കാൻ ബന്ധമില്ലാത്ത സർട്ടിഫിക്കറ്റുകൾ നീക്കുന്നത് യന്ത്രത്തെ സ്ഥിരമായി വിപുലീകരിച്ച വിശ്വാസ ഗണത്തോടെ വിടുന്ന തരം അറ്റകുറ്റപ്പണിയാണ്.
സ്വകാര്യ കീയിലേക്കുള്ള പ്രവേശനം വേറിട്ട നിയന്ത്രണമാണ്. ഓരോ ആപ്ലിക്കേഷനും കീ ഉപയോഗിക്കാൻ അനുമതി നൽകുന്നത് ഒരു ക്ലയന്റിന്റെ തിരഞ്ഞെടുപ്പ് പ്രശ്നം പരിഹരിക്കുകയും അതേ കഴിവ് യന്ത്രത്തിലെ മറ്റെല്ലാത്തിനും നൽകുകയും ചെയ്യുന്നു. ആവശ്യമുള്ള ക്ലയന്റിന് അത് നൽകുക, കീ ഹാർഡ്വെയർ പിന്തുണയുള്ളതാണോ എക്സ്പോർട്ട് ചെയ്യാനാകാത്തതെന്ന് അടയാളപ്പെടുത്തിയതാണോ എന്ന് പരിശോധിക്കുക; അങ്ങനെയെങ്കിൽ, എക്സ്പോർട്ട് ചെയ്ത പകർപ്പിന് പകരം പിന്തുണയുള്ള ദാതാവ് ഉപയോഗിക്കണം.
പ്രൊഫൈൽ ക്രെഡൻഷ്യലിലേക്ക് എങ്ങനെ വിരൽ ചൂണ്ടുന്നു
നിയന്ത്രിത നേറ്റീവ് IKEv2 കോൺഫിഗറേഷനിൽ, പ്രൊഫൈൽ PayloadCertificateUUID വഴി അതിന്റെ ക്രെഡൻഷ്യൽ പേലോഡിനെ പരാമർശിക്കുന്നു. പരാമർശിച്ച ഐഡന്റിറ്റിയും അത് എങ്ങനെ നൽകി എന്നതുമാണ് പ്രധാനം; പ്രൊഫൈലിലെ പ്രദർശന നാമം തിരുത്തുന്നത് തെറ്റായ പേലോഡിലേക്കോ ഒരിക്കലും കീ നൽകാത്ത പേലോഡിലേക്കോ ചൂണ്ടുന്ന പരാമർശം ശരിയാക്കുന്നില്ല.
മൂന്നാം കക്ഷി ദാതാവ് സ്വന്തം സ്റ്റോർ അല്ലെങ്കിൽ സിസ്റ്റം പ്രോംപ്റ്റ് പോലുള്ള തികച്ചും വ്യത്യസ്തമായ തിരഞ്ഞെടുപ്പ് സംവിധാനം ഉപയോഗിച്ചേക്കാം. നേറ്റീവ് പ്രൊഫൈലിന്റെ ഊഹങ്ങൾ കൈമാറുന്നതിന് പകരം ആ ദാതാവിന്റെ ഡോക്യുമെന്റേഷൻ വായിക്കുക, കൂടാതെ യഥാർത്ഥത്തിൽ ഇൻസ്റ്റാൾ ചെയ്ത പ്രൊഫൈലിലെ പരാമർശം പരിശോധിക്കുക, മാനേജ്മെന്റ് കൺസോളിലെ ഡ്രാഫ്റ്റിലല്ല.
തിരഞ്ഞെടുപ്പും സ്വീകാര്യതയും വേറിട്ട നാഴികക്കല്ലുകളാണ്
നിറഞ്ഞ തിരഞ്ഞെടുക്കൽ എന്നാൽ ക്ലയന്റിന് ഐഡന്റിറ്റി കണ്ടെത്താനും ഉപയോഗിക്കാനും കഴിയും എന്നാണ്. ഗേറ്റ്വേ അത് സ്വീകരിക്കുമോ എന്നതിനെപ്പറ്റി അത് ഒന്നും പറയുന്നില്ല. സെർവർ ഇപ്പോഴും ഇഷ്യൂവറും സാധുതാ കാലയളവും റദ്ദാക്കൽ നിലയും പരിശോധിക്കുന്നു, കൂടാതെ ആ ക്രെഡൻഷ്യലിൽ നിന്ന് അക്കൗണ്ടിലേക്കുള്ള മാപ്പിംഗും.
രണ്ട് ഘട്ടങ്ങളും വ്യക്തമായി, ആ ക്രമത്തിൽ പരിശോധിക്കുക. ഐഡന്റിറ്റി വാഗ്ദാനം ചെയ്യുന്നുണ്ടെന്ന് സ്ഥിരീകരിച്ച് കണക്റ്റ് ചെയ്യുക, തുടർന്ന് ഗേറ്റ്വേ ഉടമയോട് ഏത് ക്രെഡൻഷ്യൽ അവതരിപ്പിച്ചു, ഏത് മാപ്പിംഗ് നിയമം അത് ഉപയോഗിച്ചു എന്ന് സ്ഥിരീകരിക്കാൻ ആവശ്യപ്പെടുക. ക്ലയന്റ് ഐഡന്റിറ്റി നൽകുകയും സെർവർ അത് നിരസിക്കുകയും ചെയ്താൽ, ബാക്കി ജോലി സെർവർ വശത്താണ്. Mac-ൽ സർട്ടിഫിക്കറ്റ് വീണ്ടും ഇൻസ്റ്റാൾ ചെയ്താലും എത്ര തവണ ആവർത്തിച്ചാലും ആ ഫലം മാറില്ല.