Mac IKEv2 ECDSA: ക്ലയന്റിന് ഏത് സർട്ടിഫിക്കറ്റ് തരം അവകാശപ്പെടുന്നു?
Mac-ൽ, IKEv2 ക്രമീകരണങ്ങളിലെ ECDSA256 പ്രാദേശിക ഐഡന്റിറ്റി സർട്ടിഫിക്കറ്റിനെ വിവരിക്കുന്നു, ഗേറ്റ്വേയെയോ ഇഷ്യൂവറുടെ ഒപ്പിനെയോ അല്ല. തിരഞ്ഞെടുക്കുന്നതിന് മുമ്പ് ഓരോ പങ്കും വായിക്കുക.
macOS-ൽ, IKEv2 ക്ലയന്റ് ക്രമീകരണത്തിലെ ECDSA തിരഞ്ഞെടുപ്പ് ഒരു ഇടുങ്ങിയ ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു: ഏത് സർട്ടിഫിക്കറ്റാണ് Mac-ന്റെ ഐഡന്റിറ്റി തെളിയിക്കുന്നത്. ഗേറ്റ്വേ സർട്ടിഫിക്കറ്റ്, ക്ലയന്റ് സർട്ടിഫിക്കറ്റ് നൽകിയ ഒപ്പ്, അല്ലെങ്കിൽ ടണലിന്റെ എൻക്രിപ്ഷൻ നിർദ്ദേശം എന്നിവയെ അത് വിവരിക്കുന്നില്ല. ഈ നാല് പങ്കുകളെ ഒരൊറ്റ അനുയോജ്യതാ ചോദ്യമായി കാണുന്നതാണ് ശരിയായ പ്രാദേശിക ക്രമീകരണത്തിന് സർവർ വശത്തെ പൊരുത്തക്കേടിന്റെ കുറ്റം ലഭിക്കുന്ന വഴി. തീരുമാനം ചെറുതാണ്, പക്ഷേ അതെടുക്കാൻ ഉപയോഗിക്കുന്ന തെളിവുകൾ കൃത്യമായിരിക്കണം.
ഈ ഫീൽഡ് ഒരു സർട്ടിഫിക്കറ്റിനെ പേരിടുന്നു: പ്രാദേശിക ഐഡന്റിറ്റി
Apple-ന്റെ Network Extension API ക്ലയന്റ് ക്രെഡൻഷ്യലിന് ഒരു സർട്ടിഫിക്കറ്റ് തരം നൽകുന്നു, അതിൽ NEVPNIKEv2CertificateType.ECDSA256 ഉൾപ്പെടുന്നു, ഇത് ECDSA p-256 സർട്ടിഫിക്കറ്റ് തരമായി രേഖപ്പെടുത്തിയിരിക്കുന്നു. ഈ സവിശേഷത identityReference അല്ലെങ്കിൽ identityData വഴി നൽകുന്ന സർട്ടിഫിക്കറ്റിന് ബാധകമാണ്.
അതായത്, Mac അവതരിപ്പിക്കുന്ന സർട്ടിഫിക്കറ്റിനെയും അതിനൊപ്പമുള്ള സ്വകാര്യ കീയെയും കുറിച്ചാണ് തീരുമാനം. ആ ലീഫ് സർട്ടിഫിക്കറ്റിന്റെ പൊതു കീയുമായി പൊരുത്തപ്പെടുന്ന തരം തിരഞ്ഞെടുത്ത് പിന്തുണയ്ക്കുന്ന സംവിധാനത്തിലൂടെ ഐഡന്റിറ്റി നൽകുക. Mac-ന് ഐഡന്റിറ്റിക്ക് ഉപയോഗയോഗ്യമായ സ്വകാര്യ കീ ഇല്ലെങ്കിൽ, തരം തിരഞ്ഞെടുക്കൽ കണക്ഷനെ രക്ഷിക്കാൻ കഴിയില്ല.
മാനേജുചെയ്ത പ്രൊഫൈലുകൾ IKEv2 പേലോഡിന്റെ CertificateType വഴി അതേ തീരുമാനം എടുക്കുന്നു, PayloadCertificateUUID പോലുള്ള സർട്ടിഫിക്കറ്റ് റഫറൻസിനൊപ്പം. ഈ ഫീൽഡുകൾക്ക് ലക്ഷ്യ OS പതിപ്പിനുള്ള മുൻവ്യവസ്ഥകളും സ്കീമയും ഉണ്ട്; പ്രൊഫൈലിലേക്ക് പകർത്തിയ നഗ്ന തരം മൂല്യം ഇൻസ്റ്റാൾ ചെയ്യാനാകില്ല, കൂടാതെ ക്രമീകരണ വിൻഡോ എല്ലാ API ഓപ്ഷനും കാണിച്ചെന്ന് വരില്ല. വിന്യസിക്കുന്നതിന് മുമ്പ് ആ പതിപ്പിനുള്ള പേലോഡ് മുൻവ്യവസ്ഥകൾ പരിശോധിക്കുക.
സർട്ടിഫിക്കറ്റ് ലേബലിലല്ല, പങ്കിന്റെ അടിസ്ഥാനത്തിൽ തീരുമാനിക്കുക
നിങ്ങൾ മാറ്റാൻ പോകുന്ന ഫീൽഡ് വായിച്ച് അത് ഏത് സർട്ടിഫിക്കറ്റിലേക്ക് ചൂണ്ടുന്നു എന്ന് ചോദിക്കുക. സർട്ടിഫിക്കറ്റ് വ്യൂവറിലെ ലേബലുകൾ വിഷയം, ഇഷ്യൂവർ, ഒപ്പ് അൽഗോരിതം എന്നിവ കൂട്ടിക്കലർത്തുന്നു, അവയിൽ ഒന്ന് മാത്രമാണ് ക്ലയന്റ് ഐഡന്റിറ്റി തിരഞ്ഞെടുപ്പുമായി ബന്ധപ്പെട്ടത്.
| What you inspected | What it controls | Does it choose the Mac certificate type? |
|---|---|---|
| Client leaf public key | The identity the Mac presents | Yes, this is the field's subject |
| Issuer signature algorithm | How the client certificate was signed | No |
| Gateway certificate | What the Mac validates as the peer | No, check it separately |
| IKE and ESP proposals | Algorithms for the tunnel | No, separate proposal settings |
സർട്ടിഫിക്കറ്റ് വ്യൂവർ CA-യിൽ നിന്നുള്ള ECDSA ഒപ്പ് കാണിക്കുന്നുവെങ്കിൽ, അത് ഇഷ്യൂവറുടെ ഒപ്പിടൽ കീയെ വിവരിക്കുന്നു. ക്ലയന്റിന്റെ സ്വന്തം കീ ഇപ്പോഴും RSA ആകാം, കൂടാതെ തരം ഫീൽഡ് ഒപ്പ് വരിയെയല്ല, ക്ലയന്റ് കീയെ അനുസരിക്കണം. ഈ ഒറ്റ ആശയക്കുഴപ്പം "ECDSA ക്രമീകരിച്ചിട്ടുണ്ട് പക്ഷേ കണക്ഷൻ പരാജയപ്പെടുന്നു" എന്ന നിരവധി റിപ്പോർട്ടുകൾ വിശദീകരിക്കുന്നു. എന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് ലീഫിലെ കീ തരം പ്രൊഫൈലിൽ തിരഞ്ഞെടുത്ത തരവുമായി താരതമ്യം ചെയ്യുക.
ലീഫ് തിരിച്ചറിഞ്ഞാൽ തീരുമാനം ലളിതമാകും: p-256 ക്ലയന്റ് കീയ്ക്ക് ECDSA256, വ്യത്യസ്ത കീയ്ക്ക് മറ്റൊരു പിന്തുണയുള്ള തരം. ക്ലയന്റ് സർട്ടിഫിക്കറ്റും അതിന്റെ കീയും പൊരുത്തപ്പെടുന്നില്ലെങ്കിൽ, VPN പ്രൊഫൈൽ മാറ്റുന്നതിന് മുമ്പ് ആ ജോടി ശരിയാക്കുക.
ഗേറ്റ്വേ സർട്ടിഫിക്കറ്റ് വേറിട്ട തീരുമാനമാണ്
ഗേറ്റ്വേ സ്വന്തം സർട്ടിഫിക്കറ്റ് അവതരിപ്പിക്കുന്നു, Mac അത് ട്രസ്റ്റ് ആങ്കറിനും പ്രതീക്ഷിത നാമത്തിനും എതിരെ സാധൂകരിക്കുന്നു. ആ സർട്ടിഫിക്കറ്റ് ECDSA, RSA അല്ലെങ്കിൽ മറ്റൊരു കീ തരം ഉപയോഗിക്കുന്നുവോ എന്നത് സർവറിന്റെ സവിശേഷതയാണ്, ക്ലയന്റ് ഐഡന്റിറ്റി ക്രമീകരണത്തിന്റേതല്ല.
ECDSA ക്ലയന്റ് സർട്ടിഫിക്കറ്റിനുള്ള പ്രാദേശിക പിന്തുണ ഓരോ ഗേറ്റ്വേ സർട്ടിഫിക്കറ്റും, കർവും, സർവർ ഓതന്റിക്കേഷൻ ക്രമീകരണവും പരസ്പരം പ്രവർത്തിക്കുമെന്ന് തെളിയിക്കുന്നില്ല. സർവറിന്റെ ഐഡന്റിറ്റി, അതിന്റെ ചെയിൻ, IKE ഓതന്റിക്കേഷൻ രീതി എന്നിവ വേറിട്ട ഇൻപുട്ടുകളായി പരിശോധിക്കുക, കൂടാതെ യഥാർത്ഥത്തിൽ വിന്യസിക്കുന്ന പ്രൊഫൈലുമായി പരീക്ഷിക്കുക.
ഗേറ്റ്വേ സർട്ടിഫിക്കറ്റാണ് പ്രശ്നമെങ്കിൽ, ലക്ഷണം സാധാരണയായി ഐഡന്റിറ്റി തിരഞ്ഞെടുപ്പിലല്ല, പിയർ സാധൂകരണ സമയത്താണ് പ്രത്യക്ഷപ്പെടുന്നത്. ക്ലയന്റ് തരം മാറ്റുന്നതിന് മുമ്പ് പരാജയ ഘട്ടം വായിക്കുക, കാരണം ട്രസ്റ്റ് പരാജയത്തിനും ക്ലയന്റ്-കീ പൊരുത്തക്കേടിനും ഒരേ പരിഹാരമല്ല.
ഇഷ്യൂവറുടെ ഒപ്പും കീ കരാർ ഗ്രൂപ്പും ക്ലയന്റിന്റെ തരമല്ല
X.509 വിഷയത്തിന്റെ പൊതു കീയും ഇഷ്യൂവറുടെ ഒപ്പും വെവ്വേറെ ഫീൽഡുകളിൽ സൂക്ഷിക്കുന്നു. വിഷയ പൊതു കീ വിവരം സർട്ടിഫിക്കറ്റിലെ കീയെ വിവരിക്കുന്നു; ഒപ്പ് അൽഗോരിതം CA-യുടെ കീയെയും ഒപ്പിടൽ പ്രവർത്തനത്തെയും വിവരിക്കുന്നു. സർട്ടിഫിക്കറ്റ്-തരം ക്രമീകരണവുമായി പൊരുത്തപ്പെടുന്നത് ആദ്യത്തേത് മാത്രമാണ്.
IKE, Child SA നിർദ്ദേശങ്ങൾ മറ്റൊരു അച്ചുതണ്ടാണ്. ECDSA സർട്ടിഫിക്കറ്റ് തരം ESP എൻക്രിപ്ഷൻ തിരഞ്ഞെടുപ്പല്ല, കൂടാതെ കീ കരാർ ഗ്രൂപ്പ് മാറ്റുന്നത് സർട്ടിഫിക്കറ്റ് തരം തിരഞ്ഞെടുക്കുന്നില്ല. പ്രൊഫൈലിൽ സാധുവായ നിർദ്ദേശങ്ങളും തെറ്റായ ഐഡന്റിറ്റി തരവും ഉണ്ടാകാം, അല്ലെങ്കിൽ ശരിയായ ഐഡന്റിറ്റി തരവും പിയർ നിരസിക്കുന്ന നിർദ്ദേശവും ഉണ്ടാകാം.
മാറ്റ രേഖയിൽ മൂന്ന് വരികൾ വെവ്വേറെ സൂക്ഷിക്കുക: ഐഡന്റിറ്റി സർട്ടിഫിക്കറ്റും കീയും, ഗേറ്റ്വേ ട്രസ്റ്റ് ഇൻപുട്ടുകൾ, നിർദ്ദേശങ്ങളുടെ അൽഗോരിതങ്ങൾ. അവയെ ഒരൊറ്റ "ക്രിപ്റ്റോ ക്രമീകരണങ്ങൾ" കുറിപ്പിൽ ചേർത്താൽ അടുത്ത പരാജയത്തിന്റെ കാരണം നിർണ്ണയിക്കാൻ അസാധ്യമാകും.
നിങ്ങൾ ക്രമീകരിച്ച ഫീൽഡുകൾ ഉപയോഗിച്ച് തീരുമാനം പരിശോധിക്കുക
പ്രൊഫൈൽ യഥാർത്ഥത്തിൽ റഫറൻസ് ചെയ്യുന്ന ഐഡന്റിറ്റി പരിശോധിക്കുക, തുടർന്ന് ആ റഫറൻസിലെ സർട്ടിഫിക്കറ്റിന് പ്രതീക്ഷിത പൊതു കീയും ഉപയോഗയോഗ്യമായ സ്വകാര്യ കീയും ഉണ്ടെന്ന് ഉറപ്പാക്കുക. UI-യിൽ കാണിക്കുന്ന തരം, റഫറൻസ് ചെയ്ത സർട്ടിഫിക്കറ്റ്, ഉപകരണത്തിലെ കീ എന്നിവ ഒത്തുപോകണം.
അടുത്തതായി ഗേറ്റ്വേ ഇൻപുട്ടുകൾ ഉറപ്പാക്കുക: പ്രതീക്ഷിത സർവർ നാമം, ട്രസ്റ്റ് ആങ്കർ, IKE ഓതന്റിക്കേഷൻ രീതി. അവസാനം കണക്റ്റ് ചെയ്ത് ഹാൻഡ്ഷേക്ക് എവിടെ നിൽക്കുന്നു എന്ന് വായിക്കുക. ഐഡന്റിറ്റി കൈമാറ്റത്തിന് മുമ്പുള്ള പരാജയം ഈ ക്രമീകരണത്തിൽ നിന്ന് അകറ്റുന്നു; പിയർ സാധൂകരണത്തിലെ പരാജയം ഗേറ്റ്വേ വശത്തേക്ക് ചൂണ്ടുന്നു.
തിരഞ്ഞെടുത്ത തരം, ഐഡന്റിറ്റി റഫറൻസ്, ഗേറ്റ്വേ സർട്ടിഫിക്കറ്റിന്റെ വിഷയം എന്നിവ വിന്യസന കുറിപ്പുകളിൽ രേഖപ്പെടുത്തുക. അടുത്ത പ്രൊഫൈൽ അപ്ഡേറ്റ് അവയിലേതെങ്കിലും മാറ്റാം, കൂടാതെ മൂന്ന് പേരിട്ട മൂല്യങ്ങൾ ക്രമീകരണ പാനലിന്റെ സ്ക്രീൻഷോട്ടിനേക്കാൾ വേഗത്തിൽ താരതമ്യം ചെയ്യാം.