IKEv2-യിൽ രണ്ട് ഒപ്പുകളുണ്ട്: സർട്ടിഫിക്കറ്റും IKE_AUTH-ഉം
CA സർട്ടിഫിക്കറ്റിൽ ഒപ്പിടുന്നു, പീയർ സ്വന്തം രീതിയിൽ അതിന്റെ IKE_AUTH കൈമാറ്റത്തിൽ ഒപ്പിടുന്നു. ഓരോന്നും അതിന്റെ ഫീൽഡിൽ നിന്ന് വായിക്കുക, എന്നിട്ട് രണ്ടും രേഖപ്പെടുത്തുക.
സർട്ടിഫിക്കറ്റ് SHA-256 ആണെന്നാണ് നിങ്ങളുടെ ടിക്കറ്റ് പറയുന്നത്, എന്നാൽ ഗേറ്റ്വേ ലോഗ് മറ്റൊരു ഒപ്പ് അൽഗോരിതം പേരിടുന്നു, ഒപ്പം ആരോ ഇതിനകം CA വീണ്ടും പുറപ്പെടുവിക്കാനുള്ള അപേക്ഷ തയ്യാറാക്കിയിട്ടുണ്ട്. ആ അപേക്ഷ എങ്ങോട്ടും പോകുന്നതിന് മുൻപ് രണ്ട് ഒപ്പുകളും വേർതിരിക്കുക: ഒന്ന് പൊതു കീയിൽ ഇഷ്യൂവറിന്റെ മുദ്രയാണ്, മറ്റൊന്ന് IKE_AUTH സമയത്ത് പീയറിന് യോജിക്കുന്ന സ്വകാര്യ കീ ഉണ്ടെന്നുള്ള തെളിവാണ്. വ്യത്യസ്ത ഘടകങ്ങളാണ് അവ തിരഞ്ഞെടുക്കുന്നത്, അവ വ്യത്യസ്തമാകാൻ അനുവാദമുണ്ട്. ഓരോന്നും അത് കിടക്കുന്നിടത്തുനിന്ന് വായിക്കാൻ രണ്ട് കമാൻഡും ഒരു പട്ടികയും വേണം.
സർട്ടിഫിക്കറ്റിൽ നിന്ന് ഇഷ്യൂവറിന്റെ ഒപ്പ് വായിക്കുക
CA അതിന്റെ ഒപ്പ് ഒരു ഐഡന്റിറ്റിയും കീയും തമ്മിലുള്ള ബന്ധത്തിൽ വയ്ക്കുന്നു. ആ ഒപ്പ് ഇഷ്യൂ ചെയ്യുമ്പോൾ CA എന്ത് ചെയ്തു എന്ന് രേഖപ്പെടുത്തുന്നു, ബന്ധിപ്പിക്കുമ്പോൾ സബ്ജക്റ്റ് എന്ത് ചെയ്യും എന്നല്ല, അതിനാൽ അതിന്റെ അൽഗോരിതം CA-യുടെ സ്വന്തം ഹാഷും കീ തിരഞ്ഞെടുപ്പും വിവരിക്കുന്നു. ഒരു തരത്തിലുള്ള സബ്ജക്റ്റ് കീ ഒരു അസംഗതിയുമില്ലാതെ മറ്റൊരു തരത്തിലുള്ള CA കീയുടെ കീഴിൽ ഇരിക്കാം, ഒപ്പം CA കീ കറക്കം തകരാറല്ല, സാധാരണ ജോലിയാണ്. രണ്ട് ഫീൽഡുകളും വായിക്കൂ, പട്ടികയുടെ പകുതി നിങ്ങളുടെ കൈയിലുണ്ട്:
openssl x509 -in peer.pem -noout -text | grep -E "Signature Algorithm|Public Key Algorithm"രണ്ട് ലേബലുകളും വെവ്വേറെ എൻട്രികളായി എഴുതുക. ആദ്യത്തേത് CA-യെ വിവരിക്കുന്നു, രണ്ടാമത്തേത് സബ്ജക്റ്റിന്റെ കീയെ, ഒപ്പം ഒന്നും ഓൺലൈൻ ഒപ്പ് പ്രവചിക്കുന്നില്ല.
IKE കൈമാറ്റത്തിൽ നിന്ന് ഓൺലൈൻ ഒപ്പ് വായിക്കുക
പ്രാമാണീകരണ സമയത്ത് ഓരോ പീയറും സ്വന്തം സ്വകാര്യ കീ ഉപയോഗിച്ച് കൈമാറ്റ ഡാറ്റയിൽ ഒപ്പിടുന്നു, മറുവശം ആ തെളിവ് സർട്ടിഫിക്കറ്റിന്റെ ഐഡന്റിറ്റി, വിശ്വാസ ശൃംഖല, നയം എന്നിവയ്ക്കെതിരെ പരിശോധിക്കുന്നു. RSA-യിൽ പാഡിംഗും ഹാഷും ഈ ഓൺലൈൻ രീതിയിൽ ഉൾപ്പെടുന്നു, അതിനാൽ നീളമേറിയ കീയോ പുതിയ SHA-256 സർട്ടിഫിക്കറ്റോ സ്വയം പ്രാമാണീകരണ ഒപ്പിനായി RSA-PSS തിരഞ്ഞെടുക്കാൻ കഴിയില്ല. ചർച്ച ചെയ്ത രീതി ഡീമൺ ലോഗിലോ അതിന്റെ കണക്ഷൻ പട്ടികയിലോ കാണാം, സർട്ടിഫിക്കറ്റിൽ ഒരിക്കലുമില്ല. ഓരോ വശവും എന്താണ് ചർച്ച ചെയ്തതെന്ന് ചോദിക്കുക, കാരണം രണ്ട് ദിശകളും വ്യത്യസ്തമാകാം.
ipsec statusall | grep -i "auth\|proposal"ഒരു വശം മറുവശത്തിന് നിർമ്മിക്കാൻ കഴിയാത്ത ഒരു രീതി പേരിടുമ്പോൾ, ടിക്കറ്റ് ഏതിനെക്കുറിച്ചായിരുന്നോ ആ പൊരുത്തക്കേട് നിങ്ങൾ കണ്ടെത്തി. അതിന് CA വീണ്ടും പുറപ്പെടുവിക്കുന്നത് തെറ്റായ പരിഹാരമാണ്, കാരണം പരാജയപ്പെട്ടത് സർട്ടിഫിക്കറ്റ് ഒരിക്കലുമായിരുന്നില്ല.
RFC 7427 എന്ത് മാറ്റുന്നു, എന്ത് മാറ്റുന്നില്ല
യഥാർത്ഥ രീതികൾ RFC 7296-ൽ ഓരോ അൽഗോരിതം സംയോജനത്തിനും നമ്പർ നൽകിയിരിക്കുന്നു. പിന്നീടുള്ള RFC 7427 ഒപ്പ് വിപുലീകരണം ഒപ്പ്-ഹാഷ് പിന്തുണയുടെ സിഗ്നലിംഗിനൊപ്പം പൊതുവായ Digital Signature രീതി കൂട്ടിച്ചേർക്കുന്നു, അതിനാൽ പുതിയ ഹാഷിന് സ്വന്തം രീതി നമ്പർ ഇനി വേണ്ട. ഇത് ചർച്ച ചെയ്യപ്പെടുന്നതാണ്, അനുമാനിക്കുന്നതല്ല: ലൈബ്രറിക്ക് അതേ സർട്ടിഫിക്കറ്റുകൾ പാഴ്സ് ചെയ്യാൻ കഴിയുന്നതുകൊണ്ട് പീയറിന് വിപുലീകരണം ലഭിക്കുന്നില്ല, യഥാർത്ഥ രീതികൾ മാത്രം നടപ്പിലാക്കുന്ന പീയർ ഗേറ്റ്വേയെ അവയിലൊന്ന് നിലനിർത്താൻ നിർബന്ധിക്കുന്നു. ഇത് അനുയോജ്യതാ ചെലവുള്ള നയ വിനിമയമാണ്, തകരാറല്ല.
പിന്തുണ ഓരോ ദിശയ്ക്കും ഓരോ കണക്ഷനും ആണ്, അതിനാൽ കുടുംബതല പ്രഖ്യാപനം വിശ്വസിക്കുന്നതിനുപകരം നിങ്ങളുടെ മുൻപിലുള്ള ബിൽഡ് പരിശോധിക്കുക. മൂന്ന് വർഷം മുൻപ് എഴുതിയ കഴിവ് മാട്രിക്സ് മൂന്ന് വർഷം പഴക്കമുള്ള ബിൽഡുകളെ വിവരിക്കുന്നു.
പട്ടികയിൽ നാല് വരികൾ ഇടുക
തർക്കം അവസാനിപ്പിക്കുന്ന രേഖയിൽ നാല് വരികളുണ്ട്, ഓരോന്നും വേറൊരു സ്ഥലത്തുനിന്ന് വായിച്ചതും ഓരോന്നും വേറൊരു വ്യക്തി മാറ്റിയതും. എന്തെങ്കിലും തീരുമാനിക്കുന്നതിന് മുൻപ് അത് പൂരിപ്പിക്കുക, കാരണം തെറ്റായ വരിയാണ് പരിഹാരം തിരഞ്ഞെടുക്കുന്നത്.
| വസ്തു | എവിടെനിന്ന് വായിക്കണം | ആര് മാറ്റുന്നു |
|---|---|---|
| സർട്ടിഫിക്കറ്റ് ഇഷ്യൂവറിന്റെ ഒപ്പ് | സർട്ടിഫിക്കറ്റിന്റെ Signature Algorithm ഫീൽഡ് | CA ഓപ്പറേറ്റർ, ഇഷ്യൂ സമയത്ത് |
| സബ്ജക്റ്റിന്റെ പൊതു കീ | സർട്ടിഫിക്കറ്റിന്റെ Public Key Algorithm ഫീൽഡ് | സബ്ജക്റ്റ് കീ നിർമ്മിക്കുന്നയാൾ |
| IKE പ്രാമാണീകരണ രീതി | ഡീമൺ ലോഗ് അല്ലെങ്കിൽ കണക്ഷൻ പട്ടിക, auth, signature-hash അറിയിപ്പ് | രണ്ട് പീയറുകളിലെയും IKE പ്രൊഫൈൽ |
| IKE, ESP സംരക്ഷണ അൽഗോരിതങ്ങൾ | കണക്ഷന്റെ നിർദ്ദേശ പട്ടിക | IPsec പ്രൊഫൈൽ, ഓരോ ദിശയ്ക്കും |
ഓരോ വരിയും അതിന്റേതായ അനുയോജ്യതാ പരിണാമം വഹിക്കുന്നു. ESP സൈഫർ മാറ്റം ഇഷ്യൂവറിന്റെ ഒപ്പ് തിരഞ്ഞെടുക്കുന്നില്ല, CA പരിശോധന അയച്ചാൽ പീയറുകൾ ഒരിക്കലും ചർച്ച ചെയ്യാത്ത ഓൺലൈൻ രീതി കൂട്ടിച്ചേർക്കുന്നുമില്ല. ടിക്കറ്റ് ഒപ്പ് പൊരുത്തക്കേട് ആരോപിക്കുമ്പോൾ, യഥാർത്ഥത്തിൽ തെറ്റായ വരി മിക്കവാറും ഒന്നാമത്തേതല്ല.
PKI ദുർബലമാക്കാതെ പഴയ കേസ് തീർപ്പാക്കുക
പഴയ പീയറിന് നിങ്ങളുടെ നയം ഇനി അനുവദിക്കാത്ത ഒരു രീതി മാത്രം വാഗ്ദാനം ചെയ്യാം. സമയപരിധിയുള്ള അനുയോജ്യതാ ഒഴിവ്, ക്ലൈന്റ് അപ്ഡേറ്റ്, അല്ലെങ്കിൽ ആ പീയറിന് മാത്രമായി മറ്റൊരു പ്രാമാണീകരണ ക്രമീകരണം എന്നിവയാണ് ഓപ്ഷനുകൾ. ദുർബലമായ സർട്ടിഫിക്കറ്റ് ഒപ്പിനുചുറ്റും PKI പുനർനിർമ്മിക്കുന്നത് ഓൺലൈൻ കൈമാറ്റത്തിലെ പരിമിതി പരിഹരിക്കുന്നില്ല, അതേ CA-യിൽ വിശ്വസിക്കുന്ന മറ്റെല്ലാ സേവനങ്ങളെയും ദുർബലമാക്കുന്നു. ഏത് വരിയാണ് മാറ്റിയതെന്നും ഒഴിവ് എപ്പോൾ അവസാനിക്കുമെന്നും രേഖപ്പെടുത്തുക.
തുടർന്ന് രണ്ട് വായനകളും വീണ്ടും മുകളിൽനിന്ന് നടത്തുക, കാരണം ഒരു വരിയിലെ മാറ്റം മറ്റൊന്നിൽ ചർച്ച ചെയ്യുന്നതിനെ നീക്കാം. മുഴുവൻ പട്ടികയും രണ്ട് കമാൻഡും ഒരു പട്ടികയുമാണ്, പീയർ റൗട്ടറോ ലാപ്ടോപ്പോ ഉപകരണമോ ആയാലും ജോലി അതേതാണ്.